From bcampbell@pingidentity.com Wed May 1 05:37:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B4E21F99A3 for ; Wed, 1 May 2013 05:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT6EtFgqtDuS for ; Wed, 1 May 2013 05:37:19 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3D21F9939 for ; Wed, 1 May 2013 05:36:13 -0700 (PDT) Received: from mail-ob0-f197.google.com ([209.85.214.197]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUYEMOryLbNXiFf/RvoRsfk4mS+cpn7vR@postini.com; Wed, 01 May 2013 05:36:13 PDT Received: by mail-ob0-f197.google.com with SMTP id eh20so7808366obb.0 for ; Wed, 01 May 2013 05:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=w6/yFYvfz/JgRTXehEPjFpxC54SgHKT3CM5CucDG9Kg=; b=KSEu5DNhfBZ2o1Uk3l4gNP8bPbqrFYuhunvN/AmMejgMzgfN1878hUAhcj0p3DXbfj 1zELUhtF5eY1C20LTdnGDblfzckAN0Wd/ygfU87z6xVoxA/a4Cs9Ig3N6XUTAgGL7+Ar hfhfvZ/moTrxJ7dghgVVxoZTbt3umjWHTtLrnfeexkjgMxegFWcagsVYK1GRS+jUKdhH 7kCARR3nbCYVvSqEv7YeemSLaK5UT740/2nQbMWzlEVbnCRdOJv2tigAWt7go14vBxIn i8xcThyAm+gljq1WLEVmCF3JAuxIkLxvVGHScgMvR7Mp51XmiXcStW+tBYmxEsR4ODjO niUQ== X-Received: by 10.50.114.42 with SMTP id jd10mr1479879igb.101.1367411769765; Wed, 01 May 2013 05:36:09 -0700 (PDT) X-Received: by 10.50.114.42 with SMTP id jd10mr1479876igb.101.1367411769584; Wed, 01 May 2013 05:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.146 with HTTP; Wed, 1 May 2013 05:35:39 -0700 (PDT) In-Reply-To: <51483C49.4040503@gmail.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> <51483C49.4040503@gmail.com> From: Brian Campbell Date: Wed, 1 May 2013 06:35:39 -0600 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=047d7b414058caca5904dba75cf5 X-Gm-Message-State: ALoCoQkIZKUJUJkA5GqD+y+R7zdHxHYcOteNeHm2kVRAOzBv5wzocY/YKYk3q52mKv7CmHTyDoK5dSQ16FqvU5J3SfpOeOIEvzZEXUuC3wO+qJWYL/ywJ4DNRgHrAUL56oRs0v+ADd+S Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-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, 01 May 2013 12:37:23 -0000 --047d7b414058caca5904dba75cf5 Content-Type: text/plain; charset=ISO-8859-1 Just trying to close the loop on this thread (six weeks later, sorry). New drafts were published last month that (hopefully) have more clear text about the treatment of client_id. And it's been removed from examples where it's optional. http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin wrote: > Hi, > > Just one remark, the example in [1] shows "client_id"; IMHO it makes sense > to clarify than in this context (where the assertion is used as a grant), > it is optional as per: > > http://tools.ietf.org/html/**rfc6749#section-3.2.1 > > "A client MAY use the "client_id" request parameter to identify itself > when sending requests to the token endpoint" > > and otherwise > > http://tools.ietf.org/html/**rfc6749#section-2.3 > > dictates how the client authentication is done. > > By the way, my reading of the main spec's section 2.3 tells me that the > only time one would use only "client_id" in the form payload is when the > client secret is empty or perhaps the client is not in the possession of > the secret. > > Does it make sense to completely drop a "client_id" parameter in the > example at [1] in the assertion draft and use an example with a Basic > authentication instead ? > > Thanks, Sergey > > > On 15/03/13 22:12, Brian Campbell wrote: > >> So currently the base assertion document defines scope as an HTTP >> parameter on the access token request message when using an assertion as >> a grant[1]. And that applies to both the SAML and JWT grants (perhaps >> that needs to be more clear?). Also RFC 6749 defines the scope parameter >> for the client credentials access token request[2], which similarly >> applies to both SAML and JWT in the case of assertion client >> authentication using the "client_credentials" grant type. >> >> [1] http://tools.ietf.org/html/**draft-ietf-oauth-assertions-** >> 10#section-4.1 >> [2] http://tools.ietf.org/html/**rfc6749#section-4.4.1 >> >> >> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 >> >> >> >> wrote: >> >> Right ... thinking about this further I think the answer is "all of >> the above." If the JWT is a grant type then as you say it needs a >> scope param and optionally a client_id param. I argued for the >> client_id param earlier since it could assist with HOK scenarios >> once those further develop. >> >> But when the JWT is used as an AT then it will definitely require >> the scope as a claim. >> >> So I change my argument to "both" :) >> >> adam >> >> -----Original Message----- >> From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org ] On >> Behalf Of Sergey Beryozkin >> Sent: Friday, March 15, 2013 4:31 PM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] JWT grant_type and client_id >> >> Hi >> On 15/03/13 20:40, Lewis Adam-CAL022 wrote: >> > Hi John, >> > >> > I would like to argue that the scope should be a parameter in the >> access >> > token request message, the same as it is for the RO creds grant and >> > client creds grant type. This would keep it consistent with the >> core >> > OAuth grant types that talk directly to the token endpoint. >> > >> Assuming the assertion is acting as a grant, then it is indeed an >> access >> token request message, so IMHO it makes sense to get an outbound scope >> parameter optionally supported which I guess will imply that the >> client >> id will also have to accompany it... >> >> Cheers, Sergey >> >> > Thoughts? >> > >> > adam >> > >> > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >> ] >> > *Sent:* Friday, March 15, 2013 12:10 PM >> > *To:* Lewis Adam-CAL022 >> > *Cc:* Brian Campbell; "WG > >"@il06**exr02.mot.com< >> http://il06exr02.mot.com> >> > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id >> > >> > The spec is a touch vague on that. I think the scopes should be >> in the >> > assertion and the client can use the scopes outside the assertion >> to >> > down-scope. >> > >> > Having a standard claim in JWT and SAML for passing scopes is >> probably >> > useful as part of a profile. >> > >> > John B. >> > >> > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 >> > >> >> > >> > >> >> >>> >> wrote: >> > >> > >> > >> > Hmmm, one more thought ... no scope?? The JWT is the grant, is it >> assumed >> > that the scope is conveyed as a claim within the token? Otherwise >> it >> > would seem that it would require a scope. >> > >> > Thoughts? >> > >> > adam >> > >> > *From:*Brian Campbell [mailto:bcampbell@**pingidentity.com >> > >> > ] >> > *Sent:*Thursday, March 14, 2013 4:44 PM >> > *To:*Lewis Adam-CAL022 >> > *Cc:*Mike Jones; "WG >> > > >>"@il0**6exr02.mot.com >> >> >> > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id >> > >> > Yes, that is correct. >> > >> > I'm working on new revisions of the drafts that will hopefully >> make that >> > point more clear. >> > >> > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 >> > >> >> > >> > >> >> >>> >> wrote: >> > >> > Coming back to this... am I correct in that client_id is not >> required? We are implementing this spec and want to make sure >> that we are doing it right. By my understanding the only two >> parameters that are required in the JWT grant type are >> "urn:ietf:params:oauth:grant-**type:jwt-bearer" and the assertion. >> Is this correct? >> > >> > *From:*Mike Jones [mailto:Michael.Jones@**microsoft.com >> > >> > >> >> >>] >> > *Sent:*Monday, February 18, 2013 6:58 PM >> > *To:*Lewis Adam-CAL022;oauth@ietf.org >> > >> > >> >WG >> > *Subject:*RE: JWT grant_type and client_id >> > >> > The client_id value and the access token value are independent. >> > >> > -- Mike >> > >> > *From:*oauth-bounces@ietf.org >> > > >[mailto:oauth-bounces@ietf.**org >> >> >> > > >]*On Behalf Of*Lewis Adam-CAL022 >> > *Sent:*Monday, February 18, 2013 2:50 PM >> > *To:*oauth@ietf.org >> >WG >> >> > *Subject:*[OAUTH-WG] JWT grant_type and client_id >> > >> > Is there any guidance on the usage of client_id when using the JWT >> > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 >> makes >> > no mention so I assume that it is not required ... but it would be >> > necessary if using in conjunction with a HOK profile where the JWT >> > assertion is issued to - and may only be used by - the intended >> client. >> > Obviously this is straight forward enough, really I'm just >> looking to be >> > sure that I'm not missing anything. >> > >> > tx >> > >> > adam >> > >> > >> > ______________________________**_________________ >> > OAuth mailing 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 >> >> >> > > --047d7b414058caca5904dba75cf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just trying to close the loop on this thread (six weeks la= ter, sorry). New drafts were published last month that (hopefully) have mor= e clear text about the treatment of client_id. And it's been removed fr= om examples where it's optional.

http://www.ietf.org/mail-archive/web/oauth/current/= msg11213.html


On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi,

Just one remark, the example in [1] shows "client_id"; IMHO it ma= kes sense to clarify than in this context (where the assertion is used as a= grant), it is optional as per:

http://tools.ietf.org/html/rfc6749#section-3.2.1

"A client MAY use the "client_id" request parameter to ident= ify itself
=A0when sending requests to the token endpoint"

and otherwise

http://tools.ietf.org/html/rfc6749#section-2.3

dictates how the client authentication is done.

By the way, my reading of the main spec's section 2.3 tells me that the= only time one would use only "client_id" in the form payload is = when the client secret is empty or perhaps the client is not in the possess= ion of the secret.

Does it make sense to completely drop a "client_id" parameter in = the example at [1] in the assertion draft and use an example with a Basic a= uthentication instead ?

Thanks, Sergey


On 15/03/13 22:12, Brian Campbell wrote:
So currently the base assertion document defines scope as an HTTP
parameter on the access token request message when using an assertion as a grant[1]. =A0And that applies to both the SAML and JWT grants (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials access token request[2], which similarly
applies to both SAML and JWT in the case of assertion client
authentication using the "client_credentials" grant type.

[1] http://tools.ietf.org/html/draft-ietf-o= auth-assertions-10#section-4.1
[2] http://tools.ietf.org/html/rfc6749#section-4.4.1


On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022
<A= dam.Lewis@motorolasolutions.com
<mailto:Adam.Lewis@motorolasolutions.com>> wrote:

=A0 =A0 Right ... thinking about this further I think the answer is "a= ll of
=A0 =A0 the above." =A0If the JWT is a grant type then as you say it n= eeds a
=A0 =A0 scope param and optionally a client_id param. =A0I argued for the =A0 =A0 client_id param earlier since it could assist with HOK scenarios =A0 =A0 once those further develop.

=A0 =A0 But when the JWT is used as an AT then it will definitely require =A0 =A0 the scope as a claim.

=A0 =A0 So I change my argument to "both" :)

=A0 =A0 adam

=A0 =A0 -----Original Message-----
=A0 =A0 From: o= auth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
=A0 =A0 [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] On
=A0 =A0 Behalf Of Sergey Beryozkin
=A0 =A0 Sent: Friday, March 15, 2013 4:31 PM
=A0 =A0 To: oauth@ietf.= org <mailto:oaut= h@ietf.org>
=A0 =A0 Subject: Re: [OAUTH-WG] JWT grant_type and client_id

=A0 =A0 Hi
=A0 =A0 On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
=A0 =A0 =A0> Hi John,
=A0 =A0 =A0>
=A0 =A0 =A0> I would like to argue that the scope should be a parameter = in the
=A0 =A0 access
=A0 =A0 =A0> token request message, the same as it is for the RO creds g= rant and
=A0 =A0 =A0> client creds grant type. This would keep it consistent with= the core
=A0 =A0 =A0> OAuth grant types that talk directly to the token endpoint.=
=A0 =A0 =A0>
=A0 =A0 Assuming the assertion is acting as a grant, then it is indeed an a= ccess
=A0 =A0 token request message, so IMHO it makes sense to get an outbound sc= ope
=A0 =A0 parameter optionally supported which I guess will imply that the cl= ient
=A0 =A0 id will also have to accompany it...

=A0 =A0 Cheers, Sergey

=A0 =A0 =A0> Thoughts?
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com
=A0 =A0 <mailto:v= e7jtb@ve7jtb.com>]
=A0 =A0 =A0> *Sent:* Friday, March 15, 2013 12:10 PM
=A0 =A0 =A0> *To:* Lewis Adam-CAL022
=A0 =A0 =A0> *Cc:* Brian Campbell; "WG <oauth@ietf.org
=A0 =A0 =A0> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> The spec is a touch vague on that. I think the scopes shoul= d be
=A0 =A0 in the
=A0 =A0 =A0> assertion and the client can use the scopes outside the ass= ertion to
=A0 =A0 =A0> down-scope.
=A0 =A0 =A0>
=A0 =A0 =A0> Having a standard claim in JWT and SAML for passing scopes = is
=A0 =A0 probably
=A0 =A0 =A0> useful as part of a profile.
=A0 =A0 =A0>
=A0 =A0 =A0> John B.
=A0 =A0 =A0>
=A0 =A0 =A0> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
=A0 =A0 =A0> <Adam.Lewis@motorolasolutions.com
=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>
=A0 =A0 =A0> <mailto:Adam.Lewis@motorolasolutions.com

=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>>> wrote= :
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> Hmmm, one more thought ... no scope?? The JWT is the grant,= is it
=A0 =A0 assumed
=A0 =A0 =A0> that the scope is conveyed as a claim within the token? Oth= erwise it
=A0 =A0 =A0> would seem that it would require a scope.
=A0 =A0 =A0>
=A0 =A0 =A0> Thoughts?
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com =A0 =A0 <mailto:bcampbell@pingidentity.com>
=A0 =A0 =A0> <h= ttp://pingidentity.com>]
=A0 =A0 =A0> *Sent:*Thursday, March 14, 2013 4:44 PM
=A0 =A0 =A0> *To:*Lewis Adam-CAL022
=A0 =A0 =A0> *Cc:*Mike Jones; "WG <oauth@ietf.org <mailto:oauth@ietf.org>
=A0 =A0 =A0> <mailto:oauth@ietf.org
=A0 =A0 <mailto:oaut= h@ietf.org>>>"@il06exr02.mot.com
=A0 =A0 <http://i= l06exr02.mot.com> <http://il06exr02.mot.com>

=A0 =A0 =A0> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> Yes, that is correct.
=A0 =A0 =A0>
=A0 =A0 =A0> I'm working on new revisions of the drafts that will ho= pefully
=A0 =A0 make that
=A0 =A0 =A0> point more clear.
=A0 =A0 =A0>
=A0 =A0 =A0> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
=A0 =A0 =A0> <Adam.Lewis@motorolasolutions.com
=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>
=A0 =A0 =A0> <mailto:Adam.Lewis@motorolasolutions.com

=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>>> wrote= :
=A0 =A0 =A0>
=A0 =A0 =A0> Coming back to this... =A0am I correct in that client_id is= not
=A0 =A0 required? =A0 =A0We are implementing this spec and want to make sur= e
=A0 =A0 that we are doing it right. =A0 =A0By my understanding the only two=
=A0 =A0 parameters that are required in the JWT grant type are
=A0 =A0 "urn:ietf:params:oauth:grant-type:jwt-bearer" =A0 = =A0and the assertion.
=A0 =A0 =A0 =A0 =A0 Is this correct?
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
=A0 =A0 <mailto:Michael.Jones@microsoft.com>
=A0 =A0 =A0> <mailto:Michael.Jones@microsoft.com
=A0 =A0 <mailto:Michael.Jones@microsoft.com>>]
=A0 =A0 =A0> *Sent:*Monday, February 18, 2013 6:58 PM
=A0 =A0 =A0> *To:*Lewis Adam-CAL022;oauth@ietf.org
=A0 =A0 <mailto:Adam-CAL022%3Boauth@ietf.org> <mailto:oauth@ietf.org

=A0 =A0 <mailto:oaut= h@ietf.org>>WG
=A0 =A0 =A0> *Subject:*RE: JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> The client_id value and the access token value are independ= ent.
=A0 =A0 =A0>
=A0 =A0 =A0> -- Mike
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
=A0 =A0 =A0> <mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>>[mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>
=A0 =A0 =A0> <mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>>]*On Behalf Of*Lewis Adam-CAL0= 22
=A0 =A0 =A0> *Sent:*Monday, February 18, 2013 2:50 PM
=A0 =A0 =A0> *To:*oa= uth@ietf.org <mailto:oauth@ietf.org>
=A0 =A0 <mailto:oaut= h@ietf.org <mailto:oauth@ietf.org>>WG

=A0 =A0 =A0> *Subject:*[OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> Is there any guidance on the usage of client_id when using = the JWT
=A0 =A0 =A0> assertion profile as a grant type? draft-ietf-oauth-jwt-bea= rer-04
=A0 =A0 makes
=A0 =A0 =A0> no mention so I assume that it is not required ... but it w= ould be
=A0 =A0 =A0> necessary if using in conjunction with a HOK profile where = the JWT
=A0 =A0 =A0> assertion is issued to - and may only be used by - the inte= nded
=A0 =A0 client.
=A0 =A0 =A0> Obviously this is straight forward enough, really I'm j= ust
=A0 =A0 looking to be
=A0 =A0 =A0> sure that I'm not missing anything.
=A0 =A0 =A0>
=A0 =A0 =A0> tx
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org> <mailto:OAuth@ietf.org

=A0 =A0 <mailto:OAut= h@ietf.org>>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org> <mailto:OAuth@ietf.org

=A0 =A0 <mailto:OAut= h@ietf.org>>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth

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





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





--047d7b414058caca5904dba75cf5-- From phil.hunt@oracle.com Wed May 1 06:44:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E597921F9F2E for ; Wed, 1 May 2013 06:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+y-B-j-uhMB for ; Wed, 1 May 2013 06:44:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51321F9F28 for ; Wed, 1 May 2013 06:44:51 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r41Dinsi027796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 May 2013 13:44:49 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r41Dimg4000735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2013 13:44:49 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r41DimlU000730; Wed, 1 May 2013 13:44:48 GMT Received: from [10.15.142.172] (/207.230.249.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 May 2013 06:44:47 -0700 References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> <51483C49.4040503@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-EA8DCECB-D54D-44F5-9446-A68391108543 Content-Transfer-Encoding: 7bit Message-Id: <10D5EF73-469E-4129-9622-ABE7B456E5B0@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 1 May 2013 06:44:42 -0700 To: Brian Campbell X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-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, 01 May 2013 13:44:56 -0000 --Apple-Mail-EA8DCECB-D54D-44F5-9446-A68391108543 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I find the text confusing regarding client auth. >> "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint" It seems to suggest client auth is optional due to the MAY when in fact it i= s just referring to the client_id identifier which is not authn. I fear many= have missed this subtle distinction. Or did you really intend optionality f= or assertions? Phil On 2013-05-01, at 5:35, Brian Campbell wrote: > Just trying to close the loop on this thread (six weeks later, sorry). New= drafts were published last month that (hopefully) have more clear text abou= t the treatment of client_id. And it's been removed from examples where it's= optional. >=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html >=20 >=20 > On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin w= rote: >> Hi, >>=20 >> Just one remark, the example in [1] shows "client_id"; IMHO it makes sens= e to clarify than in this context (where the assertion is used as a grant), i= t is optional as per: >>=20 >> http://tools.ietf.org/html/rfc6749#section-3.2.1 >>=20 >> "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint" >>=20 >> and otherwise >>=20 >> http://tools.ietf.org/html/rfc6749#section-2.3 >>=20 >> dictates how the client authentication is done. >>=20 >> By the way, my reading of the main spec's section 2.3 tells me that the o= nly time one would use only "client_id" in the form payload is when the clie= nt secret is empty or perhaps the client is not in the possession of the sec= ret. >>=20 >> Does it make sense to completely drop a "client_id" parameter in the exam= ple at [1] in the assertion draft and use an example with a Basic authentica= tion instead ? >>=20 >> Thanks, Sergey >>=20 >>=20 >> On 15/03/13 22:12, Brian Campbell wrote: >>> So currently the base assertion document defines scope as an HTTP >>> parameter on the access token request message when using an assertion as= >>> a grant[1]. And that applies to both the SAML and JWT grants (perhaps >>> that needs to be more clear?). Also RFC 6749 defines the scope parameter= >>> for the client credentials access token request[2], which similarly >>> applies to both SAML and JWT in the case of assertion client >>> authentication using the "client_credentials" grant type. >>>=20 >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.= 1 >>> [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 >>>=20 >>>=20 >>> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 >>> >> > wrote: >>>=20 >>> Right ... thinking about this further I think the answer is "all of >>> the above." If the JWT is a grant type then as you say it needs a >>> scope param and optionally a client_id param. I argued for the >>> client_id param earlier since it could assist with HOK scenarios >>> once those further develop. >>>=20 >>> But when the JWT is used as an AT then it will definitely require >>> the scope as a claim. >>>=20 >>> So I change my argument to "both" :) >>>=20 >>> adam >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org ] On >>> Behalf Of Sergey Beryozkin >>> Sent: Friday, March 15, 2013 4:31 PM >>> To: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] JWT grant_type and client_id >>>=20 >>> Hi >>> On 15/03/13 20:40, Lewis Adam-CAL022 wrote: >>> > Hi John, >>> > >>> > I would like to argue that the scope should be a parameter in the= >>> access >>> > token request message, the same as it is for the RO creds grant a= nd >>> > client creds grant type. This would keep it consistent with the c= ore >>> > OAuth grant types that talk directly to the token endpoint. >>> > >>> Assuming the assertion is acting as a grant, then it is indeed an ac= cess >>> token request message, so IMHO it makes sense to get an outbound sco= pe >>> parameter optionally supported which I guess will imply that the cli= ent >>> id will also have to accompany it... >>>=20 >>> Cheers, Sergey >>>=20 >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >>> ] >>> > *Sent:* Friday, March 15, 2013 12:10 PM >>> > *To:* Lewis Adam-CAL022 >>> > *Cc:* Brian Campbell; "WG >> >"@il06exr02.mot.com >>> > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > The spec is a touch vague on that. I think the scopes should be >>> in the >>> > assertion and the client can use the scopes outside the assertion= to >>> > down-scope. >>> > >>> > Having a standard claim in JWT and SAML for passing scopes is >>> probably >>> > useful as part of a profile. >>> > >>> > John B. >>> > >>> > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 >>> > >> >>> > >>=20 >>> >> wrote: >>> > >>> > >>> > >>> > Hmmm, one more thought ... no scope?? The JWT is the grant, is it= >>> assumed >>> > that the scope is conveyed as a claim within the token? Otherwise= it >>> > would seem that it would require a scope. >>> > >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com >>> >>> > ] >>> > *Sent:*Thursday, March 14, 2013 4:44 PM >>> > *To:*Lewis Adam-CAL022 >>> > *Cc:*Mike Jones; "WG >>> > >> >>"@il06exr02.mot.com >>> >>>=20 >>> > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > Yes, that is correct. >>> > >>> > I'm working on new revisions of the drafts that will hopefully >>> make that >>> > point more clear. >>> > >>> > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 >>> > >> >>> > >>=20 >>> >> wrote: >>> > >>> > Coming back to this... am I correct in that client_id is not >>> required? We are implementing this spec and want to make sure >>> that we are doing it right. By my understanding the only two >>> parameters that are required in the JWT grant type are >>> "urn:ietf:params:oauth:grant-type:jwt-bearer" and the assertion. >>> Is this correct? >>> > >>> > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com >>> >>> > >> >] >>> > *Sent:*Monday, February 18, 2013 6:58 PM >>> > *To:*Lewis Adam-CAL022;oauth@ietf.org >>> >>=20 >>> >WG >>> > *Subject:*RE: JWT grant_type and client_id >>> > >>> > The client_id value and the access token value are independent. >>> > >>> > -- Mike >>> > >>> > *From:*oauth-bounces@ietf.org >>> > >> >[mailto:oauth-bounces@ietf.org >>>=20 >>> >>> > >> >]*On Behalf Of*Lewis Adam-CAL022 >>> > *Sent:*Monday, February 18, 2013 2:50 PM >>> > *To:*oauth@ietf.org >>> >WG >>>=20 >>> > *Subject:*[OAUTH-WG] JWT grant_type and client_id >>> > >>> > Is there any guidance on the usage of client_id when using the JW= T >>> > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04= >>> makes >>> > no mention so I assume that it is not required ... but it would b= e >>> > necessary if using in conjunction with a HOK profile where the JW= T >>> > assertion is issued to - and may only be used by - the intended >>> client. >>> > Obviously this is straight forward enough, really I'm just >>> looking to be >>> > sure that I'm not missing anything. >>> > >>> > tx >>> > >>> > adam >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>=20 >>> > >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>=20 >>> > >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=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-EA8DCECB-D54D-44F5-9446-A68391108543 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I find the text confusing regarding cl= ient auth.
"A client MAY use the "client_id" request= parameter to identify itself
 when sending requests to the token en= dpoint"
 It seems= to suggest client auth is optional due to the MAY when in fact it is just r= eferring to the client_id identifier which is not authn. I fear many have mi= ssed this subtle distinction.  Or did you really intend optionality for= assertions?

Phil

On 2013-05-01, at 5:35, Brian C= ampbell <bcampbell@pingiden= tity.com> wrote:

Just trying to close the loop on this thread (six weeks later, sorr= y). New drafts were published last month that (hopefully) have more clear te= xt about the treatment of client_id. And it's been removed from examples whe= re it's optional.

http://www.ietf.org/mail-archive/web/oauth/current/ms= g11213.html


On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
Hi,

Just one remark, the example in [1] shows "client_id"; IMHO it makes sense t= o clarify than in this context (where the assertion is used as a grant), it i= s optional as per:

http://tools.ietf.org/html/rfc6749#section-3.2.1

"A client MAY use the "client_id" request parameter to identify itself
 when sending requests to the token endpoint"

and otherwise

http://tools.ietf.org/html/rfc6749#section-2.3

dictates how the client authentication is done.

By the way, my reading of the main spec's section 2.3 tells me that the only= time one would use only "client_id" in the form payload is when the client s= ecret is empty or perhaps the client is not in the possession of the secret.=

Does it make sense to completely drop a "client_id" parameter in the example= at [1] in the assertion draft and use an example with a Basic authenticatio= n instead ?

Thanks, Sergey


On 15/03/13 22:12, Brian Campbell wrote:
So currently the base assertion document defines scope as an HTTP
parameter on the access token request message when using an assertion as
= a grant[1].  And that applies to both the SAML and JWT grants (perhaps<= br> that needs to be more clear?). Also RFC 6749 defines the scope parameter
= for the client credentials access token request[2], which similarly
applies to both SAML and JWT in the case of assertion client
authentication using the "client_credentials" grant type.

[1] http://tools.ietf.org/html/draft-ietf-oau= th-assertions-10#section-4.1
[2] http://tools.ietf.org/html/rfc6749#section-4.4.1


On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022
<Ad= am.Lewis@motorolasolutions.com
<mailto:Adam.Lewis@motorolasolutions.com>> wrote:

    Right ... thinking about this further I think the answer is "a= ll of
    the above."  If the JWT is a grant type then as you say i= t needs a
    scope param and optionally a client_id param.  I argued f= or the
    client_id param earlier since it could assist with HOK scenari= os
    once those further develop.

    But when the JWT is used as an AT then it will definitely requ= ire
    the scope as a claim.

    So I change my argument to "both" :)

    adam

    -----Original Message-----
    From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
    [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] On
    Behalf Of Sergey Beryozkin
    Sent: Friday, March 15, 2013 4:31 PM
    To: oauth@= ietf.org <mailto:= oauth@ietf.org>
    Subject: Re: [OAUTH-WG] JWT grant_type and client_id

    Hi
    On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
     > Hi John,
     >
     > I would like to argue that the scope should be a pa= rameter in the
    access
     > token request message, the same as it is for the RO= creds grant and
     > client creds grant type. This would keep it consist= ent with the core
     > OAuth grant types that talk directly to the token e= ndpoint.
     >
    Assuming the assertion is acting as a grant, then it is indeed= an access
    token request message, so IMHO it makes sense to get an outbou= nd scope
    parameter optionally supported which I guess will imply that t= he client
    id will also have to accompany it...

    Cheers, Sergey

     > Thoughts?
     >
     > adam
     >
     > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com
    <mailto:ve7jtb@ve7jtb.com>]
     > *Sent:* Friday, March 15, 2013 12:10 PM
     > *To:* Lewis Adam-CAL022
     > *Cc:* Brian Campbell; "WG <oauth@ietf.org
     > *Subject:* Re: [OAUTH-WG] JWT grant_type and client= _id
     >
     > The spec is a touch vague on that. I think the scop= es should be
    in the
     > assertion and the client can use the scopes outside= the assertion to
     > down-scope.
     >
     > Having a standard claim in JWT and SAML for passing= scopes is
    probably
     > useful as part of a profile.
     >
     > John B.
     >
     > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
     > <Adam.Lewis@motorolasolutions.com
    <mailto:Adam.Lewis@motorolasolutions.com>
=      > <mailto:Adam.Lewis@motorolasolutions.com
    <mailto:Adam.Lewis@motorolasolutions.com>>> w= rote:
     >
     >
     >
     > Hmmm, one more thought ... no scope?? The JWT is th= e grant, is it
    assumed
     > that the scope is conveyed as a claim within the to= ken? Otherwise it
     > would seem that it would require a scope.
     >
     > Thoughts?
     >
     > adam
     >
     > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com=
    <mailto:bcampbell@pingidentity.com>
     > <http://pingidentity.com>]
     > *Sent:*Thursday, March 14, 2013 4:44 PM
     > *To:*Lewis Adam-CAL022
     > *Cc:*Mike Jones; "WG <oauth@ietf.org <mailto:oauth@ietf.org>
     > <mailto:oauth@ietf.org
    <mailto:oauth@ietf.org>>>"@il06exr02.mot.com
    <htt= p://il06exr02.mot.com> <http://il06exr02.mot.com>

     > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_= id
     >
     > Yes, that is correct.
     >
     > I'm working on new revisions of the drafts that wil= l hopefully
    make that
     > point more clear.
     >
     > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022<= br>      > <Adam.Lewis@motorolasolutions.com
    <mailto:Adam.Lewis@motorolasolutions.com>
=      > <mailto:Adam.Lewis@motorolasolutions.com
    <mailto:Adam.Lewis@motorolasolutions.com>>> w= rote:
     >
     > Coming back to this...  am I correct in that c= lient_id is not
    required?    We are implementing this spec and want t= o make sure
    that we are doing it right.    By my understanding t= he only two
    parameters that are required in the JWT grant type are
    "urn:ietf:params:oauth:grant-type:jwt-bearer"   &n= bsp;and the assertion.
          Is this correct?
     >
     > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
    <mailto:Michael.Jones@microsoft.com>
     > <mailto:Michael.Jones@microsoft.com
    <mailto:Michael.Jones@microsoft.com>>]
     > *Sent:*Monday, February 18, 2013 6:58 PM
     > *To:*Lewis Adam-CAL022;oauth@ietf.org
    <mailto:Adam-CAL022%3Boauth@ietf.org> <mailto:oauth@ietf.org

    <mailto:oauth@ietf.org>>WG
     > *Subject:*RE: JWT grant_type and client_id
     >
     > The client_id value and the access token value are i= ndependent.
     >
     > -- Mike
     >
     > *From:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org><= br>      > <mailto:oauth-bounces@ietf.org
    <mailto:oauth-bounces@ietf.org>>[mailto:oauth-bounces@ietf.org<= div>
    <mailto:oauth-bounces@ietf.org>
     > <mailto:oauth-bounces@ietf.org
    <mailto:oauth-bounces@ietf.org>>]*On Behalf Of*Lewis Adam-= CAL022
     > *Sent:*Monday, February 18, 2013 2:50 PM
     > *To:*oauth@ietf.org <mailto:oauth@ietf.org>
    <mailto:oauth@ietf.org <mailto:oauth@ietf.org>>WG

     > *Subject:*[OAUTH-WG] JWT grant_type and client_id      >
     > Is there any guidance on the usage of client_id whe= n using the JWT
     > assertion profile as a grant type? draft-ietf-oauth= -jwt-bearer-04
    makes
     > no mention so I assume that it is not required ... b= ut it would be
     > necessary if using in conjunction with a HOK profil= e where the JWT
     > assertion is issued to - and may only be used by - t= he intended
    client.
     > Obviously this is straight forward enough, really I= 'm just
    looking to be
     > sure that I'm not missing anything.
     >
     > tx
     >
     > adam
     >
     >
     > ____________________________________________= ___
     > OAuth mailing list
     > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org      > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org



____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-EA8DCECB-D54D-44F5-9446-A68391108543-- From jricher@mitre.org Wed May 1 13:24:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A2A21F9ACB for ; Wed, 1 May 2013 13:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv88uAG+e35j for ; Wed, 1 May 2013 13:23:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1A721F9A1C for ; Wed, 1 May 2013 13:23:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BDE822260022 for ; Wed, 1 May 2013 16:23:50 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A0DE51F07CB for ; Wed, 1 May 2013 16:23:50 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 1 May 2013 16:23:50 -0400 Message-ID: <518179BB.5020308@mitre.org> Date: Wed, 1 May 2013 16:23:23 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org" References: <20130501202221.31117.90157.idtracker@ietfa.amsl.com> In-Reply-To: <20130501202221.31117.90157.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130501202221.31117.90157.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000302070507040602060307" X-Originating-IP: [129.83.31.58] Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-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: Wed, 01 May 2013 20:24:02 -0000 --------------000302070507040602060307 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I just rev'd the OAuth Introspection draft to cover some of the issues outstanding, such as alignment with JWT claim types, fields for token types (copied from revocation), and TLS restrictions. -- Justin -------- Original Message -------- Subject: New Version Notification for draft-richer-oauth-introspection-04.txt Date: Wed, 1 May 2013 13:22:21 -0700 From: To: Justin Richer A new version of I-D, draft-richer-oauth-introspection-04.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-introspection Revision: 04 Title: OAuth Token Introspection Creation date: 2013-05-01 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-04.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-04 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 --------------000302070507040602060307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I just rev'd the OAuth Introspection draft to cover some of the issues outstanding, such as alignment with JWT claim types, fields for token types (copied from revocation), and TLS restrictions.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-04.txt
Date: Wed, 1 May 2013 13:22:21 -0700
From: <internet-drafts@ietf.org>
To: Justin Richer <jricher@mitre.org> 


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

Filename:	 draft-richer-oauth-introspection
Revision:	 04
Title:		 OAuth Token Introspection
Creation date:	 2013-05-01
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-04.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-04

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


--------------000302070507040602060307-- From dick.hardt@gmail.com Wed May 1 14:12:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01C21F9B44 for ; Wed, 1 May 2013 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZC0Rl9Z1AZx for ; Wed, 1 May 2013 14:12:17 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5937421F9B2F for ; Wed, 1 May 2013 14:12:17 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id t10so1002742pdi.30 for ; Wed, 01 May 2013 14:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=yukM5PX54GJCtAlz011G4G9aV8QiXuKxVUrnYl54fCY=; b=EQtP9ULpdcFb2ygZsCzP8AxKULwvWZx+Pwhy3snkN3IKCpaeG1q/zx5sOXoUKvSqfA khx/AI55YtyHgZoLNsNidtnapR88dIl53kSCmoiC0qXGQkIo9DgppMxI2I2tVwMb8iiV HaWII3lmuSwkJVrWwUevWx42t/7v9Ombz8WbhuDqK3CBQqfDmHSkG1DeUY1ji8htGB9X 8Ej7ywhBlvz1byoeh8zHj/RnB+u6FlkRWHdeTY9w0osPyyZmwNM3pRXY3cR6X0aJDIPr uzyaxok7yOsPfiSQNJiFzd0pf0XjLlvrohfl5zsnISd7Vz3jSxdPAIY+hAXTAhxSzO8p uJnw== X-Received: by 10.67.3.2 with SMTP id bs2mr6800343pad.132.1367442736968; Wed, 01 May 2013 14:12:16 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPSA id sg4sm4337866pbc.7.2013.05.01.14.12.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 14:12:15 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> Date: Wed, 1 May 2013 14:12:14 -0700 To: O Auth WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 01 May 2013 21:12:23 -0000 "iss" and "aud" would be optional parameters in a JWE. These parameters = are in the payload, but since it is encrypted, the payload must be = decrypted before they can be read. Some times knowing these parameters = is required to be able to decrypt the payload =85 These would be additions to 9.3.1 in the JWT specification. Why "iss" is needed: Bob and Charlie each gave Alice a KID and a symmetric key to use to = verify and decrypt tokens from them.=20 The App and Alice share keys so Alice knows it is the App. The User authorizes Bob to give the App a token (which authorizes the = App to do something) The App gives the token to Alice. Since Alice indirectly received the token, the only way for Alice to = know who sent the token, is to look at the KID as the "iss" claim is = encrypted. If the "kid" values are GUIDs, then Alice can just look up = the "kid" and retrieve the associated symmetric key, and then decrypt = and verify the token and THEN see who sent it. If there is a collision = in KID values (Bon and Charlie gave the same KID for different keys), = then Alice will not know which symmetric key to use. Why "aud" is needed: Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and = symmetric key to Gwen.=20 Ellen and Gwen trust each other and know how to talk to each other. Gwen = does not know Dave. Ellen does not know Frank The App and Gwen share keys so Gwen knows it is the App. The User authorizes Dave to give the App a token Dave gives the token to Gwen (Dave does not have a relationship with = Ellen) Gwen now has a token that Ellen can decrypt and verify, but has no = method for knowing that Ellen can do that. The "aud" property would = allow Gwen to give the token to Ellen to decrypt and verify.= From Michael.Jones@microsoft.com Wed May 1 15:50:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9AA21F9B08 for ; Wed, 1 May 2013 15:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8t-dsZJKr8m for ; Wed, 1 May 2013 15:50:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1A21F9AE1 for ; Wed, 1 May 2013 15:50:22 -0700 (PDT) Received: from BL2FFO11FD014.protection.gbl (10.173.161.201) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.687.1; Wed, 1 May 2013 22:50:16 +0000 Received: from TK5EX14HUBC104.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.687.1 via Frontend Transport; Wed, 1 May 2013 22:50:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 1 May 2013 22:48:59 +0000 From: Mike Jones To: Dick Hardt , O Auth WG Thread-Topic: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE Thread-Index: AQHORrClkb9O5z8Zl0atyRk4AyEZ2Jjw52uw Date: Wed, 1 May 2013 22:48:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367708E10@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> In-Reply-To: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(13464002)(52604004)(377454001)(54356001)(23726002)(50986001)(16406001)(56816002)(74662001)(31966008)(47776003)(54316002)(74502001)(77982001)(33656001)(20776003)(59766001)(44976003)(79102001)(46102001)(74366001)(47976001)(6806003)(81542001)(69226001)(4396001)(81342001)(55846006)(49866001)(47736001)(66066001)(46406003)(50466002)(53806001)(56776001)(74706001)(76482001)(65816001)(47446002)(80022001)(51856001)(74876001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08331F819E Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 01 May 2013 22:50:28 -0000 Thanks for writing this, Dick. I think I understand your requirements and = why they exist. One question you didn't answer that will come up is whether these fields mu= st also be present in the JWT claims set if they're present in the JWE head= er. The logical answer to me seems to be something like "All claims MUST b= e present in the JWT Claims Set; specified claims MAY also be duplicated in= the JWE header, and if present there, must have exactly the same values as= in the JWT Claims Set." Is that the way that you imagined this working? -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Wednesday, May 01, 2013 2:12 PM To: O Auth WG Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter N= ames in JWE "iss" and "aud" would be optional parameters in a JWE. These parameters are= in the payload, but since it is encrypted, the payload must be decrypted b= efore they can be read. Some times knowing these parameters is required to = be able to decrypt the payload ... These would be additions to 9.3.1 in the JWT specification. Why "iss" is needed: Bob and Charlie each gave Alice a KID and a symmetric key to use to verify = and decrypt tokens from them.=20 The App and Alice share keys so Alice knows it is the App. The User authorizes Bob to give the App a token (which authorizes the App t= o do something) The App gives the token to Alice. Since Alice indirectly received the token, the only way for Alice to know = who sent the token, is to look at the KID as the "iss" claim is encrypted. = If the "kid" values are GUIDs, then Alice can just look up the "kid" and re= trieve the associated symmetric key, and then decrypt and verify the token = and THEN see who sent it. If there is a collision in KID values (Bon and Ch= arlie gave the same KID for different keys), then Alice will not know which= symmetric key to use. Why "aud" is needed: Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symm= etric key to Gwen.=20 Ellen and Gwen trust each other and know how to talk to each other. Gwen do= es not know Dave. Ellen does not know Frank The App and Gwen share keys so Gwen knows it is the App. The User authorizes Dave to give the App a token Dave gives the token to Gwen (Dave does not have a relationship with Ellen) Gwen now has a token that Ellen can decrypt and verify, but has no method f= or knowing that Ellen can do that. The "aud" property would allow Gwen to g= ive the token to Ellen to decrypt and verify. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Wed May 1 19:00:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4C721F9A56 for ; Wed, 1 May 2013 19:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6g1OVyaExrB for ; Wed, 1 May 2013 19:00:01 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id D915B21F9A54 for ; Wed, 1 May 2013 19:00:00 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bg2so71251pad.11 for ; Wed, 01 May 2013 19:00:00 -0700 (PDT) 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=9a6aq48ZAjqDXYh+Jl2AMEP6w0h2lWC9rwxDdXybUJ8=; b=FyA3RvYa8h5zUyhrtFYuhvK4ohfcEoftSDXVyoW43j4vMK+lVlWr1wVRd/Q9tCorvC tubfkLniFXLqVlApn0h9DXFsmK1z/qowMpnkaf00kA0ksMk8MzpZRrFXuCbHDIo05azz ujOk6YFXRXq53kArrppVoFm5lmdn9WmNbNKkkIRqtmdm23Zw/7XT0BEvL11ghUypN6qy CMdZDNHmVArCO2gTrB7UIQ/difJ1ZrJk6pGECWG2P7S0BlcLuv+Swy35Nh59+cV1Pb7U p4Cs1a4NLFZQ/Q1u92O+nYeEqLLaZ7CadVV7tMbw4MrDUsU8+MjwotoEy0/koOFWJH8f XdBQ== X-Received: by 10.66.254.225 with SMTP id al1mr7525858pad.111.1367460000383; Wed, 01 May 2013 19:00:00 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPSA id t1sm5948680pab.12.2013.05.01.18.59.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 18:59:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367708E10@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 1 May 2013 18:59:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> <4E1F6AAD24975D4BA5B168042967394367708E10@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: O Auth WG Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 02 May 2013 02:00:05 -0000 Hi Mike That answer makes the most sense to me as those values are often = required when processing a payload as well, and they should be = consistent. I'd be interested to hear any other opinions though! -- Dick On May 1, 2013, at 3:48 PM, Mike Jones = wrote: > Thanks for writing this, Dick. I think I understand your requirements = and why they exist. >=20 > One question you didn't answer that will come up is whether these = fields must also be present in the JWT claims set if they're present in = the JWE header. The logical answer to me seems to be something like = "All claims MUST be present in the JWT Claims Set; specified claims MAY = also be duplicated in the JWE header, and if present there, must have = exactly the same values as in the JWT Claims Set." >=20 > Is that the way that you imagined this working? >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Wednesday, May 01, 2013 2:12 PM > To: O Auth WG > Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header = Parameter Names in JWE >=20 > "iss" and "aud" would be optional parameters in a JWE. These = parameters are in the payload, but since it is encrypted, the payload = must be decrypted before they can be read. Some times knowing these = parameters is required to be able to decrypt the payload ... >=20 > These would be additions to 9.3.1 in the JWT specification. >=20 > Why "iss" is needed: >=20 > Bob and Charlie each gave Alice a KID and a symmetric key to use to = verify and decrypt tokens from them.=20 >=20 > The App and Alice share keys so Alice knows it is the App. >=20 > The User authorizes Bob to give the App a token (which authorizes the = App to do something) >=20 > The App gives the token to Alice. >=20 > Since Alice indirectly received the token, the only way for Alice to = know who sent the token, is to look at the KID as the "iss" claim is = encrypted. If the "kid" values are GUIDs, then Alice can just look up = the "kid" and retrieve the associated symmetric key, and then decrypt = and verify the token and THEN see who sent it. If there is a collision = in KID values (Bon and Charlie gave the same KID for different keys), = then Alice will not know which symmetric key to use. >=20 > Why "aud" is needed: >=20 > Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and = symmetric key to Gwen.=20 >=20 > Ellen and Gwen trust each other and know how to talk to each other. = Gwen does not know Dave. Ellen does not know Frank >=20 > The App and Gwen share keys so Gwen knows it is the App. >=20 > The User authorizes Dave to give the App a token >=20 > Dave gives the token to Gwen (Dave does not have a relationship with = Ellen) >=20 > Gwen now has a token that Ellen can decrypt and verify, but has no = method for knowing that Ellen can do that. The "aud" property would = allow Gwen to give the token to Ellen to decrypt and verify. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Thu May 2 08:15:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7287C21F8EF7 for ; Thu, 2 May 2013 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vEXeoVx6W2a for ; Thu, 2 May 2013 08:15:31 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 56A0621F8F13 for ; Thu, 2 May 2013 08:15:26 -0700 (PDT) Received: from mail-ia0-f199.google.com ([209.85.210.199]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUYKDBLuQ9eYQieEJzXh+bKBnVYQHxnY4@postini.com; Thu, 02 May 2013 08:15:26 PDT Received: by mail-ia0-f199.google.com with SMTP id t4so2556340iag.2 for ; Thu, 02 May 2013 08:15:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=ZVtKnMOqToppNkReLFaJfb4nqPiEQXc0aTKXEXXVn04=; b=Q6XKzfWHgcHylXSfiQzuWgUdVapsH+xXu3zAsx0kbkVpR9/OC1UcFKhrSjxqazNhJK Yu6rGYx/oAsIjxEzkPcnBldDNsvX2txbaMpgJDiqabVLvxzMdW7MwwHzOLMgDeinWdRf sfDeclvniqOJ/jVN/x684nMBR9QoIVnTmezLW2tvd/GhCaAVdF2ueVj94p7tKQIB3YCc 2mCOW+kstgxLnlJ+Y5cq4JQBZc8ckWN5IUbCvMHTPUZA3ukIlE8WURvNd49GZTAd99nE xkuHjlpUW+slAZyUaLGX85JgHrwWLYwKvezqS6CZoR9w3L6JAzuhA3xzxISWH70qaCFJ H4MQ== X-Received: by 10.50.180.197 with SMTP id dq5mr15028668igc.22.1367507715587; Thu, 02 May 2013 08:15:15 -0700 (PDT) X-Received: by 10.50.180.197 with SMTP id dq5mr15028664igc.22.1367507715425; Thu, 02 May 2013 08:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.146 with HTTP; Thu, 2 May 2013 08:14:45 -0700 (PDT) In-Reply-To: <10D5EF73-469E-4129-9622-ABE7B456E5B0@oracle.com> References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com> <59E470B10C4630419ED717AC79FCF9A9568A83EA@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A84A6@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A9568A8760@BY2PRD0411MB441.namprd04.prod.outlook.com> <51439320.9060401@gmail.com> <59E470B10C4630419ED717AC79FCF9A9568A87C1@BY2PRD0411MB441.namprd04.prod.outlook.com> <51483C49.4040503@gmail.com> <10D5EF73-469E-4129-9622-ABE7B456E5B0@oracle.com> From: Brian Campbell Date: Thu, 2 May 2013 09:14:45 -0600 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=14dae9340b739b67b304dbbdb37a X-Gm-Message-State: ALoCoQkK+BtAX5sHDhbo9JRb+rVOqAMnmpKn9+CMbHCCtGDEXpYHC5bDyEeYNeP7E1p1CLRVZy6/Zct2KlYrbzhSWM8ivvz6ev5Gu1VnjvvzbcHfop9PAi+dZliOro6slQdRgrfENOxu Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT grant_type and client_id X-BeenThere: oauth@ietf.org X-Mailman-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, 02 May 2013 15:15:35 -0000 --14dae9340b739b67b304dbbdb37a Content-Type: text/plain; charset=ISO-8859-1 Client authentication is optional. But I'm not sure I follow the question? On Wed, May 1, 2013 at 7:44 AM, Phil Hunt wrote: > I find the text confusing regarding client auth. > > "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint" > > It seems to suggest client auth is optional due to the MAY when in fact > it is just referring to the client_id identifier which is not authn. I fear > many have missed this subtle distinction. Or did you really intend > optionality for assertions? > > Phil > > On 2013-05-01, at 5:35, Brian Campbell wrote: > > Just trying to close the loop on this thread (six weeks later, sorry). New > drafts were published last month that (hopefully) have more clear text > about the treatment of client_id. And it's been removed from examples where > it's optional. > > http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html > > > On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin wrote: > >> Hi, >> >> Just one remark, the example in [1] shows "client_id"; IMHO it makes >> sense to clarify than in this context (where the assertion is used as a >> grant), it is optional as per: >> >> http://tools.ietf.org/html/**rfc6749#section-3.2.1 >> >> "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint" >> >> and otherwise >> >> http://tools.ietf.org/html/**rfc6749#section-2.3 >> >> dictates how the client authentication is done. >> >> By the way, my reading of the main spec's section 2.3 tells me that the >> only time one would use only "client_id" in the form payload is when the >> client secret is empty or perhaps the client is not in the possession of >> the secret. >> >> Does it make sense to completely drop a "client_id" parameter in the >> example at [1] in the assertion draft and use an example with a Basic >> authentication instead ? >> >> Thanks, Sergey >> >> >> On 15/03/13 22:12, Brian Campbell wrote: >> >>> So currently the base assertion document defines scope as an HTTP >>> parameter on the access token request message when using an assertion as >>> a grant[1]. And that applies to both the SAML and JWT grants (perhaps >>> that needs to be more clear?). Also RFC 6749 defines the scope parameter >>> for the client credentials access token request[2], which similarly >>> applies to both SAML and JWT in the case of assertion client >>> authentication using the "client_credentials" grant type. >>> >>> [1] http://tools.ietf.org/html/**draft-ietf-oauth-assertions-** >>> 10#section-4.1 >>> [2] http://tools.ietf.org/html/**rfc6749#section-4.4.1 >>> >>> >>> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 >>> >>> >> >>> wrote: >>> >>> Right ... thinking about this further I think the answer is "all of >>> the above." If the JWT is a grant type then as you say it needs a >>> scope param and optionally a client_id param. I argued for the >>> client_id param earlier since it could assist with HOK scenarios >>> once those further develop. >>> >>> But when the JWT is used as an AT then it will definitely require >>> the scope as a claim. >>> >>> So I change my argument to "both" :) >>> >>> adam >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org ] On >>> Behalf Of Sergey Beryozkin >>> Sent: Friday, March 15, 2013 4:31 PM >>> To: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] JWT grant_type and client_id >>> >>> Hi >>> On 15/03/13 20:40, Lewis Adam-CAL022 wrote: >>> > Hi John, >>> > >>> > I would like to argue that the scope should be a parameter in the >>> access >>> > token request message, the same as it is for the RO creds grant >>> and >>> > client creds grant type. This would keep it consistent with the >>> core >>> > OAuth grant types that talk directly to the token endpoint. >>> > >>> Assuming the assertion is acting as a grant, then it is indeed an >>> access >>> token request message, so IMHO it makes sense to get an outbound >>> scope >>> parameter optionally supported which I guess will imply that the >>> client >>> id will also have to accompany it... >>> >>> Cheers, Sergey >>> >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >>> ] >>> > *Sent:* Friday, March 15, 2013 12:10 PM >>> > *To:* Lewis Adam-CAL022 >>> > *Cc:* Brian Campbell; "WG >> >"@il06**exr02.mot.com< >>> http://il06exr02.mot.com> >>> > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > The spec is a touch vague on that. I think the scopes should be >>> in the >>> > assertion and the client can use the scopes outside the assertion >>> to >>> > down-scope. >>> > >>> > Having a standard claim in JWT and SAML for passing scopes is >>> probably >>> > useful as part of a profile. >>> > >>> > John B. >>> > >>> > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 >>> > >>> >>> > >>> > >>> >>> >>> >>> wrote: >>> > >>> > >>> > >>> > Hmmm, one more thought ... no scope?? The JWT is the grant, is it >>> assumed >>> > that the scope is conveyed as a claim within the token? Otherwise >>> it >>> > would seem that it would require a scope. >>> > >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*Brian Campbell [mailto:bcampbell@**pingidentity.com >>> > >>> > ] >>> > *Sent:*Thursday, March 14, 2013 4:44 PM >>> > *To:*Lewis Adam-CAL022 >>> > *Cc:*Mike Jones; "WG >>> > >> >>"@il0**6exr02.mot.com >>> >>> >>> > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > Yes, that is correct. >>> > >>> > I'm working on new revisions of the drafts that will hopefully >>> make that >>> > point more clear. >>> > >>> > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 >>> > >>> >>> > >>> > >>> >>> >>> >>> wrote: >>> > >>> > Coming back to this... am I correct in that client_id is not >>> required? We are implementing this spec and want to make sure >>> that we are doing it right. By my understanding the only two >>> parameters that are required in the JWT grant type are >>> "urn:ietf:params:oauth:grant-**type:jwt-bearer" and the >>> assertion. >>> Is this correct? >>> > >>> > *From:*Mike Jones [mailto:Michael.Jones@**microsoft.com >>> > >>> > >>> >>> >>] >>> > *Sent:*Monday, February 18, 2013 6:58 PM >>> > *To:*Lewis Adam-CAL022;oauth@ietf.org >>> > >>> >> >>> >WG >>> > *Subject:*RE: JWT grant_type and client_id >>> > >>> > The client_id value and the access token value are independent. >>> > >>> > -- Mike >>> > >>> > *From:*oauth-bounces@ietf.org >>> > >> >[mailto:oauth-bounces@ietf.**org >>> >>> >>> > >> >]*On Behalf Of*Lewis Adam-CAL022 >>> > *Sent:*Monday, February 18, 2013 2:50 PM >>> > *To:*oauth@ietf.org >>> >WG >>> >>> > *Subject:*[OAUTH-WG] JWT grant_type and client_id >>> > >>> > Is there any guidance on the usage of client_id when using the JWT >>> > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 >>> makes >>> > no mention so I assume that it is not required ... but it would be >>> > necessary if using in conjunction with a HOK profile where the JWT >>> > assertion is issued to - and may only be used by - the intended >>> client. >>> > Obviously this is straight forward enough, really I'm just >>> looking to be >>> > sure that I'm not missing anything. >>> > >>> > tx >>> > >>> > adam >>> > >>> > >>> > ______________________________**_________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >> >>> > >>> > https://www.ietf.org/mailman/**listinfo/oauth >>> > >>> > ______________________________**_________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >> >>> > >>> > https://www.ietf.org/mailman/**listinfo/oauth >>> > >>> > >>> > >>> > ______________________________**_________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/**listinfo/oauth >>> >>> ______________________________**_________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/oauth >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/oauth >>> >>> >>> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae9340b739b67b304dbbdb37a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Client authentication is optional.

But = I'm not sure I follow the question?


On Wed, May 1, 2013 at 7:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
I find the text confu= sing regarding client auth.
"A client MAY use the "client_id" request parameter to ident= ify itself
=A0when sending requests to the token endpoint"
=A0It seems to suggest = client auth is optional due to the MAY when in fact it is just referring to= the client_id identifier which is not authn. I fear many have missed this = subtle distinction. =A0Or did you really intend optionality for assertions?=

Phil

On 2013-05-01, at 5:35, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Just trying to close the loop on this thread (six wee= ks later, sorry). New drafts were published last month that (hopefully) hav= e more clear text about the treatment of client_id. And it's been remov= ed from examples where it's optional.

http://www.ietf.org/mail-archive/web/oauth/current/= msg11213.html


On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi,

Just one remark, the example in [1] shows "client_id"; IMHO it ma= kes sense to clarify than in this context (where the assertion is used as a= grant), it is optional as per:

http://tools.ietf.org/html/rfc6749#section-3.2.1

"A client MAY use the "client_id" request parameter to ident= ify itself
=A0when sending requests to the token endpoint"

and otherwise

http://tools.ietf.org/html/rfc6749#section-2.3

dictates how the client authentication is done.

By the way, my reading of the main spec's section 2.3 tells me that the= only time one would use only "client_id" in the form payload is = when the client secret is empty or perhaps the client is not in the possess= ion of the secret.

Does it make sense to completely drop a "client_id" parameter in = the example at [1] in the assertion draft and use an example with a Basic a= uthentication instead ?

Thanks, Sergey


On 15/03/13 22:12, Brian Campbell wrote:
So currently the base assertion document defines scope as an HTTP
parameter on the access token request message when using an assertion as a grant[1]. =A0And that applies to both the SAML and JWT grants (perhaps that needs to be more clear?). Also RFC 6749 defines the scope parameter for the client credentials access token request[2], which similarly
applies to both SAML and JWT in the case of assertion client
authentication using the "client_credentials" grant type.

[1] http://tools.ietf.org/html/draft-ietf-o= auth-assertions-10#section-4.1
[2] http://tools.ietf.org/html/rfc6749#section-4.4.1


On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022
<A= dam.Lewis@motorolasolutions.com
<mailto:Adam.Lewis@motorolasolutions.com>> wrote:

=A0 =A0 Right ... thinking about this further I think the answer is "a= ll of
=A0 =A0 the above." =A0If the JWT is a grant type then as you say it n= eeds a
=A0 =A0 scope param and optionally a client_id param. =A0I argued for the =A0 =A0 client_id param earlier since it could assist with HOK scenarios =A0 =A0 once those further develop.

=A0 =A0 But when the JWT is used as an AT then it will definitely require =A0 =A0 the scope as a claim.

=A0 =A0 So I change my argument to "both" :)

=A0 =A0 adam

=A0 =A0 -----Original Message-----
=A0 =A0 From: o= auth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
=A0 =A0 [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] On
=A0 =A0 Behalf Of Sergey Beryozkin
=A0 =A0 Sent: Friday, March 15, 2013 4:31 PM
=A0 =A0 To: oauth@ietf.= org <mailto:oaut= h@ietf.org>
=A0 =A0 Subject: Re: [OAUTH-WG] JWT grant_type and client_id

=A0 =A0 Hi
=A0 =A0 On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
=A0 =A0 =A0> Hi John,
=A0 =A0 =A0>
=A0 =A0 =A0> I would like to argue that the scope should be a parameter = in the
=A0 =A0 access
=A0 =A0 =A0> token request message, the same as it is for the RO creds g= rant and
=A0 =A0 =A0> client creds grant type. This would keep it consistent with= the core
=A0 =A0 =A0> OAuth grant types that talk directly to the token endpoint.=
=A0 =A0 =A0>
=A0 =A0 Assuming the assertion is acting as a grant, then it is indeed an a= ccess
=A0 =A0 token request message, so IMHO it makes sense to get an outbound sc= ope
=A0 =A0 parameter optionally supported which I guess will imply that the cl= ient
=A0 =A0 id will also have to accompany it...

=A0 =A0 Cheers, Sergey

=A0 =A0 =A0> Thoughts?
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com
=A0 =A0 <mailto:v= e7jtb@ve7jtb.com>]
=A0 =A0 =A0> *Sent:* Friday, March 15, 2013 12:10 PM
=A0 =A0 =A0> *To:* Lewis Adam-CAL022
=A0 =A0 =A0> *Cc:* Brian Campbell; "WG <oauth@ietf.org
=A0 =A0 =A0> *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> The spec is a touch vague on that. I think the scopes shoul= d be
=A0 =A0 in the
=A0 =A0 =A0> assertion and the client can use the scopes outside the ass= ertion to
=A0 =A0 =A0> down-scope.
=A0 =A0 =A0>
=A0 =A0 =A0> Having a standard claim in JWT and SAML for passing scopes = is
=A0 =A0 probably
=A0 =A0 =A0> useful as part of a profile.
=A0 =A0 =A0>
=A0 =A0 =A0> John B.
=A0 =A0 =A0>
=A0 =A0 =A0> On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
=A0 =A0 =A0> <Adam.Lewis@motorolasolutions.com
=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>
=A0 =A0 =A0> <mailto:Adam.Lewis@motorolasolutions.com

=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>>> wrote= :
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> Hmmm, one more thought ... no scope?? The JWT is the grant,= is it
=A0 =A0 assumed
=A0 =A0 =A0> that the scope is conveyed as a claim within the token? Oth= erwise it
=A0 =A0 =A0> would seem that it would require a scope.
=A0 =A0 =A0>
=A0 =A0 =A0> Thoughts?
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com =A0 =A0 <mailto:bcampbell@pingidentity.com>
=A0 =A0 =A0> <h= ttp://pingidentity.com>]
=A0 =A0 =A0> *Sent:*Thursday, March 14, 2013 4:44 PM
=A0 =A0 =A0> *To:*Lewis Adam-CAL022
=A0 =A0 =A0> *Cc:*Mike Jones; "WG <oauth@ietf.org <mailto:oauth@ietf.org>
=A0 =A0 =A0> <mailto:oauth@ietf.org
=A0 =A0 <mailto:oaut= h@ietf.org>>>"@il06exr02.mot.com
=A0 =A0 <http://i= l06exr02.mot.com> <http://il06exr02.mot.com>

=A0 =A0 =A0> *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> Yes, that is correct.
=A0 =A0 =A0>
=A0 =A0 =A0> I'm working on new revisions of the drafts that will ho= pefully
=A0 =A0 make that
=A0 =A0 =A0> point more clear.
=A0 =A0 =A0>
=A0 =A0 =A0> On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
=A0 =A0 =A0> <Adam.Lewis@motorolasolutions.com
=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>
=A0 =A0 =A0> <mailto:Adam.Lewis@motorolasolutions.com

=A0 =A0 <mailto:Adam.Lewis@motorolasolutions.com>>> wrote= :
=A0 =A0 =A0>
=A0 =A0 =A0> Coming back to this... =A0am I correct in that client_id is= not
=A0 =A0 required? =A0 =A0We are implementing this spec and want to make sur= e
=A0 =A0 that we are doing it right. =A0 =A0By my understanding the only two=
=A0 =A0 parameters that are required in the JWT grant type are
=A0 =A0 "urn:ietf:params:oauth:grant-type:jwt-bearer" =A0 = =A0and the assertion.
=A0 =A0 =A0 =A0 =A0 Is this correct?
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com
=A0 =A0 <mailto:Michael.Jones@microsoft.com>
=A0 =A0 =A0> <mailto:Michael.Jones@microsoft.com
=A0 =A0 <mailto:Michael.Jones@microsoft.com>>]
=A0 =A0 =A0> *Sent:*Monday, February 18, 2013 6:58 PM
=A0 =A0 =A0> *To:*Lewis Adam-CAL022;oauth@ietf.org
=A0 =A0 <mailto:Adam-CAL022%3Boauth@ietf.org> <mailto:oauth@ietf.org

=A0 =A0 <mailto:oaut= h@ietf.org>>WG
=A0 =A0 =A0> *Subject:*RE: JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> The client_id value and the access token value are independ= ent.
=A0 =A0 =A0>
=A0 =A0 =A0> -- Mike
=A0 =A0 =A0>
=A0 =A0 =A0> *From:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
=A0 =A0 =A0> <mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>>[mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>
=A0 =A0 =A0> <mailto:oauth-bounces@ietf.org
=A0 =A0 <mailto:oauth-bounces@ietf.org>>]*On Behalf Of*Lewis Adam-CAL0= 22
=A0 =A0 =A0> *Sent:*Monday, February 18, 2013 2:50 PM
=A0 =A0 =A0> *To:*oa= uth@ietf.org <mailto:oauth@ietf.org>
=A0 =A0 <mailto:oaut= h@ietf.org <mailto:oauth@ietf.org>>WG

=A0 =A0 =A0> *Subject:*[OAUTH-WG] JWT grant_type and client_id
=A0 =A0 =A0>
=A0 =A0 =A0> Is there any guidance on the usage of client_id when using = the JWT
=A0 =A0 =A0> assertion profile as a grant type? draft-ietf-oauth-jwt-bea= rer-04
=A0 =A0 makes
=A0 =A0 =A0> no mention so I assume that it is not required ... but it w= ould be
=A0 =A0 =A0> necessary if using in conjunction with a HOK profile where = the JWT
=A0 =A0 =A0> assertion is issued to - and may only be used by - the inte= nded
=A0 =A0 client.
=A0 =A0 =A0> Obviously this is straight forward enough, really I'm j= ust
=A0 =A0 looking to be
=A0 =A0 =A0> sure that I'm not missing anything.
=A0 =A0 =A0>
=A0 =A0 =A0> tx
=A0 =A0 =A0>
=A0 =A0 =A0> adam
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org> <mailto:OAuth@ietf.org

=A0 =A0 <mailto:OAut= h@ietf.org>>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org> <mailto:OAuth@ietf.org

=A0 =A0 <mailto:OAut= h@ietf.org>>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> OAuth mailing list
=A0 =A0 =A0> OAuth@i= etf.org <mailto:= OAuth@ietf.org>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/oauth

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





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





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

--14dae9340b739b67b304dbbdb37a-- From hannes.tschofenig@gmx.net Sun May 5 02:30:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0FA21F90AF for ; Sun, 5 May 2013 02:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agiIVBy1788B for ; Sun, 5 May 2013 02:30:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 47B9D21F8FE3 for ; Sun, 5 May 2013 02:30:38 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M21kz-1UJSis2E6l-00u3bl for ; Sun, 05 May 2013 11:30:37 +0200 Received: (qmail invoked by alias); 05 May 2013 09:30:36 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp029) with SMTP; 05 May 2013 11:30:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18bnTh1y5obuQMH3MDJeR9kxXFuR7Qjj5vv9Ntvj1 KgCMJ3aty95TDp Message-ID: <518626B8.5040606@gmx.net> Date: Sun, 05 May 2013 12:30:32 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Derek Atkins Subject: [OAUTH-WG] Working Group Management X-BeenThere: oauth@ietf.org X-Mailman-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, 05 May 2013 09:30:44 -0000 Hi all, I have been reading the discussions on the IETF mailing list about the IETF process and various people shared their views on how to work better in individual groups. I have been thinking whether we (as WG chairs) and our document authors / editors have done work in the way you guys have expected and, if not, maybe you have some suggestions on how we could improve our work style. Suggestions are welcome (also as private messages if you don't want to share your thoughts with the rest of the group). Ciao Hannes From hannes.tschofenig@gmx.net Sun May 5 02:38:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3C21F8D2E for ; Sun, 5 May 2013 02:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMof3jQzpYGw for ; Sun, 5 May 2013 02:38:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEFE21F8D27 for ; Sun, 5 May 2013 02:38:12 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LtTty-1UPCY31jLY-010xDV for ; Sun, 05 May 2013 11:38:11 +0200 Received: (qmail invoked by alias); 05 May 2013 09:38:11 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp035) with SMTP; 05 May 2013 11:38:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+WnJRsfgCWGK1wZEJuWHONCC22DNkQJjRZYKVjSr xkkWemmf46zyLj Message-ID: <5186287E.4020909@gmx.net> Date: Sun, 05 May 2013 12:38:06 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Milestones X-BeenThere: oauth@ietf.org X-Mailman-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, 05 May 2013 09:38:18 -0000 I have just looked at our WG milestones and need your feedback: * Mar 2013 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard --> I have asked the IESG secretary to mark it as DONE. * Apr 2013 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard * Apr 2013 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard --> We are behind schedule on this item and I suggest the following next steps: 1) WG review for 2 weeks (2 weeks because various folks are at the Internet Identity Workshop in Mountain View next week). 2) If review feedback indicates the documents are ready for the IESG we sent them to the IESG again. Jun 2013 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC --> Derek, as the document shepherd, knows the status of this work Jul 2013 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard --> The feedback at the last IETF meeting was good. We do, however, need to finalize the document. July is a realistic deadline, I think, but the document authors will have to propose a list of open issues. Aug 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard --> This document is pending the completion of the JOSE work. Is this date realistic? Aug 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard --> This document is pending the completion of the JOSE work. Is this date realistic? Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard --> Justin, do you think that this document can be completed in September or earlier? Ciao Hannes From hannes.tschofenig@gmx.net Sun May 5 02:41:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0F21F905B for ; Sun, 5 May 2013 02:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZYYi2ZwEigD for ; Sun, 5 May 2013 02:41:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 72A9F21F8FAC for ; Sun, 5 May 2013 02:41:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LgsnI-1UBP9537Zu-00oDbq for ; Sun, 05 May 2013 11:41:29 +0200 Received: (qmail invoked by alias); 05 May 2013 09:41:29 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 05 May 2013 11:41:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VqatifPTVeVmDMnfrIx2C4UWSe9edPWJ2QCy/zR YKzuaF6cskCHO6 Message-ID: <51862946.8080302@gmx.net> Date: Sun, 05 May 2013 12:41:26 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Assertion Drafts: Review by **19th May 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: Sun, 05 May 2013 09:41:35 -0000 Hi all after the IESG feedback on the assertion framework it was sent back to the working group and the document authors have updated the draft (and the SAML assertion document as well). We need to get the documents back to the IESG and I would like to ask you to review the documents by the **19th May 2013**. - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ - SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ Ciao Hannes From internet-drafts@ietf.org Sun May 5 12:45:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325E321F9731; Sun, 5 May 2013 12:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EIGP16bK7oM; Sun, 5 May 2013 12:45:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D06521F972F; Sun, 5 May 2013 12:45:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> Date: Sun, 05 May 2013 12:45:05 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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: Sun, 05 May 2013 19:45:06 -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 2.0 Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-10.txt Pages : 25 Date : 2013-05-05 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth 2.0 Clients at an Authorization Server and methods for the dynamically registered client to manage its registration. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Sun May 5 12:50:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D821F9728 for ; Sun, 5 May 2013 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFG0s65SOuMN for ; Sun, 5 May 2013 12:50:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5321F9724 for ; Sun, 5 May 2013 12:50:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2883B1F0A46; Sun, 5 May 2013 15:50:04 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 148921F032F; Sun, 5 May 2013 15:50:04 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Sun, 5 May 2013 15:50:03 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Milestones Thread-Index: AQHOSXRJchbV3G07MECKKQUzHT7C75j3Q5wA Date: Sun, 5 May 2013 19:50:03 +0000 Message-ID: <407E0C47-3E9F-4AA0-9413-B26901D46572@mitre.org> References: <5186287E.4020909@gmx.net> In-Reply-To: <5186287E.4020909@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.4.249] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Milestones X-BeenThere: oauth@ietf.org X-Mailman-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, 05 May 2013 19:50:13 -0000 >=20 > Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG= for consideration as a Proposed Standard >=20 > --> Justin, do you think that this document can be completed in September= or earlier? Earlier, I'd say. In my opinion, the document is feature complete and I hav= e no outstanding editor's notes to address. I've just uploaded draft -10 th= at addresses the latest round of comments, and I'd like people to read it t= hrough, comment, and most importantly, implement it to make sure it's sane.= I'm sure it could use the normal amount of last-minute polish of the langu= age throughout (particularly in the abstract, introduction, and security co= nsiderations sections), but overall I think that it is very ready. Once I g= et some thorough feedback from the WG here I think that -11 could even pote= ntially be the last call version. -- Justin= From jricher@mitre.org Sun May 5 12:52:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9DA21F9703 for ; Sun, 5 May 2013 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4UTIbvRgkMa for ; Sun, 5 May 2013 12:52:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 69E0221F96E6 for ; Sun, 5 May 2013 12:52:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 12A791F0A62 for ; Sun, 5 May 2013 15:52:22 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EEB1D1F0A5C for ; Sun, 5 May 2013 15:52:21 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Sun, 5 May 2013 15:52:21 -0400 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOScki5Sf7tCtsl0WcxmZ0zKLbDJj3Q5YA Date: Sun, 5 May 2013 19:52:20 +0000 Message-ID: <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> In-Reply-To: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.4.249] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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: Sun, 05 May 2013 19:52:28 -0000 Handful of minor changes in this revision, including tightening the languag= e around scopes and adding an absolute-URI based mechanism for extending to= ken_endpoint_auth_method (no registry, still). No normative changes beyond = removing an unreachable error state. (Thanks, Nov.) Please check the diffs,= we welcome feedback. I personally think this is really getting close to fi= nal. -- Justin On May 5, 2013, at 3:45 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-10.txt > Pages : 25 > Date : 2013-05-05 >=20 > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth 2.0 Clients at an Authorization Server and > methods for the dynamically registered client to manage its > registration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun May 5 22:19:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8918121F8D2C for ; Sun, 5 May 2013 22:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb5q29YOZ-qx for ; Sun, 5 May 2013 22:19:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42A21F8BE4 for ; Sun, 5 May 2013 22:19:38 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M1kqC-1UJTOs3Ju6-00tmie for ; Mon, 06 May 2013 07:19:36 +0200 Received: (qmail invoked by alias); 06 May 2013 05:19:36 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp028) with SMTP; 06 May 2013 07:19:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+CULwbZ/KCmI14h6ScjT37TlDBz0N6el4QZQrrLE KIQAxmGvYX5fOr Message-ID: <51873D65.5070909@gmx.net> Date: Mon, 06 May 2013 08:19:33 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Richer, Justin P." References: <5186287E.4020909@gmx.net> <407E0C47-3E9F-4AA0-9413-B26901D46572@mitre.org> In-Reply-To: <407E0C47-3E9F-4AA0-9413-B26901D46572@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Milestones X-BeenThere: oauth@ietf.org X-Mailman-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, 06 May 2013 05:19:44 -0000 Thanks for the quick response. Maybe we should issue a working group last call now already. It is not a mistake to finish documents earlier than expected ... On 05/05/2013 10:50 PM, Richer, Justin P. wrote: >> >> Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard >> >> --> Justin, do you think that this document can be completed in September or earlier? > > Earlier, I'd say. In my opinion, the document is feature complete and I have no outstanding editor's notes to address. I've just uploaded draft -10 that addresses the latest round of comments, and I'd like people to read it through, comment, and most importantly, implement it to make sure it's sane. I'm sure it could use the normal amount of last-minute polish of the language throughout (particularly in the abstract, introduction, and security considerations sections), but overall I think that it is very ready. Once I get some thorough feedback from the WG here I think that -11 could even potentially be the last call version. > > -- Justin > From hannes.tschofenig@gmx.net Sun May 5 23:51:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC0321F8E62 for ; Sun, 5 May 2013 23:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMBLJijfzpu8 for ; Sun, 5 May 2013 23:51:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 255A821F8D7A for ; Sun, 5 May 2013 23:51:02 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lkmp0-1Tz5Yo2GQ8-00aTRU for ; Mon, 06 May 2013 08:50:54 +0200 Received: (qmail invoked by alias); 06 May 2013 06:50:54 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp034) with SMTP; 06 May 2013 08:50:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WI9oyhfsWG7eyoN9gFvRb2Ei8MRZ5qmJ0ezy0+Q 6YPpCeyRVNI1QU Message-ID: <518752CB.8050408@gmx.net> Date: Mon, 06 May 2013 09:50:51 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 May 2013 06:51:07 -0000 This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 Because of the timing of the impending Internet Identity Workshop we are setting the call for **3 weeks**. Please have your comments in no later than May 27th. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Derek From jricher@mitre.org Mon May 6 08:39:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5421F9299 for ; Mon, 6 May 2013 08:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZMTQLWu1FFo for ; Mon, 6 May 2013 08:39:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6905821F9223 for ; Mon, 6 May 2013 08:39:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D90391F0409; Mon, 6 May 2013 11:39:44 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CAC841F03B6; Mon, 6 May 2013 11:39:44 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Mon, 6 May 2013 11:39:44 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOScki5Sf7tCtsl0WcxmZ0zKLbDJj3Q5YAgAADzoCAAUf0AA== Date: Mon, 6 May 2013 15:39:44 +0000 Message-ID: <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.35.124] Content-Type: text/plain; charset="us-ascii" Content-ID: <11F5D4437BF0B042BA69E9AA352E7C04@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 06 May 2013 15:39:50 -0000 In spite of what John seems to think, that dependency was never there. The = whole discovery process is related, but separate, from registration. It cou= ld happen using OIDC, it could happen with Bill Mills's LRDD link types, it= could happen with Nat's proposed HAL-based system, it could happen by the = developer going to the service provider's documentation page and reading a = bunch of text (which is what happens with large OAuth providers today) -- i= t ultimately doesn't matter.=20 And I think that the Dynamic Registration protocol that we have here is rob= ust against that kind of diversity. Let's take the token_endpoint_auth_meth= od parameter as an example. Let's say a client shows up to a service it's j= ust discovered -- through whatever means, we don't actually care. This clie= nt either has some idea of what auth methods the server supports (through a= discovery mechanism) or it doesn't. If it does, it will also know which me= thods it supports and it can pick one. If it doesn't, it will still know wh= ich methods it supports and will just pick one. The server will then take t= hat information and do one of three things: 1) Accept what the client proposes and use that. This is of course the idea= l situation where everybody gets what they want, and this can be brought ab= out more often by a good discovery process. 2) Reject what the client proposes with an error code (invalid_client_metad= ata would cover this). The client then has to re-register with a different = value or just give up because the two systems are using different auth meth= ods that can't be reconciled. 3) Ignore what the client proposes and return the server's preferred method= . The client can then, in turn: a) Accept what the server returns and use that, if it supports it. This i= s also ideal because everybody is happy again. b) Reject what the server returns and either try the registration again w= ith another value or give up. c) Ignore what the server returns and fail when doing a token request. Th= is would be a dumb thing for a dumb client to do.=20 Alternatively, the client could just not mention it and have the server dic= tate what method it will use, and the client will either accept, reject, or= ignore it. This process applies to every parameter in the system, from som= ething innocuous as the client's TOS uri to something as security-critical = as the redirect_uri (which gets its own special error message).=20 I think that the assumption of full automation for all clients to all serve= rs is a red herring in the OAuth world for the simple fact that the API tha= t's being accessed/protected isn't going to be universally compatible anywa= y. I agree fully that a well-specified service discovery is important and w= e should, as a working group, help figure out what that looks like. As ment= ioned above, several of us already are. But I don't think it's helpful to c= onflate the registration and discovery processes and turn them into some ki= nd of negotiation system. I think we can do a good job of making it widely = useful without that. -- Justin On May 5, 2013, at 1:05 PM, Phil Hunt wrote: > Justin, >=20 > Has the assumption of a discovery service defined by OIDC been removed? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >=20 >> Handful of minor changes in this revision, including tightening the lang= uage around scopes and adding an absolute-URI based mechanism for extending= token_endpoint_auth_method (no registry, still). No normative changes beyo= nd removing an unreachable error state. (Thanks, Nov.) Please check the dif= fs, we welcome feedback. I personally think this is really getting close to= final. >>=20 >> -- Justin >>=20 >> On May 5, 2013, at 3:45 PM, >> wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF. >>>=20 >>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>> Author(s) : Justin Richer >>> John Bradley >>> Michael B. Jones >>> Maciej Machulak >>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>> Pages : 25 >>> Date : 2013-05-05 >>>=20 >>> Abstract: >>> This specification defines an endpoint and protocol for dynamic >>> registration of OAuth 2.0 Clients at an Authorization Server and >>> methods for the dynamically registered client to manage its >>> registration. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From phil.hunt@oracle.com Mon May 6 11:56:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5194721F930C for ; Mon, 6 May 2013 11:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuYwfDiUVl+S for ; Mon, 6 May 2013 11:56:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0716521F90DF for ; Mon, 6 May 2013 11:56:45 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r46Iuile008931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 May 2013 18:56:45 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r46Iuh9H029815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 May 2013 18:56:44 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r46IuhI3029804; Mon, 6 May 2013 18:56:43 GMT Received: from dhcp-whq-twvpn-3-vpnpool-10-159-231-61.vpn.oracle.com (/10.159.231.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 May 2013 11:56:43 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> Date: Mon, 6 May 2013 11:56:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 06 May 2013 18:56:54 -0000 Justin, What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. I have also thought through, does it matter since it is optional? I = think it does. If servers just ignore the param most of the time, what = value is there? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: > In spite of what John seems to think, that dependency was never there. = The whole discovery process is related, but separate, from registration. = It could happen using OIDC, it could happen with Bill Mills's LRDD link = types, it could happen with Nat's proposed HAL-based system, it could = happen by the developer going to the service provider's documentation = page and reading a bunch of text (which is what happens with large OAuth = providers today) -- it ultimately doesn't matter.=20 >=20 > And I think that the Dynamic Registration protocol that we have here = is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >=20 > 1) Accept what the client proposes and use that. This is of course the = ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. > 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. > 3) Ignore what the client proposes and return the server's preferred = method. The client can then, in turn: > a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. > b) Reject what the server returns and either try the registration = again with another value or give up. > c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >=20 > Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >=20 > I think that the assumption of full automation for all clients to all = servers is a red herring in the OAuth world for the simple fact that the = API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >=20 > -- Justin >=20 > On May 5, 2013, at 1:05 PM, Phil Hunt > wrote: >=20 >> Justin, >>=20 >> Has the assumption of a discovery service defined by OIDC been = removed? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>=20 >>> Handful of minor changes in this revision, including tightening the = language around scopes and adding an absolute-URI based mechanism for = extending token_endpoint_auth_method (no registry, still). No normative = changes beyond removing an unreachable error state. (Thanks, Nov.) = Please check the diffs, we welcome feedback. I personally think this is = really getting close to final. >>>=20 >>> -- Justin >>>=20 >>> On May 5, 2013, at 3:45 PM, >>> wrote: >>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>> Author(s) : Justin Richer >>>> John Bradley >>>> Michael B. Jones >>>> Maciej Machulak >>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>> Pages : 25 >>>> Date : 2013-05-05 >>>>=20 >>>> Abstract: >>>> This specification defines an endpoint and protocol for dynamic >>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>> methods for the dynamically registered client to manage its >>>> registration. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From hannes.tschofenig@gmx.net Mon May 6 23:40:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3F21F851E for ; Mon, 6 May 2013 23:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCzdAfD7s97q for ; Mon, 6 May 2013 23:40:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9621F8FA5 for ; Mon, 6 May 2013 23:40:19 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M84Qp-1UMcxH1Y5R-00vcKx for ; Tue, 07 May 2013 08:40:18 +0200 Received: (qmail invoked by alias); 07 May 2013 06:40:18 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp024) with SMTP; 07 May 2013 08:40:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+inQuWcn+piEGyIunaXTuhfuMx4nCL9JVfppoJH nG2S+nJjppG5rw Message-ID: <5188A1CD.6010701@gmx.net> Date: Tue, 07 May 2013 09:40:13 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <51884195.6010706@stanford.edu> In-Reply-To: <51884195.6010706@stanford.edu> X-Forwarded-Message-Id: <51884195.6010706@stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Fwd: Wording feedback in draft 3 of draft-ietf-oauth-v2-http-mac X-BeenThere: oauth@ietf.org X-Mailman-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, 07 May 2013 06:40:25 -0000 Thanks for your feedback, Patrick. I forwarded your review comments to the IETF OAuth mailing list. Will discuss it there. -------- Original Message -------- Subject: Wording feedback in draft 3 Resent-To: hannes.tschofenig@gmx.net, jricher@mitre.org, wmills@yahoo-inc.com Date: Mon, 06 May 2013 16:49:41 -0700 From: Patrick Radtke To: draft-ietf-oauth-v2-http-mac@tools.ietf.org I'm not sure how this is usually done, but here is some feedback on wording that I found confusing. I didn't know where to look to determine if this feedback has already been given. > 128 Since a keyed message digest only provides integrity protection and > 129 data-origin authentication confidentiality protection can only be > 130 added by the usage of Transport Layer Security (TLS). What is the 'since' implying? Usually 'since' would be used to imply an action, but the rest of the sentence is just a statement. Maybe "Transport Layer Security (TLS) MAY be used to provide data-origin authentication confidentiality protection since a keyed message digest only provides integrity protection" > 323 The transport of the mac_key from the authorization server to the > 324 resource server is accomplished by conveying the encrypting mac_key > 325 inside the access token. The phrase 'encrypting mac_key' is confusing, maybe because its a typo? Is that suppose to be 'encrypted mac_key' or 'conveying the mac_key inside the encrypted access token'? > 591 the token). The content of the access token, in particular the > 592 audience field and the scope, MUST be verified as described in There is no reference after 'in'. -Patrick From jmandel@gmail.com Tue May 7 10:10:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA5A21F93FC for ; Tue, 7 May 2013 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVkui6TF6cbN for ; Tue, 7 May 2013 10:10:15 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD221F93F8 for ; Tue, 7 May 2013 10:10:14 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id o6so929609oag.16 for ; Tue, 07 May 2013 10:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=H3DIHLAxkdwU3wWEVIMwyS+h//VJY4qylAUEGvONCiQ=; b=whrRwBZmovSu5P7ja3cqfG20jJr3TDebbDwzMuBoaLZZXgcoMY5gd4tZTCf+dGsddu /qjlDoDN74PWZDxifJII4KeZhzOqdftrcMViAnTtpiOec/I1No1i2LvDfdraqNb+2Nuc UoTZpv8V7Gt29xShkXQJMY9iiz/SdXGrm5OHwv9KOemAB0uRifZFPBYXwBYHPeCPeOVF hofanEQrbpBL6gp95+L3UuOx00UZcziMaw/9UV9Hz2sz3z2HN5YwcCyz/zFcInIxKFkl /HOSAaIpQviZw+if1Lj1bFoi6A0zg6lc3p6vYhXf5qDsVIR0G7xETgkPktn7xdevAftk E4Lw== X-Received: by 10.60.134.147 with SMTP id pk19mr867830oeb.4.1367946604402; Tue, 07 May 2013 10:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.118.228 with HTTP; Tue, 7 May 2013 10:09:49 -0700 (PDT) In-Reply-To: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> From: Josh Mandel Date: Tue, 7 May 2013 10:09:49 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b41cc186d5db104dc23e33b Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 07 May 2013 17:10:20 -0000 --047d7b41cc186d5db104dc23e33b Content-Type: text/plain; charset=ISO-8859-1 As I understand it (corrections welcome!) rfc6749 says that public clients: 1. are defined functionally, as clients "incapable of maintaining the confidentiality of their credentials" [section 2.1] 2. "MAY establish a client authentication method" if the server allows. e.g. client password auth [section 2.3] Given 1 and 2, it's technical possible for a public client to be assigned a (not-so-)secret that it uses not for authentication per se, but merely to go through the motions of client password auth. (How) Does dyn-reg support the registration of a public client that (for whatever reason -- code re-use?) seeks to use a client authentication method? It seems to me that, given the current draft, a registration server couldn't tell such a client from a confidential client ( token_endpoint_auth_method, grant_types, and response_types would be indistinguishable). Is this use case out of scope? If so, the spec might benefit from a note to that effect. If not, an explicit flag at registration time (conveying the app's explicitly asserted "public" vs. "confidential" status) might help servers make better decisions. -Josh On Sun, May 5, 2013 at 12:45 PM, 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 2.0 Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-10.txt > Pages : 25 > Date : 2013-05-05 > > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth 2.0 Clients at an Authorization Server and > methods for the dynamically registered client to manage its > registration. > > > 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-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10 > > > 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 > --047d7b41cc186d5db104dc23e33b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I understand it (corrections welcome!) rfc67= 49 says that public clients:

1. =A0are= defined functionally, as clients "incapable of maintaining the confid= entiality of their credentials" [section 2.1]
2. =A0"MAY e= stablish a client authentication method" if the server allows. e.g. cl= ient password auth [section 2.3]

Given 1 and 2, it's technical possible for a public client to be assign= ed a (not-so-)secret that it uses not for authentication per se, but merely= to go through the motions of client password auth.=A0

(How) Does dyn-reg support the registration of a public cl= ient that (for whatever reason -- code re-use?) seeks to use a client authe= ntication method? It seems to me that, given the current draft, a registrat= ion server couldn't tell such a client from a confidential client =A0(<= span style=3D"color:rgb(0,0,0);font-size:1em">token_endpoint_auth_method,= =A0grant_types, and r= esponse_types would be indistinguishable). =A0

=
Is this use case = out of scope? =A0If so, the spec might benefit from a note to that effect.= =A0= =A0If not, an explicit flag at registration time (conveying the app's e= xplicitly asserted "public" vs. "confidential" status) = might help servers make better decisions.
=
=A0 -Josh

On Sun, May 5, 2013 at 12:45 PM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Web Authorization Protocol Working Grou= p of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : OAuth 2.0 Dynamic Client Regist= ration Protocol
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Justin Richer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Bradley
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Michael B. Jones
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Maciej Machulak
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-dyn-reg-10.txt =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 25
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-05

Abstract:
=A0 =A0This specification defines an endpoint and protocol for dynamic
=A0 =A0registration of OAuth 2.0 Clients at an Authorization Server and
=A0 =A0methods for the dynamically registered client to manage its
=A0 =A0registration.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-r= eg-10


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

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

--047d7b41cc186d5db104dc23e33b-- From jricher@mitre.org Tue May 7 13:55:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC3B21F86D6 for ; Tue, 7 May 2013 13:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLxy1FF25OPN for ; Tue, 7 May 2013 13:55:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07C21F85C3 for ; Tue, 7 May 2013 13:55:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94D4E227006B; Tue, 7 May 2013 16:55:39 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7791B227005D; Tue, 7 May 2013 16:55:39 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Tue, 7 May 2013 16:55:39 -0400 From: "Richer, Justin P." To: Josh Mandel Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOS0Wu5Sf7tCtsl0WcxmZ0zKLbDJj6dviA Date: Tue, 7 May 2013 20:55:38 +0000 Message-ID: <5FAB4732-821E-451F-97F0-868619075F7F@mitre.org> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.35.252] Content-Type: multipart/alternative; boundary="_000_5FAB4732821E451F97F0868619075F7Fmitreorg_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 07 May 2013 20:55:45 -0000 --_000_5FAB4732821E451F97F0868619075F7Fmitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A true public client doesn't have a client_secret or its equivalent, so it = would have token_endpoint_auth_method =3D none. A confidential client can't= use the implicit flow (since you can't send a client_secret to the auth en= dpoint), so there's a bit of overlap there. Would it be useful to have an explanatory paragraph or table to this effect= in the draft? I'm currently thinking that'd be a bit overkill, but I'd def= initely rather it be clear and unambiguous. -- Justin On May 7, 2013, at 10:09 AM, Josh Mandel > wrote: As I understand it (corrections welcome!) rfc6749 says that public clients: 1. are defined functionally, as clients "incapable of maintaining the conf= identiality of their credentials" [section 2.1] 2. "MAY establish a client authentication method" if the server allows. e.= g. client password auth [section 2.3] Given 1 and 2, it's technical possible for a public client to be assigned a= (not-so-)secret that it uses not for authentication per se, but merely to = go through the motions of client password auth. (How) Does dyn-reg support the registration of a public client that (for wh= atever reason -- code re-use?) seeks to use a client authentication method?= It seems to me that, given the current draft, a registration server couldn= 't tell such a client from a confidential client (token_endpoint_auth_meth= od, grant_types, and response_types would be indistinguishable). Is this use case out of scope? If so, the spec might benefit from a note t= o that effect. If not, an explicit flag at registration time (conveying th= e app's explicitly asserted "public" vs. "confidential" status) might help = servers make better decisions. -Josh On Sun, May 5, 2013 at 12:45 PM, > wrote: 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 2.0 Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-10.txt Pages : 25 Date : 2013-05-05 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth 2.0 Clients at an Authorization Server and methods for the dynamically registered client to manage its registration. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 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 --_000_5FAB4732821E451F97F0868619075F7Fmitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1FB24294A293E64CB736BEB3D63CEAD1@imc.mitre.org> Content-Transfer-Encoding: quoted-printable A true public client doesn't have a client_secret or its equivalent, so it = would have token_endpoint_auth_method =3D none. A confidential client can't= use the implicit flow (since you can't send a client_secret to the auth en= dpoint), so there's a bit of overlap there. 

Would it be useful to have an explanatory paragraph or table to this e= ffect in the draft? I'm currently thinking that'd be a bit overkill, but I'= d definitely rather it be clear and unambiguous.

 -- Justin

On May 7, 2013, at 10:09 AM, Josh Mandel <jmandel@gmail.com>
 wrote:

As I understand it (corrections welcome!) rfc6749 says that= public clients:

1.  are defined functionally, as clients "incapab= le of maintaining the confidentiality of their credentials" [section 2= .1]
2.  "MAY establi= sh a client authentication method" if the server allows. e.g. client p= assword auth [section 2.3]

Given 1 and 2, it's technical possible for a public client = to be assigned a (not-so-)secret that it uses not for authentication per se= , but merely to go through the motions of client password auth. 

(How) Does dyn-reg support the registration of a public cli= ent that (for whatever reason -- code re-use?) seeks to use a client authen= tication method? It seems to me that, given the current draft, a registrati= on server couldn't tell such a client from a confidential client  (token_e= ndpoint_auth_method, grant_typ= es, and response_types would be indistinguishable).  

Is this use case out of sc= ope?  If so, the spec might benefit from a note to that effect. <= /span> If not, an ex= plicit flag at registration time (conveying the app's explicitly asserted "public" vs. "confidential" status= ) might help servers make better decisions.

  -J= osh


On Sun, May 5, 2013 at 12:45 PM, <intern= et-drafts@ietf.org> wrote:

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 G= roup of the IETF.

        Title           : OAut= h 2.0 Dynamic Client Registration Protocol
        Author(s)       : Justin Richer<= br>                      = ;     John Bradley
                     = ;     Michael B. Jones
                     = ;     Maciej Machulak
        Filename        : draft-iet= f-oauth-dyn-reg-10.txt
        Pages           : 25         Date            := 2013-05-05

Abstract:
   This specification defines an endpoint and protocol for dynami= c
   registration of OAuth 2.0 Clients at an Authorization Server a= nd
   methods for the dynamically registered client to manage its    registration.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-r= eg-10


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

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

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

--_000_5FAB4732821E451F97F0868619075F7Fmitreorg_-- From asanso@adobe.com Thu May 9 02:53:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3145721F8B54 for ; Thu, 9 May 2013 02:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wazJ6LFS1gqY for ; Thu, 9 May 2013 02:53:44 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6421F8599 for ; Thu, 9 May 2013 02:53:43 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUYtyJw89V5D3z0Pe3SuWvJ2lXs81e35w@postini.com; Thu, 09 May 2013 02:53:44 PDT 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 r499rg99009359 for ; Thu, 9 May 2013 02:53:42 -0700 (PDT) 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 r499qxGY001029 for ; Thu, 9 May 2013 02:53:41 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 9 May 2013 02:53:37 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Thu, 9 May 2013 10:53:36 +0100 From: Antonio Sanso To: "oauth@ietf.org WG" Date: Thu, 9 May 2013 10:53:34 +0100 Thread-Topic: JWT spec Thread-Index: Ac5MmxLVX7jdFN4WTOKhKthgGPozCg== Message-ID: 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_A34392DA003F4B19A807B3EBD516BA68adobecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] JWT spec X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2013 09:53:49 -0000 --_000_A34392DA003F4B19A807B3EBD516BA68adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi *, the example plaintext in the JWT specification [0] has a "weird" JWT claims= Set: {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} The "http://example.com/is_root":true part looks a bit odd to me. Is it a t= ypo? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07#section-4= .1 --_000_A34392DA003F4B19A807B3EBD516BA68adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi *,

t= he example plaintext in the JWT specification [0] has a "weird" JWT claims = Set:

     {"iss":"joe",
      "exp":1300819380,
      "http://example.com/is_root":true}
The "http://example.com/is_root":true part looks a bit odd to me.= Is it a typo?

Regards

<= div>Antonio

= --_000_A34392DA003F4B19A807B3EBD516BA68adobecom_-- From hannes.tschofenig@gmx.net Thu May 9 04:22:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B2621F8E59 for ; Thu, 9 May 2013 04:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmovjg5DP-cr for ; Thu, 9 May 2013 04:21:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 396C121F8E56 for ; Thu, 9 May 2013 04:21:57 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lsdt9-1UP6LM06S9-012KUU for ; Thu, 09 May 2013 13:21:57 +0200 Received: (qmail invoked by alias); 09 May 2013 11:21:56 -0000 Received: from unknown (EHLO [10.72.209.52]) [193.1.64.8] by mail.gmx.net (mp035) with SMTP; 09 May 2013 13:21:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yZ113wysym9tEB1xrICqGRKmAv3ggM3m/eDzGVj cVdrlRu5HSGj2g Message-ID: <518B86D3.4010701@gmx.net> Date: Thu, 09 May 2013 14:21:55 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Antonio Sanso References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT spec X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2013 11:22:10 -0000 Hi Antonio, this parameter is supposed to show how the extension points works. Here is the text from the draft about how these extensions are supposed to work: Collision Resistant Namespace A namespace that allows names to be allocated in a manner such that they are highly unlikely to collide with other names. For instance, collision resistance can be achieved through administrative delegation of portions of the namespace or through use of collision-resistant name allocation functions. Examples of Collision Resistant Namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name. This text is a bit fuzzy. Ciao Hannes On 05/09/2013 12:53 PM, Antonio Sanso wrote: > Hi *, > > the example plaintext in the JWT specification [0] has a "weird" JWT > claims Set: > > {"iss":"joe", > "exp":1300819380, > "http://example.com/is_root":true} > > The "http://example.com/is_root":true part looks a bit odd to me. Is it > a typo? > > Regards > > Antonio > > [0] > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07#section-4.1 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Thu May 9 13:51:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868D421F8518 for ; Thu, 9 May 2013 13:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPn-Uxmpk2BY for ; Thu, 9 May 2013 13:51:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 70EB921F89A5 for ; Thu, 9 May 2013 13:51:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E6F32A50464; Thu, 9 May 2013 16:51:15 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2D6A52A50463; Thu, 9 May 2013 16:51:15 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Thu, 9 May 2013 16:51:15 -0400 From: "Richer, Justin P." To: Josh Mandel Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOS0Wu5Sf7tCtsl0WcxmZ0zKLbDJj6dviAgALM14CAAFaeAA== Date: Thu, 9 May 2013 20:51:15 +0000 Message-ID: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <5FAB4732-821E-451F-97F0-868619075F7F@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.117] Content-Type: multipart/alternative; boundary="_000_F86EB9C622354C109CE0DFD136936480mitreorg_" MIME-Version: 1.0 Cc: " WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 20:51:41 -0000 --_000_F86EB9C622354C109CE0DFD136936480mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So if that's the case -- you've got a client that can't keep a secret that = has a secret -- you do one of the normal auth methods (like client_secret_b= asic) and call it a day. I don't think it makes any sense, and the language= below is really less about client secrets and more about assertions and ot= her methods of authentication that otherwise "public" clients could use. Dy= nReg makes it so that the client_secret is now a runtime secret, so we're a= lready outside the core definitions of public/confidential clients anyway. -- Justin On May 9, 2013, at 8:41 AM, Josh Mandel > wrote: > A true public client doesn't have a client_secret or its equivalent, so i= t would have If this is the case, then my premise #2 is wrong -- and in that case my c= oncern about dynamic registration disappears. But if so: what is the quote= d bit of 2.3 *supposed* to indicate? (If not that a public client might, i= n some scenarios, be given a client_secret with the explicit expectation th= at it won't be kept secret and the stipulation that it mustn't be relied up= on for authentication... ) Thanks! - Josh > On May 7, 2013, at 10:09 AM, Josh Mandel > > wrote: > >> As I understand it (corrections welcome!) rfc6749 says that public clien= ts: >> >> 1. are defined functionally, as clients "incapable of maintaining the c= onfidentiality of their credentials" [section 2.1] >> 2. "MAY establish a client authentication method" if the server allows.= e.g. client password auth [section 2.3] >> >> Given 1 and 2, it's technical possible for a public client to be assigne= d a (not-so-)secret that it uses not for authentication per se, but merely = to go through the motions of client password auth. >> >> (How) Does dyn-reg support the registration of a public client that (for= whatever reason -- code re-use?) seeks to use a client authentication meth= od? It seems to me that, given the current draft, a registration server cou= ldn't tell such a client from a confidential client (token_endpoint_auth_m= ethod, grant_types, and response_types would be indistinguishable). >> >> Is this use case out of scope? If so, the spec might benefit from a not= e to that effect. If not, an explicit flag at registration time (conveying= the app's explicitly asserted "public" vs. "confidential" status) might he= lp servers make better decisions. >> >> -Josh >> >> >> On Sun, May 5, 2013 at 12:45 PM, > wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. >>> >>> Title : OAuth 2.0 Dynamic Client Registration Protoco= l >>> Author(s) : Justin Richer >>> John Bradley >>> Michael B. Jones >>> Maciej Machulak >>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>> Pages : 25 >>> Date : 2013-05-05 >>> >>> Abstract: >>> This specification defines an endpoint and protocol for dynamic >>> registration of OAuth 2.0 Clients at an Authorization Server and >>> methods for the dynamically registered client to manage its >>> registration. >>> >>> >>> 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-10 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>> >>> >>> 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 > > --_000_F86EB9C622354C109CE0DFD136936480mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable So if that's the case -- you've got a client that can't keep a secret that = has a secret -- you do one of the normal auth methods (like client_secret_b= asic) and call it a day. I don't think it makes any sense, and the language= below is really less about client secrets and more about assertions and other methods of authentication that= otherwise "public" clients could use. DynReg makes it so that th= e client_secret is now a runtime secret, so we're already outside the core = definitions of public/confidential clients anyway.

 -- Justin

On May 9, 2013, at 8:41 AM, Josh Mandel <jmandel@gmail.com>
 wrote:

> A true public client doesn't have a client_secret or it= s equivalent, so it would have

If this is the case,  then my premise #2 is wrong -- an= d in that case my  concern about dynamic registration disappears. = ; But if so: what is the quoted bit of 2.3 *supposed* to indicate? (If not = that a public client might,  in some scenarios, be given a client_secret with the explicit expectation that it won't be kept = secret and the stipulation that it mustn't be relied upon for authenticatio= n... )

Thanks!

  - Josh

> On May 7, 2013, at 10:09 AM, Josh Mandel <jmandel@gmail.com>
>  wrote:
>
>> As I understand it (corrections welcome!) rfc6749 says that public= clients:
>>
>> 1.  are defined functionally, as clients "incapable of m= aintaining the confidentiality of their credentials" [section 2.1]
>> 2.  "MAY establish a client authentication method" = if the server allows. e.g. client password auth [section 2.3]
>>
>> Given 1 and 2, it's technical possible for a public client to be a= ssigned a (not-so-)secret that it uses not for authentication per se, but m= erely to go through the motions of client password auth. 
>>
>> (How) Does dyn-reg support the registration of a public client tha= t (for whatever reason -- code re-use?) seeks to use a client authenticatio= n method? It seems to me that, given the current draft, a registration serv= er couldn't tell such a client from a confidential client  (token_endpoint_auth_method, grant_types, a= nd response_types would be indistinguishable).  
>>
>> Is this use case out of scope?  If so, the spec might benefit= from a note to that effect.  If not, an explicit flag at registr= ation time (conveying the app's explicitly asserted "public" vs. = "confidential" status) might help servers make better decisions.<= br> >>
>>   -Josh
>>
>>
>> On Sun, May 5, 2013 at 12:45 PM, <internet-drafts@ietf.org> wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
>>>  This draft is a work item of the Web Authorization Proto= col Working Group of the IETF.
>>>
>>>         Title         =   : OAuth 2.0 Dynamic Client Registration Protocol
>>>         Author(s)       : J= ustin Richer
>>>                  =         John Bradley
>>>                  =         Michael B. Jones
>>>                  =         Maciej Machulak
>>>         Filename       &nbs= p;: draft-ietf-oauth-dyn-reg-10.txt
>>>         Pages         =   : 25
>>>         Date         &= nbsp;  : 2013-05-05
>>>
>>> Abstract:
>>>    This specification defines an endpoint and protoc= ol for dynamic
>>>    registration of OAuth 2.0 Clients at an Authoriza= tion Server and
>>>    methods for the dynamically registered client to = manage its
>>>    registration.
>>>
>>>
>>> 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-10
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10=
>>>
>>>
>>> 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://ww= w.ietf.org/mailman/listinfo/oauth
>
>


--_000_F86EB9C622354C109CE0DFD136936480mitreorg_-- From phil.hunt@oracle.com Thu May 9 14:44:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E273821F8EBC for ; Thu, 9 May 2013 14:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU6+yCsyDwOF for ; Thu, 9 May 2013 14:44:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A93B021F8EAE for ; Thu, 9 May 2013 14:44:24 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49LiMpM002839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 21:44:23 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49LiLRF002402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 21:44:22 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49LiL6F002383; Thu, 9 May 2013 21:44:21 GMT Received: from dhcp-whq-twvpn-2-vpnpool-10-159-169-191.vpn.oracle.com (/10.159.169.191) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 14:44:21 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> Date: Thu, 9 May 2013 14:44:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 21:44:30 -0000 Justin, Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-06, at 11:56 AM, Phil Hunt wrote: > Justin, >=20 > What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >=20 > Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >=20 > I have also thought through, does it matter since it is optional? I = think it does. If servers just ignore the param most of the time, what = value is there? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >=20 >> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>=20 >> And I think that the Dynamic Registration protocol that we have here = is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>=20 >> 1) Accept what the client proposes and use that. This is of course = the ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. >> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >> 3) Ignore what the client proposes and return the server's preferred = method. The client can then, in turn: >> a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. >> b) Reject what the server returns and either try the registration = again with another value or give up. >> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>=20 >> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>=20 >> I think that the assumption of full automation for all clients to all = servers is a red herring in the OAuth world for the simple fact that the = API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>=20 >> -- Justin >>=20 >> On May 5, 2013, at 1:05 PM, Phil Hunt >> wrote: >>=20 >>> Justin, >>>=20 >>> Has the assumption of a discovery service defined by OIDC been = removed? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>=20 >>>> Handful of minor changes in this revision, including tightening the = language around scopes and adding an absolute-URI based mechanism for = extending token_endpoint_auth_method (no registry, still). No normative = changes beyond removing an unreachable error state. (Thanks, Nov.) = Please check the diffs, we welcome feedback. I personally think this is = really getting close to final. >>>>=20 >>>> -- Justin >>>>=20 >>>> On May 5, 2013, at 3:45 PM, >>>> wrote: >>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>> Author(s) : Justin Richer >>>>> John Bradley >>>>> Michael B. Jones >>>>> Maciej Machulak >>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>> Pages : 25 >>>>> Date : 2013-05-05 >>>>>=20 >>>>> Abstract: >>>>> This specification defines an endpoint and protocol for dynamic >>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>> methods for the dynamically registered client to manage its >>>>> registration. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu May 9 14:52:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6021F8F17 for ; Thu, 9 May 2013 14:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY65dEbBP-47 for ; Thu, 9 May 2013 14:51:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9394621F8EB5 for ; Thu, 9 May 2013 14:51:38 -0700 (PDT) Received: from BN1BFFO11FD020.protection.gbl (10.58.52.201) by BN1AFFO11HUB031.protection.gbl (10.58.52.141) with Microsoft SMTP Server (TLS) id 15.0.687.1; Thu, 9 May 2013 21:51:37 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD020.mail.protection.outlook.com (10.58.53.80) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Thu, 9 May 2013 21:51:36 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 9 May 2013 21:51:20 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOSiYtvANLDf9vyU+N0DGZfz8B4Zj9aXWg Date: Thu, 9 May 2013 21:51:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367716D6D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <518752CB.8050408@gmx.net> In-Reply-To: <518752CB.8050408@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(41574002)(199002)(189002)(377454002)(16406001)(50466002)(55846006)(56816002)(15202345002)(74662001)(56776001)(74502001)(54316002)(46102001)(76482001)(59766001)(77982001)(66066001)(74706001)(74876001)(54356001)(6806003)(65816001)(46406003)(79102001)(80022001)(74366001)(53806001)(51856001)(47976001)(23726002)(4396001)(81542001)(50986001)(63696002)(69226001)(33656001)(47446002)(47776003)(31966008)(20776003)(49866001)(47736001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB031; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08417837C5 Subject: Re: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2013 21:52:01 -0000 I believe that the spec is fine either as-is, or with the addition of a reg= istry for token_endpoint_auth_method values. I'd slightly prefer the regis= try but wouldn't object if it were not added. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Sunday, May 05, 2013 11:51 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 Because of the timing of the impending Internet Identity Workshop we are se= tting the call for **3 weeks**. Please have your comments in no later than May 27th. Do remember to send a note in if you have read the document and have no oth= er comments other than "its ready to go" - we need those as much as we need= "I found a problem". Thanks! Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu May 9 14:57:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB921F9239 for ; Thu, 9 May 2013 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqR70YgW+TxC for ; Thu, 9 May 2013 14:57:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95321F85CC for ; Thu, 9 May 2013 14:57:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A1D72260089; Thu, 9 May 2013 17:57:06 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EE3EA2260087; Thu, 9 May 2013 17:57:05 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Thu, 9 May 2013 17:57:05 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOScki5Sf7tCtsl0WcxmZ0zKLbDJj3Q5YAgAADzoCAAUf0AIAE2dlWgABGDIA= Date: Thu, 9 May 2013 21:57:05 +0000 Message-ID: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 21:57:11 -0000 Part of my argument for leaving this parameter in is exactly the use case t= hat you're saying: the client doesn't tell the server anything but the serv= er tells the client what it must use to authenticate. That's already possib= le using what's there. But I'm loathe to pull out this particular piece of = metadata as non-parallel and separate from the rest of the parameters.=20 The whole negotiation for this or any other parameter can happen at least p= artially out of band, for instance as part of the discovery process. In Blu= e Button+ (reference for others, here: http://blue-button.github.io/blue-bu= tton-plus-pull/), you could either pre-register it or you could do it per-i= nstance. You'd probably pre-register this parameter in most cases though be= cause the nature of the app's capabilities won't really change.=20 What I think this parameter gives you is a *chance* for things to go right = or stop early before they go horribly wrong later in the process where the = stakes are higher. All of the if-then steps I listed out below still exist = if the client can't tell its preferred auth method to the server in-band du= ring registration, the decisions just happen at a different times where it'= s harder to recover programmatically. And since it's an optional parameter = on both sides, people who don't want to deal with the logic to process it d= on't have to do anything with it. -- Justin On May 9, 2013, at 2:44 PM, Phil Hunt wrote: > Justin, >=20 > Just to progress towards resolving this issue, what I would like to under= stand is how specifying authentication type makes things simpler or more in= ter-operable. I'm concerned that the logic you proposed early in the thread= is a lot more complexity. I would prefer just having the server tell the = client what authentication it MUST use. >=20 > As an alternative, the negotiation for credential method/type could occur= during the initial developer registration of the app. As in your "blue bu= tton" health case (did I remember that right), the initial registration JWT= would be used in the dynamic registration and allow the registration serve= r to observe any previously negotiated client preferences OOB of this spec.= Or, are you saying that individual instances have some need to change aut= hentication types on a per deployment basis independent of what the associa= ted authorization server wants them to use? If so what is it? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >=20 >> Justin, >>=20 >> What you describe, though good intentioned, seems like a lot of complexi= ty without getting an actual benefit. I would rather not have token_endpoin= t_auth_method at all. >>=20 >> Think about someone writing a general purpose SCIM client or OIDC client= . Site as uses method 1 and 2, site b supports 2,3 and 4. Site c only 5 a= nd 6. So if each site is willing to negotiate authn, how has this develope= r's coding been reduced? The developer will end up having to implement all = popular methods regardless of discovery or the ability of the client to sel= ect. In fact, they have to do all the logic you describe below AND implemen= t all methods. >>=20 >> I have also thought through, does it matter since it is optional? I thi= nk it does. If servers just ignore the param most of the time, what value i= s there? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>=20 >>> In spite of what John seems to think, that dependency was never there. = The whole discovery process is related, but separate, from registration. It= could happen using OIDC, it could happen with Bill Mills's LRDD link types= , it could happen with Nat's proposed HAL-based system, it could happen by = the developer going to the service provider's documentation page and readin= g a bunch of text (which is what happens with large OAuth providers today) = -- it ultimately doesn't matter.=20 >>>=20 >>> And I think that the Dynamic Registration protocol that we have here is= robust against that kind of diversity. Let's take the token_endpoint_auth_= method parameter as an example. Let's say a client shows up to a service it= 's just discovered -- through whatever means, we don't actually care. This = client either has some idea of what auth methods the server supports (throu= gh a discovery mechanism) or it doesn't. If it does, it will also know whic= h methods it supports and it can pick one. If it doesn't, it will still kno= w which methods it supports and will just pick one. The server will then ta= ke that information and do one of three things: >>>=20 >>> 1) Accept what the client proposes and use that. This is of course the = ideal situation where everybody gets what they want, and this can be brough= t about more often by a good discovery process. >>> 2) Reject what the client proposes with an error code (invalid_client_m= etadata would cover this). The client then has to re-register with a differ= ent value or just give up because the two systems are using different auth = methods that can't be reconciled. >>> 3) Ignore what the client proposes and return the server's preferred me= thod. The client can then, in turn: >>> a) Accept what the server returns and use that, if it supports it. This= is also ideal because everybody is happy again. >>> b) Reject what the server returns and either try the registration again= with another value or give up. >>> c) Ignore what the server returns and fail when doing a token request. = This would be a dumb thing for a dumb client to do.=20 >>>=20 >>> Alternatively, the client could just not mention it and have the server= dictate what method it will use, and the client will either accept, reject= , or ignore it. This process applies to every parameter in the system, from= something innocuous as the client's TOS uri to something as security-criti= cal as the redirect_uri (which gets its own special error message).=20 >>>=20 >>> I think that the assumption of full automation for all clients to all s= ervers is a red herring in the OAuth world for the simple fact that the API= that's being accessed/protected isn't going to be universally compatible a= nyway. I agree fully that a well-specified service discovery is important a= nd we should, as a working group, help figure out what that looks like. As = mentioned above, several of us already are. But I don't think it's helpful = to conflate the registration and discovery processes and turn them into som= e kind of negotiation system. I think we can do a good job of making it wid= ely useful without that. >>>=20 >>> -- Justin >>>=20 >>> On May 5, 2013, at 1:05 PM, Phil Hunt >>> wrote: >>>=20 >>>> Justin, >>>>=20 >>>> Has the assumption of a discovery service defined by OIDC been removed= ? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>=20 >>>>> Handful of minor changes in this revision, including tightening the l= anguage around scopes and adding an absolute-URI based mechanism for extend= ing token_endpoint_auth_method (no registry, still). No normative changes b= eyond removing an unreachable error state. (Thanks, Nov.) Please check the = diffs, we welcome feedback. I personally think this is really getting close= to final. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On May 5, 2013, at 3:45 PM, >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>>>>> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>>>>>=20 >>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>> Author(s) : Justin Richer >>>>>> John Bradley >>>>>> Michael B. Jones >>>>>> Maciej Machulak >>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>> Pages : 25 >>>>>> Date : 2013-05-05 >>>>>>=20 >>>>>> Abstract: >>>>>> This specification defines an endpoint and protocol for dynamic >>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>> methods for the dynamically registered client to manage its >>>>>> registration. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Thu May 9 15:17:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01DE21F8F3E for ; Thu, 9 May 2013 15:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sMA68+5bDJF for ; Thu, 9 May 2013 15:17:09 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C15F521F89E8 for ; Thu, 9 May 2013 15:17:09 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id l25so3852791iad.32 for ; Thu, 09 May 2013 15:17:09 -0700 (PDT) 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=Wat8SVQkYsg1HCQg/c9ItiFOK4aDDPd7+aHKO+PqTc8=; b=Fo6qblTmmyaKj6ASTGwaQt8b9sZNyTTIQwDJ5TIAIHZHGSmKu+OvW2iesyQiyuuPRe hnEfuqLNeRBMsDzeV/yK2HC2ffv/33YcXbBe4nVNlV73B0RYtbJ7p2IDm2uQRzZyLwFP cDncoyPv4qrFNmVFqaTXngP9neWQU8+xgp491xfy3xyKExGJrZZNvKGFYvNZmuS0vuNx 18nLGasAzYakOWzGWN+mKkMHab0Q23J+G/CcwjwkzBGnrEaAkp7MZj7IBvcd28aaMHSD SGpPTuBU44RiceumkXDGT7xyfO7xfBh9NyOmGM4S6bI57DQajF3+0UkewXQtzXqFeNBT 6dPg== X-Received: by 10.50.128.227 with SMTP id nr3mr55270igb.24.1368137829186; Thu, 09 May 2013 15:17:09 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id j7sm592869igt.1.2013.05.09.15.17.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 15:17:06 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7F0053E8-A5B4-4642-8299-59C6FE6B930B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Thu, 9 May 2013 15:17:03 -0700 Message-Id: <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkKlNvtsVsNsJ94+CYXScei8PfHhrEZLVDtbD57XLirt81Q2+BoCSNwiVbWO2uSYpDuvKx6 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 22:17:11 -0000 --Apple-Mail=_7F0053E8-A5B4-4642-8299-59C6FE6B930B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The client needs to be able to say only use a particular auth method to = disallow the Authorization server from providing a weaker method to an = attacker. =20 This is a required parameter to allow a Authorization server to support = high and low LoA clients dynamically. John B. On 2013-05-09, at 2:44 PM, Phil Hunt wrote: > Justin, >=20 > Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >=20 > As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >=20 >> Justin, >>=20 >> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>=20 >> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>=20 >> I have also thought through, does it matter since it is optional? I = think it does. If servers just ignore the param most of the time, what = value is there? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>=20 >>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>=20 >>> And I think that the Dynamic Registration protocol that we have here = is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>=20 >>> 1) Accept what the client proposes and use that. This is of course = the ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. >>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>> 3) Ignore what the client proposes and return the server's preferred = method. The client can then, in turn: >>> a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. >>> b) Reject what the server returns and either try the registration = again with another value or give up. >>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>=20 >>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>=20 >>> I think that the assumption of full automation for all clients to = all servers is a red herring in the OAuth world for the simple fact that = the API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>>=20 >>> -- Justin >>>=20 >>> On May 5, 2013, at 1:05 PM, Phil Hunt >>> wrote: >>>=20 >>>> Justin, >>>>=20 >>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>=20 >>>>> Handful of minor changes in this revision, including tightening = the language around scopes and adding an absolute-URI based mechanism = for extending token_endpoint_auth_method (no registry, still). No = normative changes beyond removing an unreachable error state. (Thanks, = Nov.) Please check the diffs, we welcome feedback. I personally think = this is really getting close to final. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On May 5, 2013, at 3:45 PM, >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>> Author(s) : Justin Richer >>>>>> John Bradley >>>>>> Michael B. Jones >>>>>> Maciej Machulak >>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>> Pages : 25 >>>>>> Date : 2013-05-05 >>>>>>=20 >>>>>> Abstract: >>>>>> This specification defines an endpoint and protocol for dynamic >>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>> methods for the dynamically registered client to manage its >>>>>> registration. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=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=_7F0053E8-A5B4-4642-8299-59C6FE6B930B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjIxNzAzWjAjBgkqhkiG9w0BCQQxFgQUhfG4D8GR ltYmiBM8fJ1BlDF8c7gwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAigf9GD1FT1+a5QH3JZhdi863TQvgM5Pu09qyK3cR bq2XLQBwG+TCihOkmY1Ytv1FVbFpPswf80Q8ZHI3nn6JdxXGS84XoO72qomCu+VH53SkqXk+dGbK ya32j6HjGsF1IyRocPibSbQsXhchokGNTSdY9IrPDVw3ndO7FwAg1WdgPNCCjN2s7jaLq0J5EUK9 ye0Jcx1dx24A1cyHhWnpUC3+uBHJOGBEn9uXiHdpZ09W9NAs6ku42cn9ONVWd+M9boTvcfM2TS2F GIA5TokY2hEa4Hf7vCsOGKbG9FX5JPqe2EBg0OmHkw1FEh9J5or1pTAkXpqEs7QhrcRKAs/3bwAA AAAAAA== --Apple-Mail=_7F0053E8-A5B4-4642-8299-59C6FE6B930B-- From phil.hunt@oracle.com Thu May 9 15:32:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2421F8D8E for ; Thu, 9 May 2013 15:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrc-uFLAFlBT for ; Thu, 9 May 2013 15:32:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A98721F8C33 for ; Thu, 9 May 2013 15:32:25 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49MWMaf012712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 22:32:23 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49MWMhJ016615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 22:32:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49MWMe4016611; Thu, 9 May 2013 22:32:22 GMT Received: from dhcp-whq-twvpn-2-vpnpool-10-159-169-191.vpn.oracle.com (/10.159.169.191) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 15:32:22 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> Date: Thu, 9 May 2013 15:32:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 22:32:30 -0000 Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. Why would a server tolerate multiple levels of LoA from the same client = application? Why is that needed? If a server allows 2 and 3, then all clients will choose 2 -- or at the = very least your overall security drops to 2. This is not good. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-09, at 3:17 PM, John Bradley wrote: > The client needs to be able to say only use a particular auth method = to disallow the Authorization server from providing a weaker method to = an attacker. =20 >=20 > This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >=20 > John B. >=20 >=20 > On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >=20 >> Justin, >>=20 >> Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >>=20 >> As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>=20 >>> Justin, >>>=20 >>> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>=20 >>> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>>=20 >>> I have also thought through, does it matter since it is optional? I = think it does. If servers just ignore the param most of the time, what = value is there? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>=20 >>>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>=20 >>>> And I think that the Dynamic Registration protocol that we have = here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>=20 >>>> 1) Accept what the client proposes and use that. This is of course = the ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. >>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>> a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. >>>> b) Reject what the server returns and either try the registration = again with another value or give up. >>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>=20 >>>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>=20 >>>> I think that the assumption of full automation for all clients to = all servers is a red herring in the OAuth world for the simple fact that = the API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>>>=20 >>>> -- Justin >>>>=20 >>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>> wrote: >>>>=20 >>>>> Justin, >>>>>=20 >>>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>=20 >>>>>> Handful of minor changes in this revision, including tightening = the language around scopes and adding an absolute-URI based mechanism = for extending token_endpoint_auth_method (no registry, still). No = normative changes beyond removing an unreachable error state. (Thanks, = Nov.) Please check the diffs, we welcome feedback. I personally think = this is really getting close to final. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>> On May 5, 2013, at 3:45 PM, >>>>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>> Author(s) : Justin Richer >>>>>>> John Bradley >>>>>>> Michael B. Jones >>>>>>> Maciej Machulak >>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>> Pages : 25 >>>>>>> Date : 2013-05-05 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This specification defines an endpoint and protocol for dynamic >>>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>>> methods for the dynamically registered client to manage its >>>>>>> registration. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Thu May 9 15:47:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5D721F8EB5 for ; Thu, 9 May 2013 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS57uoZRVQvd for ; Thu, 9 May 2013 15:47:15 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C82E21F8EB1 for ; Thu, 9 May 2013 15:47:14 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so6753898iec.34 for ; Thu, 09 May 2013 15:47:13 -0700 (PDT) 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=pn5/vFLfblInKYVkKG4FMIJEFelmMBYmpx6B0amOQ28=; b=NYqlZ/fmzpSt8QH+03OMERXckM3Jb0SDytEBqdz4e35ZrqJUcB/6LoqMmI2NKANdRK 9DJVWuSoH83b3tFB/8KKYEhXXi3sS2ARgUlVyRgoHLLxU5L/BybB3ojNFeNUXJhycWhf eek2McoQqA2YQSF5vUi2FwELQUaoguJsMsq7xdTiVYWJoapsXeKifJtoUYvkC215FLSl cBSfvuzdWBvrW589vti7/uGutXqiBgMxagl55wFwykE6yWyAs2oerKpid3CSouUqFpCN 0ETmW6UJgbdnFHy8RpvBaQlPyvhEtKQwtq80lJZXnQMajBkBTxb7IsmlfHbvMasRWhG9 2Yfw== X-Received: by 10.50.60.102 with SMTP id g6mr11386igr.112.1368139633602; Thu, 09 May 2013 15:47:13 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id qs4sm172647igb.10.2013.05.09.15.47.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 15:47:12 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> Date: Thu, 9 May 2013 15:47:09 -0700 Message-Id: <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmdYAReJQEYXAg7xd8051pKhKe+F8CtyoXZIJl+MGq+B2TyShwgRean4ex/3b5e7099PM34 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 22:47:16 -0000 --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Consider if you will a world where IdP support multiple LoA. This allows a RP to register the method required for there use case. If a Client requires the asymmetrically signed JWT assertions rather = than http basic, it doesn't want the Authorization server accepting = http_basic for it's client_id. The reason a client/RP would want to specify multiple LoA is the same = reason they may wan to in SAML or other protocols. The issue is more that different clients will have different security = requirements and this allows them to dynamic register those. If you allow 2 and 3 the one that need 3 will specify that. John On 2013-05-09, at 3:32 PM, Phil Hunt wrote: > Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >=20 > Why would a server tolerate multiple levels of LoA from the same = client application? Why is that needed? >=20 > If a server allows 2 and 3, then all clients will choose 2 -- or at = the very least your overall security drops to 2. This is not good. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-09, at 3:17 PM, John Bradley wrote: >=20 >> The client needs to be able to say only use a particular auth method = to disallow the Authorization server from providing a weaker method to = an attacker. =20 >>=20 >> This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >>=20 >> John B. >>=20 >>=20 >> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>=20 >>> Justin, >>>=20 >>> Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >>>=20 >>> As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>=20 >>>> Justin, >>>>=20 >>>> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>=20 >>>> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>>>=20 >>>> I have also thought through, does it matter since it is optional? = I think it does. If servers just ignore the param most of the time, what = value is there? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>=20 >>>>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>=20 >>>>> And I think that the Dynamic Registration protocol that we have = here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>=20 >>>>> 1) Accept what the client proposes and use that. This is of course = the ideal situation where everybody gets what they want, and this can be = brought about more often by a good discovery process. >>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>> a) Accept what the server returns and use that, if it supports it. = This is also ideal because everybody is happy again. >>>>> b) Reject what the server returns and either try the registration = again with another value or give up. >>>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>>=20 >>>>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>>=20 >>>>> I think that the assumption of full automation for all clients to = all servers is a red herring in the OAuth world for the simple fact that = the API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>> wrote: >>>>>=20 >>>>>> Justin, >>>>>>=20 >>>>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>=20 >>>>>>> Handful of minor changes in this revision, including tightening = the language around scopes and adding an absolute-URI based mechanism = for extending token_endpoint_auth_method (no registry, still). No = normative changes beyond removing an unreachable error state. (Thanks, = Nov.) Please check the diffs, we welcome feedback. I personally think = this is really getting close to final. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>> Author(s) : Justin Richer >>>>>>>> John Bradley >>>>>>>> Michael B. Jones >>>>>>>> Maciej Machulak >>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>> Pages : 25 >>>>>>>> Date : 2013-05-05 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This specification defines an endpoint and protocol for dynamic >>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server = and >>>>>>>> methods for the dynamically registered client to manage its >>>>>>>> registration. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjI0NzEwWjAjBgkqhkiG9w0BCQQxFgQU+0/R1Nj0 OWjQ8gKbEitdnJdJnaswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAYXGH36PtboIgTZfhSU9AdgSCocgUz6nT0COFvFEz JM6TPf8/1sSgpx2Tesks6wcYoSlbrKzQtHiuOIOnYCxSYjBcnSAzrEGPOp+ZqzGh8ouvreFEI3mO 9MgZaGUIcM7M+xvzn3hEKTKhSv80bq5LrcfzejqsWbnHmYUO6XniUMX2HxLqrPnHY6ba3/1mVYeG O+J4QpXx8eV9X8I3Np0bWrT2VuzxJesR9hcZxr3zyQY0rlDj/rouU8njAG7a54ApVTjHq32onJ/8 qXmUtao3yVDFTaBqj/vhnzbjDJpVJhmt3VVQkGFPdmCnmfM+acscd5tr5GwPSEGo+ZIqt08z4gAA AAAAAA== --Apple-Mail=_4E614468-7D4B-4B9C-949A-40F1892FB004-- From phil.hunt@oracle.com Thu May 9 15:58:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A56521F8CEC for ; Thu, 9 May 2013 15:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYaVfgSTJk53 for ; Thu, 9 May 2013 15:58:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC521F8C9B for ; Thu, 9 May 2013 15:58:35 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49MwXC2029942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 22:58:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49MwWu9000668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 22:58:32 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49MwVET025958; Thu, 9 May 2013 22:58:31 GMT Received: from dhcp-whq-twvpn-2-vpnpool-10-159-169-191.vpn.oracle.com (/10.159.169.191) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 15:58:31 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> Date: Thu, 9 May 2013 15:58:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 22:58:40 -0000 You seem to now be talking about SAML endpoints rather than OAuth = endpoints. I think you are confusing what the client gets back from the AS in terms = of the OAuth protocol vs. how the client authenticates to the AS. The = parameter in question isn't about what assertions the AS returns to the = client. The case is about what credential the client must use with the = AS to satisfy a particular AS's requirements.=20 I haven't heard a reason for clients to be able to downgrade. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-09, at 3:47 PM, John Bradley wrote: > Consider if you will a world where IdP support multiple LoA. >=20 > This allows a RP to register the method required for there use case. >=20 > If a Client requires the asymmetrically signed JWT assertions rather = than http basic, it doesn't want the Authorization server accepting = http_basic for it's client_id. >=20 > The reason a client/RP would want to specify multiple LoA is the same = reason they may wan to in SAML or other protocols. >=20 > The issue is more that different clients will have different security = requirements and this allows them to dynamic register those. >=20 > If you allow 2 and 3 the one that need 3 will specify that. >=20 > John >=20 > On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >=20 >> Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >>=20 >> Why would a server tolerate multiple levels of LoA from the same = client application? Why is that needed? >>=20 >> If a server allows 2 and 3, then all clients will choose 2 -- or at = the very least your overall security drops to 2. This is not good. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>=20 >>> The client needs to be able to say only use a particular auth method = to disallow the Authorization server from providing a weaker method to = an attacker. =20 >>>=20 >>> This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >>>=20 >>> John B. >>>=20 >>>=20 >>> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>>=20 >>>> Justin, >>>>=20 >>>> Just to progress towards resolving this issue, what I would like to = understand is how specifying authentication type makes things simpler or = more inter-operable. I'm concerned that the logic you proposed early in = the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >>>>=20 >>>> As an alternative, the negotiation for credential method/type could = occur during the initial developer registration of the app. As in your = "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>=20 >>>>> Justin, >>>>>=20 >>>>> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>>=20 >>>>> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>>>>=20 >>>>> I have also thought through, does it matter since it is optional? = I think it does. If servers just ignore the param most of the time, what = value is there? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>=20 >>>>>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>>=20 >>>>>> And I think that the Dynamic Registration protocol that we have = here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>>=20 >>>>>> 1) Accept what the client proposes and use that. This is of = course the ideal situation where everybody gets what they want, and this = can be brought about more often by a good discovery process. >>>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>>> a) Accept what the server returns and use that, if it supports = it. This is also ideal because everybody is happy again. >>>>>> b) Reject what the server returns and either try the registration = again with another value or give up. >>>>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>>>=20 >>>>>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>>>=20 >>>>>> I think that the assumption of full automation for all clients to = all servers is a red herring in the OAuth world for the simple fact that = the API that's being accessed/protected isn't going to be universally = compatible anyway. I agree fully that a well-specified service discovery = is important and we should, as a working group, help figure out what = that looks like. As mentioned above, several of us already are. But I = don't think it's helpful to conflate the registration and discovery = processes and turn them into some kind of negotiation system. I think we = can do a good job of making it widely useful without that. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>> wrote: >>>>>>=20 >>>>>>> Justin, >>>>>>>=20 >>>>>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>=20 >>>>>>>> Handful of minor changes in this revision, including tightening = the language around scopes and adding an absolute-URI based mechanism = for extending token_endpoint_auth_method (no registry, still). No = normative changes beyond removing an unreachable error state. (Thanks, = Nov.) Please check the diffs, we welcome feedback. I personally think = this is really getting close to final. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>>> Author(s) : Justin Richer >>>>>>>>> John Bradley >>>>>>>>> Michael B. Jones >>>>>>>>> Maciej Machulak >>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>> Pages : 25 >>>>>>>>> Date : 2013-05-05 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This specification defines an endpoint and protocol for = dynamic >>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server = and >>>>>>>>> methods for the dynamically registered client to manage its >>>>>>>>> registration. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>=20 >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>=20 >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 From ve7jtb@ve7jtb.com Thu May 9 16:03:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D479F21F8E9A for ; Thu, 9 May 2013 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGGMk0aMKKXD for ; Thu, 9 May 2013 16:03:07 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 74A1C21F8956 for ; Thu, 9 May 2013 16:03:07 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so6841427iec.11 for ; Thu, 09 May 2013 16:03:07 -0700 (PDT) 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=p4dh68plxlQpEwY+zaC4x+pUJY9WW/CKejWPH72jswc=; b=kV0UqhXMLRnpNaw33SzgMZResbhV2OwdFpiSY5msrKp0p24fY0YrKRSKwUOCCz4ci/ pGksKEn90kn7Ln+kWUw1tcZr1rm6uY0tSX8d57yJe8m32l64BUm8/xkVOr+xq8HegXT8 Ec4gOxyA4IHoh9MACTKp1M1tb9goDvHK9lwFIO89Ocs2o0A5HoiTdirRWepNeCvv6Dpp tP6BcRsVDbZcC7e0MFVUd7jmzg4PoEEEfPMCQA87N8SXAePstCAq7l3Xl9hOK4bOOgZn 94ckLRn7XCNuKZEr3O/E2eyjADNBt0SLxzg4maYHC3ma8TcCALJmj1V1EqsIlFP037zv seTw== X-Received: by 10.50.15.166 with SMTP id y6mr81255igc.83.1368140586776; Thu, 09 May 2013 16:03:06 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id kc10sm859215igb.0.2013.05.09.16.03.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 16:03:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2FCB9832-E18B-48AC-8C5A-6958DC140BBA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> Date: Thu, 9 May 2013 16:03:01 -0700 Message-Id: <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk03osmTDSokrpg2oUxubar18vxkyPPg40zBTyWjP1IyzjjEmYW/79Y3VTAoT0vkv1x8i+P Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 23:03:08 -0000 --Apple-Mail=_2FCB9832-E18B-48AC-8C5A-6958DC140BBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The issue is not allowing fake clients to dynamically downgrade, where = the AS supports multiple methods. On 2013-05-09, at 3:58 PM, Phil Hunt wrote: > You seem to now be talking about SAML endpoints rather than OAuth = endpoints. >=20 >=20 > I think you are confusing what the client gets back from the AS in = terms of the OAuth protocol vs. how the client authenticates to the AS. = The parameter in question isn't about what assertions the AS returns to = the client. The case is about what credential the client must use with = the AS to satisfy a particular AS's requirements.=20 >=20 > I haven't heard a reason for clients to be able to downgrade. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-09, at 3:47 PM, John Bradley wrote: >=20 >> Consider if you will a world where IdP support multiple LoA. >>=20 >> This allows a RP to register the method required for there use case. >>=20 >> If a Client requires the asymmetrically signed JWT assertions rather = than http basic, it doesn't want the Authorization server accepting = http_basic for it's client_id. >>=20 >> The reason a client/RP would want to specify multiple LoA is the same = reason they may wan to in SAML or other protocols. >>=20 >> The issue is more that different clients will have different security = requirements and this allows them to dynamic register those. >>=20 >> If you allow 2 and 3 the one that need 3 will specify that. >>=20 >> John >>=20 >> On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >>=20 >>> Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >>>=20 >>> Why would a server tolerate multiple levels of LoA from the same = client application? Why is that needed? >>>=20 >>> If a server allows 2 and 3, then all clients will choose 2 -- or at = the very least your overall security drops to 2. This is not good. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>=20 >>>> The client needs to be able to say only use a particular auth = method to disallow the Authorization server from providing a weaker = method to an attacker. =20 >>>>=20 >>>> This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>>>=20 >>>>> Justin, >>>>>=20 >>>>> Just to progress towards resolving this issue, what I would like = to understand is how specifying authentication type makes things simpler = or more inter-operable. I'm concerned that the logic you proposed early = in the thread is a lot more complexity. I would prefer just having the = server tell the client what authentication it MUST use. >>>>>=20 >>>>> As an alternative, the negotiation for credential method/type = could occur during the initial developer registration of the app. As in = your "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>=20 >>>>>> Justin, >>>>>>=20 >>>>>> What you describe, though good intentioned, seems like a lot of = complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>>>=20 >>>>>> Think about someone writing a general purpose SCIM client or OIDC = client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c = only 5 and 6. So if each site is willing to negotiate authn, how has = this developer's coding been reduced? The developer will end up having = to implement all popular methods regardless of discovery or the ability = of the client to select. In fact, they have to do all the logic you = describe below AND implement all methods. >>>>>>=20 >>>>>> I have also thought through, does it matter since it is optional? = I think it does. If servers just ignore the param most of the time, = what value is there? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>=20 >>>>>>> In spite of what John seems to think, that dependency was never = there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>>>=20 >>>>>>> And I think that the Dynamic Registration protocol that we have = here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>>>=20 >>>>>>> 1) Accept what the client proposes and use that. This is of = course the ideal situation where everybody gets what they want, and this = can be brought about more often by a good discovery process. >>>>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>>>> a) Accept what the server returns and use that, if it supports = it. This is also ideal because everybody is happy again. >>>>>>> b) Reject what the server returns and either try the = registration again with another value or give up. >>>>>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>>>>=20 >>>>>>> Alternatively, the client could just not mention it and have the = server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>>>>=20 >>>>>>> I think that the assumption of full automation for all clients = to all servers is a red herring in the OAuth world for the simple fact = that the API that's being accessed/protected isn't going to be = universally compatible anyway. I agree fully that a well-specified = service discovery is important and we should, as a working group, help = figure out what that looks like. As mentioned above, several of us = already are. But I don't think it's helpful to conflate the registration = and discovery processes and turn them into some kind of negotiation = system. I think we can do a good job of making it widely useful without = that. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Justin, >>>>>>>>=20 >>>>>>>> Has the assumption of a discovery service defined by OIDC been = removed? >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>=20 >>>>>>>>> Handful of minor changes in this revision, including = tightening the language around scopes and adding an absolute-URI based = mechanism for extending token_endpoint_auth_method (no registry, still). = No normative changes beyond removing an unreachable error state. = (Thanks, Nov.) Please check the diffs, we welcome feedback. I personally = think this is really getting close to final. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>> John Bradley >>>>>>>>>> Michael B. Jones >>>>>>>>>> Maciej Machulak >>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>> Pages : 25 >>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>=20 >>>>>>>>>> Abstract: >>>>>>>>>> This specification defines an endpoint and protocol for = dynamic >>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server = and >>>>>>>>>> methods for the dynamically registered client to manage its >>>>>>>>>> registration. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>=20 >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>=20 >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_2FCB9832-E18B-48AC-8C5A-6958DC140BBA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjMwMzAyWjAjBgkqhkiG9w0BCQQxFgQUzDR/fJB3 vT8KbbRkC6HHHuyc7LwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAO45sJ/EfH36pYrFMkgN0HwfqAZKuPj0ndlhTD8k/ oTlm3at31SA0KhYtbrcyUVpt91/qG2gwSAVl1c/eROkPSjlGpZT1CtKQVLwxWd11voFW3lnaeJrR ixzT74XflT5L5tocvfVsYL+xEq9ugNl8qICgRxsJVS2IuVBfhIk1TqQOb+zJyguauUi4Ya/jXTQJ pXLAmwkbBJJqCuyY+oY6rPfNjcI/yU1GqKGlY9nqRBhukoDjMZZm5q0zce9/+ih3DsqkKUEVI9Op MVyuJOO3EgnmNCryoN8am/AQ0mzmQbYPusSZWjy1Xk6vud/RNCjli0GG18KW/9mVjdyqWNE+BQAA AAAAAA== --Apple-Mail=_2FCB9832-E18B-48AC-8C5A-6958DC140BBA-- From ve7jtb@ve7jtb.com Thu May 9 16:23:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976521F8E8F for ; Thu, 9 May 2013 16:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiXrYRlyvGEl for ; Thu, 9 May 2013 16:23:48 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F1E0521F8E8E for ; Thu, 9 May 2013 16:23:47 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 10so6703490ied.19 for ; Thu, 09 May 2013 16:23:47 -0700 (PDT) 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=sIqzDSr2GYRLumXKFsXeRp0ZIiNY9E9KTLB/2qrkpZA=; b=iYYy9FsjH6sVzMJuT+Ss/dzAR0DlVg0vtNZhksnvB8d2zaNmIUcK3PZHCPtEXBgXhH odc9Ve3VWwvPYjDm97ypdmvj99zxYoHaUtaOgikhkD2Y6HNKVLvTnUK624TmW7fDRMbc QNqie1an0UPqH3jbv+s3u+oGGxmTVP2D/+RU6xuK9vVtzzBDL+twIdjWImFKMqEMaVAa 8yn53dFArbmfIfAgV2C323iuY1VrOCAiNGXfIcr/rGRjFgzwZQHATfoZwzJ3NQ96LmtA ddKE9ci62q9yuViSV4AGXqs1/lPABORu8hahhr4l5ayZPZgmtIKLAmhBZjGnezO20aKU 7nzw== X-Received: by 10.50.51.226 with SMTP id n2mr203604igo.25.1368141827291; Thu, 09 May 2013 16:23:47 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id d9sm371980igr.4.2013.05.09.16.23.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 16:23:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DC85B3B1-B3BA-48AB-ABB3-0218833D9129"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <518752CB.8050408@gmx.net> Date: Thu, 9 May 2013 16:23:40 -0700 Message-Id: <464CDED2-AA62-47DC-8821-E347507D78B7@ve7jtb.com> References: <518752CB.8050408@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmu0T7xV40D3xm+OoJC6rqWsnECJiwKcLCSTmYqSToIec5ik9Yo25XhZYDsrFvvdOKm/4Vk Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2013 23:23:49 -0000 --Apple-Mail=_DC85B3B1-B3BA-48AB-ABB3-0218833D9129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe the spec is fine as is. John B. On 2013-05-05, at 11:50 PM, Hannes Tschofenig = wrote: > This is a Last Call for comments on > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >=20 > Because of the timing of the impending Internet Identity Workshop we = are setting the call for **3 weeks**. >=20 > Please have your comments in no later than May 27th. >=20 > Do remember to send a note in if you have read the document and have = no other comments other than "its ready to go" - we need those as much = as we need "I found a problem". >=20 > Thanks! > Hannes & Derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DC85B3B1-B3BA-48AB-ABB3-0218833D9129 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjMyMzQwWjAjBgkqhkiG9w0BCQQxFgQUHVsA6nKy gSn7QNHefoSngrVBI8AwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEALiilptKTZLB1l62Kx7pxIqDscTtyBjjeFw8hRTr1 W5BxiWtZcXuwN7WZIljbbZLwqem+9py94zfhCbpoV37tMXqgRCrFvPrItc/L80MnCB9Q8cKAcZ3z MJwevN3O/PBxXK0gpiYCh9bzrfKzqDbyfMjinczqeLgIHX/HTifOqbUHEwH/qbdYnHch1jvV7qMA UH2joXJYbjvKa152SL+iFYFKwXAwJXRFFZecddTU8XusxfU6sUs4tSm/xpmYDzp4wK8ptZP+fHR/ zoM1NZqAkkVcBpto8/EOI4KtmVBpGxN806YC/8LU8PeEa3zQft2ewufp2x6VjmYSLm6LmfVavgAA AAAAAA== --Apple-Mail=_DC85B3B1-B3BA-48AB-ABB3-0218833D9129-- From phil.hunt@oracle.com Thu May 9 16:38:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9E121F905C for ; Thu, 9 May 2013 16:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQHGFvk3eZo7 for ; Thu, 9 May 2013 16:38:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 38F3521F8EB5 for ; Thu, 9 May 2013 16:37:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49NbnPx024627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 23:37:50 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49NbmSm025033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 23:37:48 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49NblJR005045; Thu, 9 May 2013 23:37:47 GMT Received: from [25.35.253.54] (/24.114.91.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 16:37:46 -0700 References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 9 May 2013 16:37:38 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 23:38:05 -0000 How does NOT allowing clients to choose authn type allow them to downgrade. I= am saying there is NO value in allowing this and that the parameter needs t= o be removed.=20 Phil On 2013-05-09, at 16:03, John Bradley wrote: > The issue is not allowing fake clients to dynamically downgrade, where the= AS supports multiple methods. >=20 >=20 > On 2013-05-09, at 3:58 PM, Phil Hunt wrote: >=20 >> You seem to now be talking about SAML endpoints rather than OAuth endpoin= ts. >>=20 >>=20 >> I think you are confusing what the client gets back from the AS in terms o= f the OAuth protocol vs. how the client authenticates to the AS. The param= eter in question isn't about what assertions the AS returns to the client. T= he case is about what credential the client must use with the AS to satisfy a= particular AS's requirements.=20 >>=20 >> I haven't heard a reason for clients to be able to downgrade. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>=20 >>> Consider if you will a world where IdP support multiple LoA. >>>=20 >>> This allows a RP to register the method required for there use case. >>>=20 >>> If a Client requires the asymmetrically signed JWT assertions rather tha= n http basic, it doesn't want the Authorization server accepting http_basic= for it's client_id. >>>=20 >>> The reason a client/RP would want to specify multiple LoA is the same re= ason they may wan to in SAML or other protocols. >>>=20 >>> The issue is more that different clients will have different security re= quirements and this allows them to dynamic register those. >>>=20 >>> If you allow 2 and 3 the one that need 3 will specify that. >>>=20 >>> John >>>=20 >>> On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >>>=20 >>>> Giving the client the choice lets the client choose lower LoA and downg= rade. Surely it is the server that is taking the risk so the server has the= right to set the requirements. >>>>=20 >>>> Why would a server tolerate multiple levels of LoA from the same client= application? Why is that needed? >>>>=20 >>>> If a server allows 2 and 3, then all clients will choose 2 -- or at the= very least your overall security drops to 2. This is not good. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>=20 >>>>> The client needs to be able to say only use a particular auth method t= o disallow the Authorization server from providing a weaker method to an att= acker. =20 >>>>>=20 >>>>> This is a required parameter to allow a Authorization server to suppor= t high and low LoA clients dynamically. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>>>>=20 >>>>>> Justin, >>>>>>=20 >>>>>> Just to progress towards resolving this issue, what I would like to u= nderstand is how specifying authentication type makes things simpler or more= inter-operable. I'm concerned that the logic you proposed early in the thre= ad is a lot more complexity. I would prefer just having the server tell the= client what authentication it MUST use. >>>>>>=20 >>>>>> As an alternative, the negotiation for credential method/type could o= ccur during the initial developer registration of the app. As in your "blue= button" health case (did I remember that right), the initial registration J= WT would be used in the dynamic registration and allow the registration serv= er to observe any previously negotiated client preferences OOB of this spec.= Or, are you saying that individual instances have some need to change auth= entication types on a per deployment basis independent of what the associate= d authorization server wants them to use? If so what is it? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>=20 >>>>>>> Justin, >>>>>>>=20 >>>>>>> What you describe, though good intentioned, seems like a lot of comp= lexity without getting an actual benefit. I would rather not have token_endp= oint_auth_method at all. >>>>>>>=20 >>>>>>> Think about someone writing a general purpose SCIM client or OIDC cl= ient. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c only 5= and 6. So if each site is willing to negotiate authn, how has this develop= er's coding been reduced? The developer will end up having to implement all p= opular methods regardless of discovery or the ability of the client to selec= t. In fact, they have to do all the logic you describe below AND implement a= ll methods. >>>>>>>=20 >>>>>>> I have also thought through, does it matter since it is optional? I= think it does. If servers just ignore the param most of the time, what valu= e is there? >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>=20 >>>>>>>> In spite of what John seems to think, that dependency was never the= re. The whole discovery process is related, but separate, from registration.= It could happen using OIDC, it could happen with Bill Mills's LRDD link typ= es, it could happen with Nat's proposed HAL-based system, it could happen by= the developer going to the service provider's documentation page and readin= g a bunch of text (which is what happens with large OAuth providers today) -= - it ultimately doesn't matter.=20 >>>>>>>>=20 >>>>>>>> And I think that the Dynamic Registration protocol that we have her= e is robust against that kind of diversity. Let's take the token_endpoint_au= th_method parameter as an example. Let's say a client shows up to a service i= t's just discovered -- through whatever means, we don't actually care. This c= lient either has some idea of what auth methods the server supports (through= a discovery mechanism) or it doesn't. If it does, it will also know which m= ethods it supports and it can pick one. If it doesn't, it will still know wh= ich methods it supports and will just pick one. The server will then take th= at information and do one of three things: >>>>>>>>=20 >>>>>>>> 1) Accept what the client proposes and use that. This is of course t= he ideal situation where everybody gets what they want, and this can be brou= ght about more often by a good discovery process. >>>>>>>> 2) Reject what the client proposes with an error code (invalid_clie= nt_metadata would cover this). The client then has to re-register with a dif= ferent value or just give up because the two systems are using different aut= h methods that can't be reconciled. >>>>>>>> 3) Ignore what the client proposes and return the server's preferre= d method. The client can then, in turn: >>>>>>>> a) Accept what the server returns and use that, if it supports it. T= his is also ideal because everybody is happy again. >>>>>>>> b) Reject what the server returns and either try the registration a= gain with another value or give up. >>>>>>>> c) Ignore what the server returns and fail when doing a token reque= st. This would be a dumb thing for a dumb client to do.=20 >>>>>>>>=20 >>>>>>>> Alternatively, the client could just not mention it and have the se= rver dictate what method it will use, and the client will either accept, rej= ect, or ignore it. This process applies to every parameter in the system, fr= om something innocuous as the client's TOS uri to something as security-crit= ical as the redirect_uri (which gets its own special error message).=20 >>>>>>>>=20 >>>>>>>> I think that the assumption of full automation for all clients to a= ll servers is a red herring in the OAuth world for the simple fact that the A= PI that's being accessed/protected isn't going to be universally compatible a= nyway. I agree fully that a well-specified service discovery is important an= d we should, as a working group, help figure out what that looks like. As me= ntioned above, several of us already are. But I don't think it's helpful to c= onflate the registration and discovery processes and turn them into some kin= d of negotiation system. I think we can do a good job of making it widely us= eful without that. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Justin, >>>>>>>>>=20 >>>>>>>>> Has the assumption of a discovery service defined by OIDC been rem= oved? >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>=20 >>>>>>>>>> Handful of minor changes in this revision, including tightening t= he language around scopes and adding an absolute-URI based mechanism for ext= ending token_endpoint_auth_method (no registry, still). No normative changes= beyond removing an unreachable error state. (Thanks, Nov.) Please check the= diffs, we welcome feedback. I personally think this is really getting close= to final. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draf= ts directories. >>>>>>>>>>> This draft is a work item of the Web Authorization Protocol Work= ing Group of the IETF. >>>>>>>>>>>=20 >>>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration Proto= col >>>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>>> John Bradley >>>>>>>>>>> Michael B. Jones >>>>>>>>>>> Maciej Machulak >>>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>>> Pages : 25 >>>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>>=20 >>>>>>>>>>> Abstract: >>>>>>>>>>> This specification defines an endpoint and protocol for dynamic >>>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server and= >>>>>>>>>>> methods for the dynamically registered client to manage its >>>>>>>>>>> registration. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>=20 >>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>=20 >>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From phil.hunt@oracle.com Thu May 9 16:40:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B571D21F905C for ; Thu, 9 May 2013 16:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMRc+pli1O4L for ; Thu, 9 May 2013 16:40:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A08AF21F8EB5 for ; Thu, 9 May 2013 16:40:20 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49NeHpO026595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 23:40:18 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49NeGPo028508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 23:40:17 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49NeGaK028502; Thu, 9 May 2013 23:40:16 GMT Received: from [25.35.253.54] (/24.114.91.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 16:40:16 -0700 References: <518752CB.8050408@gmx.net> <464CDED2-AA62-47DC-8821-E347507D78B7@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <464CDED2-AA62-47DC-8821-E347507D78B7@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 9 May 2013 16:40:08 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Working Group Last Call on draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2013 23:40:26 -0000 The client auth type parameter issue needs to be resolved.=20 Phil On 2013-05-09, at 16:23, John Bradley wrote: > I believe the spec is fine as is. >=20 > John B. >=20 > On 2013-05-05, at 11:50 PM, Hannes Tschofenig w= rote: >=20 >> This is a Last Call for comments on >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>=20 >> Because of the timing of the impending Internet Identity Workshop we are s= etting the call for **3 weeks**. >>=20 >> Please have your comments in no later than May 27th. >>=20 >> Do remember to send a note in if you have read the document and have no o= ther comments other than "its ready to go" - we need those as much as we nee= d "I found a problem". >>=20 >> Thanks! >> Hannes & Derek >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Thu May 9 16:46:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482D521F8EB5 for ; Thu, 9 May 2013 16:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.576 X-Spam-Level: X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLRFK0uD9fzY for ; Thu, 9 May 2013 16:46:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CC4CD21F8FDF for ; Thu, 9 May 2013 16:46:45 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r49Nkgpw030577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 May 2013 23:46:43 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49Nkf0o006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2013 23:46:42 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r49NkfEj000715; Thu, 9 May 2013 23:46:41 GMT Received: from [192.168.67.123] (/207.239.114.206) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 16:46:40 -0700 References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> In-Reply-To: <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 9 May 2013 16:46:39 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 23:46:51 -0000 Maybe i am not being clear. I feel the parameter must not be in the dyn reg r= equest. The parameter should be in the response so that the client has no c= hoice and no ability to downgrade.=20 Phil On 2013-05-09, at 16:37, Phil Hunt wrote: > How does NOT allowing clients to choose authn type allow them to downgrade= . I am saying there is NO value in allowing this and that the parameter need= s to be removed.=20 >=20 > Phil >=20 > On 2013-05-09, at 16:03, John Bradley wrote: >=20 >> The issue is not allowing fake clients to dynamically downgrade, where th= e AS supports multiple methods. >>=20 >>=20 >> On 2013-05-09, at 3:58 PM, Phil Hunt wrote: >>=20 >>> You seem to now be talking about SAML endpoints rather than OAuth endpoi= nts. >>>=20 >>>=20 >>> I think you are confusing what the client gets back from the AS in terms= of the OAuth protocol vs. how the client authenticates to the AS. The par= ameter in question isn't about what assertions the AS returns to the client.= The case is about what credential the client must use with the AS to satis= fy a particular AS's requirements.=20 >>>=20 >>> I haven't heard a reason for clients to be able to downgrade. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>>=20 >>>> Consider if you will a world where IdP support multiple LoA. >>>>=20 >>>> This allows a RP to register the method required for there use case. >>>>=20 >>>> If a Client requires the asymmetrically signed JWT assertions rather th= an http basic, it doesn't want the Authorization server accepting http_basi= c for it's client_id. >>>>=20 >>>> The reason a client/RP would want to specify multiple LoA is the same r= eason they may wan to in SAML or other protocols. >>>>=20 >>>> The issue is more that different clients will have different security r= equirements and this allows them to dynamic register those. >>>>=20 >>>> If you allow 2 and 3 the one that need 3 will specify that. >>>>=20 >>>> John >>>>=20 >>>> On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >>>>=20 >>>>> Giving the client the choice lets the client choose lower LoA and down= grade. Surely it is the server that is taking the risk so the server has th= e right to set the requirements. >>>>>=20 >>>>> Why would a server tolerate multiple levels of LoA from the same clien= t application? Why is that needed? >>>>>=20 >>>>> If a server allows 2 and 3, then all clients will choose 2 -- or at th= e very least your overall security drops to 2. This is not good. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>>=20 >>>>>> The client needs to be able to say only use a particular auth method t= o disallow the Authorization server from providing a weaker method to an att= acker. =20 >>>>>>=20 >>>>>> This is a required parameter to allow a Authorization server to suppo= rt high and low LoA clients dynamically. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> Justin, >>>>>>>=20 >>>>>>> Just to progress towards resolving this issue, what I would like to u= nderstand is how specifying authentication type makes things simpler or more= inter-operable. I'm concerned that the logic you proposed early in the thre= ad is a lot more complexity. I would prefer just having the server tell the= client what authentication it MUST use. >>>>>>>=20 >>>>>>> As an alternative, the negotiation for credential method/type could o= ccur during the initial developer registration of the app. As in your "blue= button" health case (did I remember that right), the initial registration J= WT would be used in the dynamic registration and allow the registration serv= er to observe any previously negotiated client preferences OOB of this spec.= Or, are you saying that individual instances have some need to change auth= entication types on a per deployment basis independent of what the associate= d authorization server wants them to use? If so what is it? >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>>=20 >>>>>>>> Justin, >>>>>>>>=20 >>>>>>>> What you describe, though good intentioned, seems like a lot of com= plexity without getting an actual benefit. I would rather not have token_end= point_auth_method at all. >>>>>>>>=20 >>>>>>>> Think about someone writing a general purpose SCIM client or OIDC c= lient. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c only= 5 and 6. So if each site is willing to negotiate authn, how has this devel= oper's coding been reduced? The developer will end up having to implement al= l popular methods regardless of discovery or the ability of the client to se= lect. In fact, they have to do all the logic you describe below AND implemen= t all methods. >>>>>>>>=20 >>>>>>>> I have also thought through, does it matter since it is optional? I= think it does. If servers just ignore the param most of the time, what valu= e is there? >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>>=20 >>>>>>>>> In spite of what John seems to think, that dependency was never th= ere. The whole discovery process is related, but separate, from registration= . It could happen using OIDC, it could happen with Bill Mills's LRDD link ty= pes, it could happen with Nat's proposed HAL-based system, it could happen b= y the developer going to the service provider's documentation page and readi= ng a bunch of text (which is what happens with large OAuth providers today) -= - it ultimately doesn't matter.=20 >>>>>>>>>=20 >>>>>>>>> And I think that the Dynamic Registration protocol that we have he= re is robust against that kind of diversity. Let's take the token_endpoint_a= uth_method parameter as an example. Let's say a client shows up to a service= it's just discovered -- through whatever means, we don't actually care. Thi= s client either has some idea of what auth methods the server supports (thro= ugh a discovery mechanism) or it doesn't. If it does, it will also know whic= h methods it supports and it can pick one. If it doesn't, it will still know= which methods it supports and will just pick one. The server will then take= that information and do one of three things: >>>>>>>>>=20 >>>>>>>>> 1) Accept what the client proposes and use that. This is of course= the ideal situation where everybody gets what they want, and this can be br= ought about more often by a good discovery process. >>>>>>>>> 2) Reject what the client proposes with an error code (invalid_cli= ent_metadata would cover this). The client then has to re-register with a di= fferent value or just give up because the two systems are using different au= th methods that can't be reconciled. >>>>>>>>> 3) Ignore what the client proposes and return the server's preferr= ed method. The client can then, in turn: >>>>>>>>> a) Accept what the server returns and use that, if it supports it.= This is also ideal because everybody is happy again. >>>>>>>>> b) Reject what the server returns and either try the registration a= gain with another value or give up. >>>>>>>>> c) Ignore what the server returns and fail when doing a token requ= est. This would be a dumb thing for a dumb client to do.=20 >>>>>>>>>=20 >>>>>>>>> Alternatively, the client could just not mention it and have the s= erver dictate what method it will use, and the client will either accept, re= ject, or ignore it. This process applies to every parameter in the system, f= rom something innocuous as the client's TOS uri to something as security-cri= tical as the redirect_uri (which gets its own special error message).=20 >>>>>>>>>=20 >>>>>>>>> I think that the assumption of full automation for all clients to a= ll servers is a red herring in the OAuth world for the simple fact that the A= PI that's being accessed/protected isn't going to be universally compatible a= nyway. I agree fully that a well-specified service discovery is important an= d we should, as a working group, help figure out what that looks like. As me= ntioned above, several of us already are. But I don't think it's helpful to c= onflate the registration and discovery processes and turn them into some kin= d of negotiation system. I think we can do a good job of making it widely us= eful without that. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Justin, >>>>>>>>>>=20 >>>>>>>>>> Has the assumption of a discovery service defined by OIDC been re= moved? >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>>=20 >>>>>>>>>>> Handful of minor changes in this revision, including tightening t= he language around scopes and adding an absolute-URI based mechanism for ext= ending token_endpoint_auth_method (no registry, still). No normative changes= beyond removing an unreachable error state. (Thanks, Nov.) Please check the= diffs, we welcome feedback. I personally think this is really getting close= to final. >>>>>>>>>>>=20 >>>>>>>>>>> -- Justin >>>>>>>>>>>=20 >>>>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Dra= fts directories. >>>>>>>>>>>> This draft is a work item of the Web Authorization Protocol Wor= king Group of the IETF. >>>>>>>>>>>>=20 >>>>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration Protoc= ol >>>>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>>>> John Bradley >>>>>>>>>>>> Michael B. Jones >>>>>>>>>>>> Maciej Machulak >>>>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>>>> Pages : 25 >>>>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>>>>>>> This specification defines an endpoint and protocol for dynamic= >>>>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server an= d >>>>>>>>>>>> methods for the dynamically registered client to manage its >>>>>>>>>>>> registration. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>>=20 >>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>=20 >>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing 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 May 9 16:55:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BC621F901D for ; Thu, 9 May 2013 16:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgPZ25By7gXW for ; Thu, 9 May 2013 16:55:42 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D16CE21F8FDF for ; Thu, 9 May 2013 16:55:41 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so6857033iea.18 for ; Thu, 09 May 2013 16:55:41 -0700 (PDT) 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=fAoBaZbYEqfcvPN1hTNgHZw9N7yX342PcK2Vw3bNy6w=; b=Zedfpi1LzGCiGCiUo8P1Lhrp9eit2VeWCmIImYfZujc9gDtfb9L2uENdxDhjTZbUPz /SpI0J8aOABKAyom6BzNWd/3YgAfLuYrlhzZK5EsNicNLYoaRoTHi5OHr2zu1QUEz9/p YzdX1m4KWahvsKVLlwLBySZeafZn7rxsuUyKSzd1jqhCiUrdj9H13Qj/GpAzxMKEkqmR qMIHAgXAADmC7XkxZbEzs9uzmG7OWApj9/Ii2T0nuxufg4gkzDlW+NLhky0XbWkg5Ys7 yY29uzPqujEcXfGyr4CWT05pyVwkS/sQ6Q02dnOcforTRW2qBx7b8Z2OZV7pvRRkZitg nMXg== X-Received: by 10.50.80.101 with SMTP id q5mr296192igx.2.1368143741275; Thu, 09 May 2013 16:55:41 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id q3sm690727igw.0.2013.05.09.16.55.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 16:55:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A2092896-5CD9-4F36-AB4B-E9A5C890B70C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Thu, 9 May 2013 16:55:37 -0700 Message-Id: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkb4vq/tmhT6eXvRxBELAN2dYnz96YY89PdzlOc6HfR3TqKMqrEvvV4Az5CX/R/FhgOUgPO Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 09 May 2013 23:55:43 -0000 --Apple-Mail=_A2092896-5CD9-4F36-AB4B-E9A5C890B70C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The downgrade is at runtime not at registration. It is signalling the = methods the RP doesn't want the AS to support for the client_id. We are not getting anywhere on this. The parameter is required for = dynamic registration of higher security clients at AS that support = multiple token_endpoint authentication types. John On 2013-05-09, at 4:46 PM, Phil Hunt wrote: > Maybe i am not being clear. I feel the parameter must not be in the = dyn reg request. The parameter should be in the response so that the = client has no choice and no ability to downgrade.=20 >=20 > Phil >=20 > On 2013-05-09, at 16:37, Phil Hunt wrote: >=20 >> How does NOT allowing clients to choose authn type allow them to = downgrade. I am saying there is NO value in allowing this and that the = parameter needs to be removed.=20 >>=20 >> Phil >>=20 >> On 2013-05-09, at 16:03, John Bradley wrote: >>=20 >>> The issue is not allowing fake clients to dynamically downgrade, = where the AS supports multiple methods. >>>=20 >>>=20 >>> On 2013-05-09, at 3:58 PM, Phil Hunt wrote: >>>=20 >>>> You seem to now be talking about SAML endpoints rather than OAuth = endpoints. >>>>=20 >>>>=20 >>>> I think you are confusing what the client gets back from the AS in = terms of the OAuth protocol vs. how the client authenticates to the AS. = The parameter in question isn't about what assertions the AS returns to = the client. The case is about what credential the client must use with = the AS to satisfy a particular AS's requirements.=20 >>>>=20 >>>> I haven't heard a reason for clients to be able to downgrade. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>>>=20 >>>>> Consider if you will a world where IdP support multiple LoA. >>>>>=20 >>>>> This allows a RP to register the method required for there use = case. >>>>>=20 >>>>> If a Client requires the asymmetrically signed JWT assertions = rather than http basic, it doesn't want the Authorization server = accepting http_basic for it's client_id. >>>>>=20 >>>>> The reason a client/RP would want to specify multiple LoA is the = same reason they may wan to in SAML or other protocols. >>>>>=20 >>>>> The issue is more that different clients will have different = security requirements and this allows them to dynamic register those. >>>>>=20 >>>>> If you allow 2 and 3 the one that need 3 will specify that. >>>>>=20 >>>>> John >>>>>=20 >>>>> On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >>>>>=20 >>>>>> Giving the client the choice lets the client choose lower LoA and = downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >>>>>>=20 >>>>>> Why would a server tolerate multiple levels of LoA from the same = client application? Why is that needed? >>>>>>=20 >>>>>> If a server allows 2 and 3, then all clients will choose 2 -- or = at the very least your overall security drops to 2. This is not good. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>>>=20 >>>>>>> The client needs to be able to say only use a particular auth = method to disallow the Authorization server from providing a weaker = method to an attacker. =20 >>>>>>>=20 >>>>>>> This is a required parameter to allow a Authorization server to = support high and low LoA clients dynamically. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-09, at 2:44 PM, Phil Hunt = wrote: >>>>>>>=20 >>>>>>>> Justin, >>>>>>>>=20 >>>>>>>> Just to progress towards resolving this issue, what I would = like to understand is how specifying authentication type makes things = simpler or more inter-operable. I'm concerned that the logic you = proposed early in the thread is a lot more complexity. I would prefer = just having the server tell the client what authentication it MUST use. >>>>>>>>=20 >>>>>>>> As an alternative, the negotiation for credential method/type = could occur during the initial developer registration of the app. As in = your "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>>> Justin, >>>>>>>>>=20 >>>>>>>>> What you describe, though good intentioned, seems like a lot = of complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>>>>>>=20 >>>>>>>>> Think about someone writing a general purpose SCIM client or = OIDC client. Site as uses method 1 and 2, site b supports 2,3 and 4. = Site c only 5 and 6. So if each site is willing to negotiate authn, how = has this developer's coding been reduced? The developer will end up = having to implement all popular methods regardless of discovery or the = ability of the client to select. In fact, they have to do all the logic = you describe below AND implement all methods. >>>>>>>>>=20 >>>>>>>>> I have also thought through, does it matter since it is = optional? I think it does. If servers just ignore the param most of the = time, what value is there? >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>>>=20 >>>>>>>>>> In spite of what John seems to think, that dependency was = never there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>>>>>>=20 >>>>>>>>>> And I think that the Dynamic Registration protocol that we = have here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>>>>>>=20 >>>>>>>>>> 1) Accept what the client proposes and use that. This is of = course the ideal situation where everybody gets what they want, and this = can be brought about more often by a good discovery process. >>>>>>>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>>>>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>>>>>>> a) Accept what the server returns and use that, if it = supports it. This is also ideal because everybody is happy again. >>>>>>>>>> b) Reject what the server returns and either try the = registration again with another value or give up. >>>>>>>>>> c) Ignore what the server returns and fail when doing a token = request. This would be a dumb thing for a dumb client to do.=20 >>>>>>>>>>=20 >>>>>>>>>> Alternatively, the client could just not mention it and have = the server dictate what method it will use, and the client will either = accept, reject, or ignore it. This process applies to every parameter in = the system, from something innocuous as the client's TOS uri to = something as security-critical as the redirect_uri (which gets its own = special error message).=20 >>>>>>>>>>=20 >>>>>>>>>> I think that the assumption of full automation for all = clients to all servers is a red herring in the OAuth world for the = simple fact that the API that's being accessed/protected isn't going to = be universally compatible anyway. I agree fully that a well-specified = service discovery is important and we should, as a working group, help = figure out what that looks like. As mentioned above, several of us = already are. But I don't think it's helpful to conflate the registration = and discovery processes and turn them into some kind of negotiation = system. I think we can do a good job of making it widely useful without = that. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Justin, >>>>>>>>>>>=20 >>>>>>>>>>> Has the assumption of a discovery service defined by OIDC = been removed? >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Handful of minor changes in this revision, including = tightening the language around scopes and adding an absolute-URI based = mechanism for extending token_endpoint_auth_method (no registry, still). = No normative changes beyond removing an unreachable error state. = (Thanks, Nov.) Please check the diffs, we welcome feedback. I personally = think this is really getting close to final. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Justin >>>>>>>>>>>>=20 >>>>>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>>>>> John Bradley >>>>>>>>>>>>> Michael B. Jones >>>>>>>>>>>>> Maciej Machulak >>>>>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>>>>> Pages : 25 >>>>>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> This specification defines an endpoint and protocol for = dynamic >>>>>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization = Server and >>>>>>>>>>>>> methods for the dynamically registered client to manage = its >>>>>>>>>>>>> registration. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing 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=_A2092896-5CD9-4F36-AB4B-E9A5C890B70C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA5MjM1NTM4WjAjBgkqhkiG9w0BCQQxFgQUAhSbYnMK s5bu4onlPBr7RVlJiWcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEADHN+s6w3rtthEVGEOlTB1Px2tt/fKugPWaaRcMTm idJOcVu44G5ksI4qr9+5n8KyKP8jERbIRCLARKSOI7wGGLD7CBDCy1Yg/g86SlHFTO0fZq1Jzkzw fTuoa9HQ9Boi1EL3pRbRlW+XNn/i4HNhOdXs2A/H5j57mf2F+htOffy9TjBAfoF9KiV4piwJQGMm roRnJgh//KApyh+oNEDO2irvBBNGcocu2VufOHSOIPIAvBSRWGv5DHM7a6XxQZQzSa6YLQ37So4x qbP8oYbuIiq4ke0dQlwa4WHfIE9InzOinjFbJvmi1tC766xeW7oPfV0+FoS4q7qqLJcociC8MgAA AAAAAA== --Apple-Mail=_A2092896-5CD9-4F36-AB4B-E9A5C890B70C-- From phil.hunt@oracle.com Thu May 9 17:19:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8021F919D for ; Thu, 9 May 2013 17:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDbVHCUMsj2V for ; Thu, 9 May 2013 17:19:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 148D821F9048 for ; Thu, 9 May 2013 17:19:32 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4A0JVpt021537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 May 2013 00:19:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4A0JUCd026320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 May 2013 00:19:30 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4A0JT0B012470; Fri, 10 May 2013 00:19:29 GMT Received: from [192.168.67.123] (/207.239.114.206) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 May 2013 17:19:22 -0700 References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4C185ABE-7048-4003-BD5E-FA8ADE69B078@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 9 May 2013 17:19:09 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 10 May 2013 00:19:38 -0000 Well this is a last call discussion. So we have to get somewhere don't we? Phil On 2013-05-09, at 16:55, John Bradley wrote: > The downgrade is at runtime not at registration. It is signalling the met= hods the RP doesn't want the AS to support for the client_id. >=20 > We are not getting anywhere on this. The parameter is required for dynami= c registration of higher security clients at AS that support multiple token_= endpoint authentication types. >=20 > John > On 2013-05-09, at 4:46 PM, Phil Hunt wrote: >=20 >=20 >> Maybe i am not being clear. I feel the parameter must not be in the dyn r= eg request. The parameter should be in the response so that the client has n= o choice and no ability to downgrade.=20 >>=20 >> Phil >>=20 >> On 2013-05-09, at 16:37, Phil Hunt wrote: >>=20 >>> How does NOT allowing clients to choose authn type allow them to downgra= de. I am saying there is NO value in allowing this and that the parameter ne= eds to be removed.=20 >>>=20 >>> Phil >>>=20 >>> On 2013-05-09, at 16:03, John Bradley wrote: >>>=20 >>>> The issue is not allowing fake clients to dynamically downgrade, where t= he AS supports multiple methods. >>>>=20 >>>>=20 >>>> On 2013-05-09, at 3:58 PM, Phil Hunt wrote: >>>>=20 >>>>> You seem to now be talking about SAML endpoints rather than OAuth endp= oints. >>>>>=20 >>>>>=20 >>>>> I think you are confusing what the client gets back from the AS in ter= ms of the OAuth protocol vs. how the client authenticates to the AS. The p= arameter in question isn't about what assertions the AS returns to the clien= t. The case is about what credential the client must use with the AS to sat= isfy a particular AS's requirements.=20 >>>>>=20 >>>>> I haven't heard a reason for clients to be able to downgrade. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>>>>=20 >>>>>> Consider if you will a world where IdP support multiple LoA. >>>>>>=20 >>>>>> This allows a RP to register the method required for there use case. >>>>>>=20 >>>>>> If a Client requires the asymmetrically signed JWT assertions rather t= han http basic, it doesn't want the Authorization server accepting http_bas= ic for it's client_id. >>>>>>=20 >>>>>> The reason a client/RP would want to specify multiple LoA is the same= reason they may wan to in SAML or other protocols. >>>>>>=20 >>>>>> The issue is more that different clients will have different security= requirements and this allows them to dynamic register those. >>>>>>=20 >>>>>> If you allow 2 and 3 the one that need 3 will specify that. >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>> On 2013-05-09, at 3:32 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> Giving the client the choice lets the client choose lower LoA and do= wngrade. Surely it is the server that is taking the risk so the server has t= he right to set the requirements. >>>>>>>=20 >>>>>>> Why would a server tolerate multiple levels of LoA from the same cli= ent application? Why is that needed? >>>>>>>=20 >>>>>>> If a server allows 2 and 3, then all clients will choose 2 -- or at t= he very least your overall security drops to 2. This is not good. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>>>>=20 >>>>>>>> The client needs to be able to say only use a particular auth metho= d to disallow the Authorization server from providing a weaker method to an a= ttacker. =20 >>>>>>>>=20 >>>>>>>> This is a required parameter to allow a Authorization server to sup= port high and low LoA clients dynamically. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-09, at 2:44 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>>> Justin, >>>>>>>>>=20 >>>>>>>>> Just to progress towards resolving this issue, what I would like t= o understand is how specifying authentication type makes things simpler or m= ore inter-operable. I'm concerned that the logic you proposed early in the t= hread is a lot more complexity. I would prefer just having the server tell t= he client what authentication it MUST use. >>>>>>>>>=20 >>>>>>>>> As an alternative, the negotiation for credential method/type coul= d occur during the initial developer registration of the app. As in your "b= lue button" health case (did I remember that right), the initial registratio= n JWT would be used in the dynamic registration and allow the registration s= erver to observe any previously negotiated client preferences OOB of this sp= ec. Or, are you saying that individual instances have some need to change a= uthentication types on a per deployment basis independent of what the associ= ated authorization server wants them to use? If so what is it? >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>>>>=20 >>>>>>>>>> Justin, >>>>>>>>>>=20 >>>>>>>>>> What you describe, though good intentioned, seems like a lot of c= omplexity without getting an actual benefit. I would rather not have token_e= ndpoint_auth_method at all. >>>>>>>>>>=20 >>>>>>>>>> Think about someone writing a general purpose SCIM client or OIDC= client. Site as uses method 1 and 2, site b supports 2,3 and 4. Site c on= ly 5 and 6. So if each site is willing to negotiate authn, how has this dev= eloper's coding been reduced? The developer will end up having to implement a= ll popular methods regardless of discovery or the ability of the client to s= elect. In fact, they have to do all the logic you describe below AND impleme= nt all methods. >>>>>>>>>>=20 >>>>>>>>>> I have also thought through, does it matter since it is optional?= I think it does. If servers just ignore the param most of the time, what v= alue is there? >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>>>>=20 >>>>>>>>>>> In spite of what John seems to think, that dependency was never t= here. The whole discovery process is related, but separate, from registratio= n. It could happen using OIDC, it could happen with Bill Mills's LRDD link t= ypes, it could happen with Nat's proposed HAL-based system, it could happen b= y the developer going to the service provider's documentation page and readi= ng a bunch of text (which is what happens with large OAuth providers today) -= - it ultimately doesn't matter.=20 >>>>>>>>>>>=20 >>>>>>>>>>> And I think that the Dynamic Registration protocol that we have h= ere is robust against that kind of diversity. Let's take the token_endpoint_= auth_method parameter as an example. Let's say a client shows up to a servic= e it's just discovered -- through whatever means, we don't actually care. Th= is client either has some idea of what auth methods the server supports (thr= ough a discovery mechanism) or it doesn't. If it does, it will also know whi= ch methods it supports and it can pick one. If it doesn't, it will still kno= w which methods it supports and will just pick one. The server will then tak= e that information and do one of three things: >>>>>>>>>>>=20 >>>>>>>>>>> 1) Accept what the client proposes and use that. This is of cour= se the ideal situation where everybody gets what they want, and this can be b= rought about more often by a good discovery process. >>>>>>>>>>> 2) Reject what the client proposes with an error code (invalid_c= lient_metadata would cover this). The client then has to re-register with a d= ifferent value or just give up because the two systems are using different a= uth methods that can't be reconciled. >>>>>>>>>>> 3) Ignore what the client proposes and return the server's prefe= rred method. The client can then, in turn: >>>>>>>>>>> a) Accept what the server returns and use that, if it supports i= t. This is also ideal because everybody is happy again. >>>>>>>>>>> b) Reject what the server returns and either try the registratio= n again with another value or give up. >>>>>>>>>>> c) Ignore what the server returns and fail when doing a token re= quest. This would be a dumb thing for a dumb client to do.=20 >>>>>>>>>>>=20 >>>>>>>>>>> Alternatively, the client could just not mention it and have the= server dictate what method it will use, and the client will either accept, r= eject, or ignore it. This process applies to every parameter in the system, f= rom something innocuous as the client's TOS uri to something as security-cri= tical as the redirect_uri (which gets its own special error message).=20 >>>>>>>>>>>=20 >>>>>>>>>>> I think that the assumption of full automation for all clients t= o all servers is a red herring in the OAuth world for the simple fact that t= he API that's being accessed/protected isn't going to be universally compati= ble anyway. I agree fully that a well-specified service discovery is importa= nt and we should, as a working group, help figure out what that looks like. A= s mentioned above, several of us already are. But I don't think it's helpful= to conflate the registration and discovery processes and turn them into som= e kind of negotiation system. I think we can do a good job of making it wide= ly useful without that. >>>>>>>>>>>=20 >>>>>>>>>>> -- Justin >>>>>>>>>>>=20 >>>>>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Justin, >>>>>>>>>>>>=20 >>>>>>>>>>>> Has the assumption of a discovery service defined by OIDC been r= emoved? >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Handful of minor changes in this revision, including tightenin= g the language around scopes and adding an absolute-URI based mechanism for e= xtending token_endpoint_auth_method (no registry, still). No normative chang= es beyond removing an unreachable error state. (Thanks, Nov.) Please check t= he diffs, we welcome feedback. I personally think this is really getting clo= se to final. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A New Internet-Draft is available from the on-line Internet-D= rafts directories. >>>>>>>>>>>>>> This draft is a work item of the Web Authorization Protocol W= orking Group of the IETF. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration Proto= col >>>>>>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>>>>>> John Bradley >>>>>>>>>>>>>> Michael B. Jones >>>>>>>>>>>>>> Maciej Machulak >>>>>>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>>>>>> Pages : 25 >>>>>>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>> This specification defines an endpoint and protocol for dynam= ic >>>>>>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization Server a= nd >>>>>>>>>>>>>> methods for the dynamically registered client to manage its >>>>>>>>>>>>>> registration. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-1= 0 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Thu May 9 17:24:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325D21F919D for ; Thu, 9 May 2013 17:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR4PaMRXjxd4 for ; Thu, 9 May 2013 17:24:51 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 962A421F918C for ; Thu, 9 May 2013 17:24:51 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id k20so4052645iak.29 for ; Thu, 09 May 2013 17:24:51 -0700 (PDT) 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=ogz68ovrg5ty0ejVjGUyKFinhLBhpTPJ77LvFE/FCVA=; b=Qf2J1kwb008aHrXk+XDLIyuUNw2bqjYIlbnfsVIA6ul/UELM7GmU+TlMupRbsG9Ryv uU078L47k0z8FQB5P3Ctewa1/E4h5MmLo9VKxSwoB5NyLx72fIvMikExzQuPceKUgiDr N6lpt9DTL72q4Yg1hkBr9dxIfgV+2/+RhuW7QR5b9Iz+sTE9JWjiZmbs5Egots5Dozkk vAWEOoSWif3z5O43VUvCHvtMI5YzyKFncVhw/mY6Yu6u21CE6P15kVETuOZHz5fOLd4x 9Wo776L4ByPCYj1Nr+aieRx2uPoIPZyFiFIDmjXirJvvgMfYmItmdAoajKrD1BpyhUar sDkA== X-Received: by 10.50.136.138 with SMTP id qa10mr260833igb.74.1368145490970; Thu, 09 May 2013 17:24:50 -0700 (PDT) Received: from [192.168.51.155] (ip65-46-254-110.z254-46-65.customer.algx.net. [65.46.254.110]) by mx.google.com with ESMTPSA id d4sm714817igc.3.2013.05.09.17.24.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 17:24:49 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D3DA8CF3-5783-4415-A4C7-CDBE34139480"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4C185ABE-7048-4003-BD5E-FA8ADE69B078@oracle.com> Date: Thu, 9 May 2013 17:24:45 -0700 Message-Id: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> <86F7EC4C-DDF3-42B7-8355-A8C684CC2D2F@ve7jtb.com> <3B38531B-AED4-459C-9B9F-A57DE04AB467@oracle.com> <915B3011-AD0E-49C4-B655-707092419A11@ve7jtb.com> <77F7D0E4-B996-4F6F-9B69-16FA89984C3A@oracle.com> <529E31DF-1344-4051-A520-ED8569B6AF71@ve7jtb.com> <378F6108-F10B-466B-AF8B-5587AA23CE8E@oracle.com> <4C185ABE-7048-4003-BD5E-FA8ADE69B078@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlVBKobDC0qgxj7tLeirANO2p22PdF6WluAqeC0zdRg6/9x4Q6fVMdeQ0n0Bu0i7AUZSKRv Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.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, 10 May 2013 00:24:53 -0000 --Apple-Mail=_D3DA8CF3-5783-4415-A4C7-CDBE34139480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes but the two of us going back and forth seem not to be making = progress. I am still at the IDESG meeting if you want to get together. On 2013-05-09, at 5:19 PM, Phil Hunt wrote: > Well this is a last call discussion. So we have to get somewhere don't = we? >=20 > Phil >=20 > On 2013-05-09, at 16:55, John Bradley wrote: >=20 >> The downgrade is at runtime not at registration. It is signalling = the methods the RP doesn't want the AS to support for the client_id. >>=20 >> We are not getting anywhere on this. The parameter is required for = dynamic registration of higher security clients at AS that support = multiple token_endpoint authentication types. >>=20 >> John >> On 2013-05-09, at 4:46 PM, Phil Hunt wrote: >>=20 >>=20 >>> Maybe i am not being clear. I feel the parameter must not be in the = dyn reg request. The parameter should be in the response so that the = client has no choice and no ability to downgrade.=20 >>>=20 >>> Phil >>>=20 >>> On 2013-05-09, at 16:37, Phil Hunt wrote: >>>=20 >>>> How does NOT allowing clients to choose authn type allow them to = downgrade. I am saying there is NO value in allowing this and that the = parameter needs to be removed.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-05-09, at 16:03, John Bradley wrote: >>>>=20 >>>>> The issue is not allowing fake clients to dynamically downgrade, = where the AS supports multiple methods. >>>>>=20 >>>>>=20 >>>>> On 2013-05-09, at 3:58 PM, Phil Hunt wrote: >>>>>=20 >>>>>> You seem to now be talking about SAML endpoints rather than OAuth = endpoints. >>>>>>=20 >>>>>>=20 >>>>>> I think you are confusing what the client gets back from the AS = in terms of the OAuth protocol vs. how the client authenticates to the = AS. The parameter in question isn't about what assertions the AS = returns to the client. The case is about what credential the client = must use with the AS to satisfy a particular AS's requirements.=20 >>>>>>=20 >>>>>> I haven't heard a reason for clients to be able to downgrade. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>>>>>=20 >>>>>>> Consider if you will a world where IdP support multiple LoA. >>>>>>>=20 >>>>>>> This allows a RP to register the method required for there use = case. >>>>>>>=20 >>>>>>> If a Client requires the asymmetrically signed JWT assertions = rather than http basic, it doesn't want the Authorization server = accepting http_basic for it's client_id. >>>>>>>=20 >>>>>>> The reason a client/RP would want to specify multiple LoA is the = same reason they may wan to in SAML or other protocols. >>>>>>>=20 >>>>>>> The issue is more that different clients will have different = security requirements and this allows them to dynamic register those. >>>>>>>=20 >>>>>>> If you allow 2 and 3 the one that need 3 will specify that. >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>> On 2013-05-09, at 3:32 PM, Phil Hunt = wrote: >>>>>>>=20 >>>>>>>> Giving the client the choice lets the client choose lower LoA = and downgrade. Surely it is the server that is taking the risk so the = server has the right to set the requirements. >>>>>>>>=20 >>>>>>>> Why would a server tolerate multiple levels of LoA from the = same client application? Why is that needed? >>>>>>>>=20 >>>>>>>> If a server allows 2 and 3, then all clients will choose 2 -- = or at the very least your overall security drops to 2. This is not = good. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> The client needs to be able to say only use a particular auth = method to disallow the Authorization server from providing a weaker = method to an attacker. =20 >>>>>>>>>=20 >>>>>>>>> This is a required parameter to allow a Authorization server = to support high and low LoA clients dynamically. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-05-09, at 2:44 PM, Phil Hunt = wrote: >>>>>>>>>=20 >>>>>>>>>> Justin, >>>>>>>>>>=20 >>>>>>>>>> Just to progress towards resolving this issue, what I would = like to understand is how specifying authentication type makes things = simpler or more inter-operable. I'm concerned that the logic you = proposed early in the thread is a lot more complexity. I would prefer = just having the server tell the client what authentication it MUST use. >>>>>>>>>>=20 >>>>>>>>>> As an alternative, the negotiation for credential method/type = could occur during the initial developer registration of the app. As in = your "blue button" health case (did I remember that right), the initial = registration JWT would be used in the dynamic registration and allow the = registration server to observe any previously negotiated client = preferences OOB of this spec. Or, are you saying that individual = instances have some need to change authentication types on a per = deployment basis independent of what the associated authorization server = wants them to use? If so what is it? >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>>> Justin, >>>>>>>>>>>=20 >>>>>>>>>>> What you describe, though good intentioned, seems like a lot = of complexity without getting an actual benefit. I would rather not have = token_endpoint_auth_method at all. >>>>>>>>>>>=20 >>>>>>>>>>> Think about someone writing a general purpose SCIM client or = OIDC client. Site as uses method 1 and 2, site b supports 2,3 and 4. = Site c only 5 and 6. So if each site is willing to negotiate authn, how = has this developer's coding been reduced? The developer will end up = having to implement all popular methods regardless of discovery or the = ability of the client to select. In fact, they have to do all the logic = you describe below AND implement all methods. >>>>>>>>>>>=20 >>>>>>>>>>> I have also thought through, does it matter since it is = optional? I think it does. If servers just ignore the param most of the = time, what value is there? >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> In spite of what John seems to think, that dependency was = never there. The whole discovery process is related, but separate, from = registration. It could happen using OIDC, it could happen with Bill = Mills's LRDD link types, it could happen with Nat's proposed HAL-based = system, it could happen by the developer going to the service provider's = documentation page and reading a bunch of text (which is what happens = with large OAuth providers today) -- it ultimately doesn't matter.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> And I think that the Dynamic Registration protocol that we = have here is robust against that kind of diversity. Let's take the = token_endpoint_auth_method parameter as an example. Let's say a client = shows up to a service it's just discovered -- through whatever means, we = don't actually care. This client either has some idea of what auth = methods the server supports (through a discovery mechanism) or it = doesn't. If it does, it will also know which methods it supports and it = can pick one. If it doesn't, it will still know which methods it = supports and will just pick one. The server will then take that = information and do one of three things: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1) Accept what the client proposes and use that. This is of = course the ideal situation where everybody gets what they want, and this = can be brought about more often by a good discovery process. >>>>>>>>>>>> 2) Reject what the client proposes with an error code = (invalid_client_metadata would cover this). The client then has to = re-register with a different value or just give up because the two = systems are using different auth methods that can't be reconciled. >>>>>>>>>>>> 3) Ignore what the client proposes and return the server's = preferred method. The client can then, in turn: >>>>>>>>>>>> a) Accept what the server returns and use that, if it = supports it. This is also ideal because everybody is happy again. >>>>>>>>>>>> b) Reject what the server returns and either try the = registration again with another value or give up. >>>>>>>>>>>> c) Ignore what the server returns and fail when doing a = token request. This would be a dumb thing for a dumb client to do.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Alternatively, the client could just not mention it and = have the server dictate what method it will use, and the client will = either accept, reject, or ignore it. This process applies to every = parameter in the system, from something innocuous as the client's TOS = uri to something as security-critical as the redirect_uri (which gets = its own special error message).=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I think that the assumption of full automation for all = clients to all servers is a red herring in the OAuth world for the = simple fact that the API that's being accessed/protected isn't going to = be universally compatible anyway. I agree fully that a well-specified = service discovery is important and we should, as a working group, help = figure out what that looks like. As mentioned above, several of us = already are. But I don't think it's helpful to conflate the registration = and discovery processes and turn them into some kind of negotiation = system. I think we can do a good job of making it widely useful without = that. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Justin >>>>>>>>>>>>=20 >>>>>>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt = >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Justin, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Has the assumption of a discovery service defined by OIDC = been removed? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Handful of minor changes in this revision, including = tightening the language around scopes and adding an absolute-URI based = mechanism for extending token_endpoint_auth_method (no registry, still). = No normative changes beyond removing an unreachable error state. = (Thanks, Nov.) Please check the diffs, we welcome feedback. I personally = think this is really getting close to final. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On May 5, 2013, at 3:45 PM, >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Title : OAuth 2.0 Dynamic Client Registration = Protocol >>>>>>>>>>>>>>> Author(s) : Justin Richer >>>>>>>>>>>>>>> John Bradley >>>>>>>>>>>>>>> Michael B. Jones >>>>>>>>>>>>>>> Maciej Machulak >>>>>>>>>>>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>>>>>>>>>>> Pages : 25 >>>>>>>>>>>>>>> Date : 2013-05-05 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>>> This specification defines an endpoint and protocol for = dynamic >>>>>>>>>>>>>>> registration of OAuth 2.0 Clients at an Authorization = Server and >>>>>>>>>>>>>>> methods for the dynamically registered client to manage = its >>>>>>>>>>>>>>> registration. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>> = https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_D3DA8CF3-5783-4415-A4C7-CDBE34139480 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTEwMDAyNDQ1WjAjBgkqhkiG9w0BCQQxFgQUK6cRQas1 JHzbjw3MkKBzDa2dcgswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAff5CTsa4AgG1QeZfEOqXZWuk3uG2B+PF23FwePVW s/062KJvuNaMgBxiRf3A+xHxZ0ZBbIqmG0lT21dsU4YBLmuyYBo1ZUjBZ+HHDqHQLtQriNLmmrq7 mAlFtIznpd1D4Ar9lcueeo3uIjQk4nEIuDCJiodpT0pTS20vK3CehcGB2M7vlZlcuWRtyGpC0Aat cB47osMvusWiFVwgPiuj8WUCrqjPy8QKIqphC4/+5YN1e1ZIBHrIlL9raRzvOtO1fboldGpg2zwk zfvr+6paBzS/lyDAVM6jePwxylm5AKb+hr8a8zF14z3K/GnpbhXz+q0GHijy6sWJHUgRJKmWcQAA AAAAAA== --Apple-Mail=_D3DA8CF3-5783-4415-A4C7-CDBE34139480-- From hannes.tschofenig@gmx.net Mon May 13 01:04:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796D021F8F0E for ; Mon, 13 May 2013 01:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.282 X-Spam-Level: X-Spam-Status: No, score=-99.282 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fntDh8wy5auf for ; Mon, 13 May 2013 01:04:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE8621F8EAE for ; Mon, 13 May 2013 01:04:22 -0700 (PDT) Received: from 3capp-gmx-bs52.server.lan ([172.19.170.105]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MCvtd-1UlSWk0edH-009gKF for ; Mon, 13 May 2013 10:04:21 +0200 Received: from [194.251.119.197] by 3capp-gmx-bs52.server.lan with HTTP; Mon May 13 10:04:21 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: oauth@ietf.org Content-Type: text/html; charset=UTF-8 Date: Mon, 13 May 2013 10:04:21 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:VFWffVOFkVC0kvZMCsg7PtZEqZ8d4kwld/Sgl4JR+u1 6KSgBJYPpYv+nJw6wHerTPXOI3RQBI/sVcNvGB9CTS2Z7rVfvk AuKBdXs5x2DTjpr+GykxqWsVbZLdI0jwskNvvS1dCsfZOfpJVS m+m6rBH8NwxYsR1e1vuf8eVQ8a1KlkUfOvXPplFoAgo9Qyk5oB xnf+UtWzUCN6tMNXHg2yk0X3+d5WzDBKiRdaNIHjGzbyv5bdOm bV/vcb6VMNuXgSKXvopW+DlXdAkJNqsXa+3cEPmy4qK8ds8QRN n0osUY= Subject: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2013 08:04:27 -0000
Hi all, 
 
the OpenID Connect had gained some experience with using version control systems for editing specifications (and the use of issue trackers), see http://openid.bitbucket.org/. Based on a recent discussion in the IETF (among the working group chairs) I am wondering what your experience is with those tools and whether you see value in using these tools for document editing in the OAuth working group. 
 
Ciao
Hannes
 
From stephen.farrell@cs.tcd.ie Mon May 13 02:41:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2479121F93FF for ; Mon, 13 May 2013 02:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLCH9FGFMCza for ; Mon, 13 May 2013 02:41:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 49B0C21F93F0 for ; Mon, 13 May 2013 02:40:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F36DBE53; Mon, 13 May 2013 10:40:34 +0100 (IST) 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 rK0q+Q8CYmx6; Mon, 13 May 2013 10:40:34 +0100 (IST) Received: from [IPv6:2001:770:10:203:58bf:cc10:2360:c990] (unknown [IPv6:2001:770:10:203:58bf:cc10:2360:c990]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 01C2FBE35; Mon, 13 May 2013 10:40:33 +0100 (IST) Message-ID: <5190B512.6060903@cs.tcd.ie> Date: Mon, 13 May 2013 10:40:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2013 09:41:05 -0000 Hiya, On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: > Hi all, > the OpenID Connect had gained some experience with using version control systems > for editing specifications (and the use of issue trackers), see > http://openid.bitbucket.org/. Based on a recent discussion in the IETF (among > the working group chairs) I am wondering what your experience is with those > tools and whether you see value in using these tools for document editing in the > OAuth working group. Sounds like a fine plan if the wg want to try it. Only thing I'd note is that it means editors need to be *very* careful to bring discussion back to the wg list when that's needed, since you will likely get comments in the version control environment that are not cc'd to the wg list. (The IETF will be considering generic solutions for that, if you're interested get involved with the tools team.) In turn, I suspect that means that wg chairs need to make sure there's an editor who really gets when a change needs to be discussed on the list and when its ok to just fix a typo. The httpbis wg have some experience doing this btw and have hit that specific issue of comments being made on github but not the list. There's a recent thread [1] that ends with good advice from the wg chair. And in case someone asks, reasons why we need the wg list cc'd include open-ness and to be clear as to what's an IETF contribution. There're probably more but these are enough;-) Cheers, S. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Mon May 13 06:08:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C0F21F95EC for ; Mon, 13 May 2013 06:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTDP1IXQuJHj for ; Mon, 13 May 2013 06:08:43 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id F0AE321F95EA for ; Mon, 13 May 2013 06:08:42 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ep20so6114941lab.10 for ; Mon, 13 May 2013 06:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8emSbC4bp+0DTyzaJN7nSA8Xfy0ORJoguLhfT6NBHeA=; b=jiGHE0PLs1bPTW/KtZmB4km9EH071K3k1+XgFw7JM+218UFD96wLD4qH0Bs/qYQB+w knboB6AwM8xVNSGTKQo6LKnYx/QU+q9Iy+qRvTVymhLcS86FZ2mfnVSqjv0XIMttDNzn S3v9B0ckOTOtCmN9zAPGC220uXMisn9l3aVuI0eDIkI80ZSXvNjl7K/uZW71Hzf5KQoS A+nVsOXb2az9sk4XNywESc50RtUeu8fLq1RVt/MRYopDhI7cbkKVfPOXaZjarhDncaHv p5827hnhY35z3licNKV8Fg1907may0qkchG2ejV44oqZqztyzTeT4xr8KTzuz3sB7HkB oPXg== MIME-Version: 1.0 X-Received: by 10.112.6.135 with SMTP id b7mr12911502lba.104.1368450521786; Mon, 13 May 2013 06:08:41 -0700 (PDT) Received: by 10.112.73.170 with HTTP; Mon, 13 May 2013 06:08:41 -0700 (PDT) In-Reply-To: <5190B512.6060903@cs.tcd.ie> References: <5190B512.6060903@cs.tcd.ie> Date: Mon, 13 May 2013 22:08:41 +0900 Message-ID: From: Nat Sakimura To: Stephen Farrell Content-Type: multipart/alternative; boundary=14dae947303b3e729a04dc993757 Cc: oauth Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2013 13:08:44 -0000 --14dae947303b3e729a04dc993757 Content-Type: text/plain; charset=ISO-8859-1 I am probably biased since I am the one who introduced ticket driven version control to OIDF but it proved to be very valuable especially for transparency purposes. Each changes are linked to the ticket so it is easy to see why that change was made. As to the comments v.s. mailing list relationship is concerned, I think it is possible to forward all the comments to the list, and in case of IETF, it should do so. One feedback on the experience we had at OIDF is that XML Editing tools changes all sort of formatting making the diff at bitbucket useless. So, we had to resort to emacs/vim/ etc. my 2c. Nat Sakimura 2013/5/13 Stephen Farrell > > Hiya, > > On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: > > Hi all, > > the OpenID Connect had gained some experience with using version control > systems > > for editing specifications (and the use of issue trackers), see > > http://openid.bitbucket.org/. Based on a recent discussion in the IETF > (among > > the working group chairs) I am wondering what your experience is with > those > > tools and whether you see value in using these tools for document > editing in the > > OAuth working group. > > Sounds like a fine plan if the wg want to try it. Only thing I'd > note is that it means editors need to be *very* careful to bring > discussion back to the wg list when that's needed, since you will > likely get comments in the version control environment that are > not cc'd to the wg list. (The IETF will be considering generic > solutions for that, if you're interested get involved with the > tools team.) In turn, I suspect that means that wg chairs need > to make sure there's an editor who really gets when a change needs > to be discussed on the list and when its ok to just fix a typo. > > The httpbis wg have some experience doing this btw and have hit > that specific issue of comments being made on github but not the > list. There's a recent thread [1] that ends with good advice from > the wg chair. > > And in case someone asks, reasons why we need the wg list cc'd > include open-ness and to be clear as to what's an IETF > contribution. There're probably more but these are enough;-) > > Cheers, > S. > > [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html > > > > > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --14dae947303b3e729a04dc993757 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am probably biased since I am the one who introduced tic= ket driven version control to OIDF but it proved to be very valuable especi= ally for transparency purposes. Each changes are linked to the ticket so it= is easy to see why that change was made.=A0

As to the comments v.s. mailing list relationship is concern= ed, I think it is possible to forward all the comments to the list, and in = case of IETF, it should do so.=A0

One feedback on = the experience we had at OIDF is that XML Editing tools changes all sort of= formatting making the diff at bitbucket useless. So, we had to resort to e= macs/vim/ etc.=A0

my 2c.=A0

Nat Sakimura




2013/5/13 Stephen Farrell <stephen.farrel= l@cs.tcd.ie>

Hiya,

On 05/13/2013 09:04 AM, Hannes Tschofenig wrote:
> Hi all,
> the OpenID Connect had gained some experience with using version contr= ol systems
> for editing specifications (and the use of issue trackers), see
> http://open= id.bitbucket.org/. Based on a recent discussion in the IETF (among
> the working group chairs) I am wondering what your experience is with = those
> tools and whether you see value in using these tools for document edit= ing in the
> OAuth working group.

Sounds like a fine plan if the wg want to try it. Only thing I&= #39;d
note is that it means editors need to be *very* careful to bring
discussion back to the wg list when that's needed, since you will
likely get comments in the version control environment that are
not cc'd to the wg list. (The IETF will be considering generic
solutions for that, if you're interested get involved with the
tools team.) In turn, I suspect that means that wg chairs need
to make sure there's an editor who really gets when a change needs
to be discussed on the list and when its ok to just fix a typo.

The httpbis wg have some experience doing this btw and have hit
that specific issue of comments being made on github but not the
list. There's a recent thread [1] that ends with good advice from
the wg chair.

And in case someone asks, reasons why we need the wg list cc'd
include open-ness and to be clear as to what's an IETF
contribution. There're probably more but these are enough;-)

Cheers,
S.

[1] http://lists.w3.org/Archives/Public/ietf-http-= wg/2013AprJun/0334.html



> Ciao
> Hannes
>
>
>
> _______________________________________________
> 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



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--14dae947303b3e729a04dc993757-- From asanso@adobe.com Mon May 13 08:16:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998DC21F8F3E for ; Mon, 13 May 2013 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25R7mgZvDTC3 for ; Mon, 13 May 2013 08:16:16 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id AD73B21F915B for ; Mon, 13 May 2013 08:16:15 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUZEDv/a/aMNQ8F0C7BtAuMcsfLM0TfXM@postini.com; Mon, 13 May 2013 08:16:15 PDT 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 r4DFGD99002170 for ; Mon, 13 May 2013 08:16:13 -0700 (PDT) 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 r4DFG7Ai002827 for ; Mon, 13 May 2013 08:16:12 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 13 May 2013 08:15:12 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Mon, 13 May 2013 16:15:10 +0100 From: Antonio Sanso To: "oauth@ietf.org WG" Date: Mon, 13 May 2013 16:14:42 +0100 Thread-Topic: Recap of two well known OAuth related attacks Thread-Index: Ac5P7Kgk2IO6JLdIQgSAEFhZyghq+g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2013 15:16:21 -0000 Hi *, I wrote a blog post showing two well known OAuth related attacks. I paste h= ere the link for your consideration: http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-devi= l-wears.html Any comment is more than appreciated. Regards Antonio= From Michael.Jones@microsoft.com Wed May 15 10:25:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF221F8F12 for ; Wed, 15 May 2013 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGILG3NVR+P2 for ; Wed, 15 May 2013 10:25:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4385421F8EE3 for ; Wed, 15 May 2013 10:25:45 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.202) by BL2FFO11HUB017.protection.gbl (10.173.160.109) with Microsoft SMTP Server (TLS) id 15.0.687.1; Wed, 15 May 2013 17:25:43 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Wed, 15 May 2013 17:25:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Wed, 15 May 2013 17:24:46 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 has won the 2013 European Identity Award Thread-Index: Ac5RkRHsmjk4DQHIScSJKb59Lo5YdQ== Date: Wed, 15 May 2013 17:24:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436772FB86@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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436772FB86TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(31966008)(74366001)(49866001)(74662001)(47976001)(47736001)(512954002)(77982001)(74706001)(15202345002)(50986001)(81342001)(16236675002)(33656001)(80022001)(55846006)(4396001)(65816001)(6806003)(71186001)(16297215003)(51856001)(20776003)(54356001)(56776001)(74876001)(69226001)(81542001)(66066001)(53806001)(74502001)(54316002)(59766001)(44976003)(56816002)(16406001)(63696002)(46102001)(47446002)(79102001)(76482001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB017; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08476BC6EF Subject: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 17:25:52 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436772FB86TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm pleased to report that OAuth 2.0 has won the 2013 European Identity Awa= rd for Best Innovation/New Standard. I was honored to accept the award fro= m Kuppinger Cole at the 2013 European Identity and Cloud Conference on behalf of all who contributed to creati= ng the OAuth 2.0 standards [RFC 6749, R= FC 6750] and building solutions with th= em. (I also posted this announcement at http://self-issued.info/?p=3D1026.) -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436772FB86TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m pleased to report that OAuth 2.0 has won t= he 2013 European Identity Award for Best Innovation/New Standard.  I w= as honored to accept the award from Kuppinger Cole at the 2013 European Identity a= nd Cloud Conference on behalf of all who contributed to creating the OA= uth 2.0 standards [RFC 6749<= /a>, RFC 6750] and building s= olutions with them.

 

(I also posted this announcement at http://self-issued.info/?p=3D1026.)

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436772FB86TK5EX14MBXC283r_-- From igor.faynberg@alcatel-lucent.com Wed May 15 10:41:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16E21F8F83 for ; Wed, 15 May 2013 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSDInBC4tl3W for ; Wed, 15 May 2013 10:41:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E953621F8F4A for ; Wed, 15 May 2013 10:41:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r4FHfsc8029801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 May 2013 12:41:54 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r4FHfrUC026927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 15 May 2013 12:41:54 -0500 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 r4FHfrXj000789; Wed, 15 May 2013 12:41:53 -0500 (CDT) Message-ID: <5193C8E0.6070104@alcatel-lucent.com> Date: Wed, 15 May 2013 13:41:52 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000108010101050109080205" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:41:59 -0000 This is a multi-part message in MIME format. --------------000108010101050109080205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, Thanks! This is great news for all of us, and, finally, long-deserved positive publicity for OAuth 2.0. Long live OAuth! Igor On 5/15/2013 1:24 PM, Mike Jones wrote: > > I'm pleased to report that OAuth 2.0 has won the 2013 European > Identity Award for Best Innovation/New Standard. I was honored to > accept the award from Kuppinger Cole at the 2013 European Identity and > Cloud Conference on behalf of > all who contributed to creating the OAuth 2.0 standards [RFC 6749 > , RFC 6750 > ] and building solutions with them. > > (I also posted this announcement at http://self-issued.info/?p=1026.) > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000108010101050109080205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Thanks!  This is great news for all of us, and, finally, long-deserved positive publicity for OAuth 2.0.

Long live OAuth!

Igor

On 5/15/2013 1:24 PM, Mike Jones wrote:

I’m pleased to report that OAuth 2.0 has won the 2013 European Identity Award for Best Innovation/New Standard.  I was honored to accept the award from Kuppinger Cole at the 2013 European Identity and Cloud Conference on behalf of all who contributed to creating the OAuth 2.0 standards [RFC 6749, RFC 6750] and building solutions with them.

 

(I also posted this announcement at http://self-issued.info/?p=1026.)

 

                                                            -- Mike

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000108010101050109080205-- From hannes.tschofenig@gmx.net Wed May 15 11:34:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83B21F8A74 for ; Wed, 15 May 2013 11:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRGWhqehv0W5 for ; Wed, 15 May 2013 11:34:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B513421F89A5 for ; Wed, 15 May 2013 11:34:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lr5Xp-1Ty6qw2jvX-00edPj for ; Wed, 15 May 2013 20:34:17 +0200 Received: (qmail invoked by alias); 15 May 2013 18:34:17 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp002) with SMTP; 15 May 2013 20:34:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18YrqZZ3PkYeilMwTM1zn6C+sXEg83jrf771206hR fFhYRzPVPwmZHH Message-ID: <5193D528.4030901@gmx.net> Date: Wed, 15 May 2013 21:34:16 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 18:34:23 -0000 That's great to hear. Hope you have taken some pictures from the awards ceremony. On 05/15/2013 08:24 PM, Mike Jones wrote: > Im pleased to report that OAuth 2.0 has won the 2013 European Identity > Award for Best Innovation/New Standard. I was honored to accept the > award from Kuppinger Cole at the 2013 European Identity and Cloud > Conference on behalf of all who > contributed to creating the OAuth 2.0 standards [RFC 6749 > , RFC 6750 > ] and building solutions with them. > > (I also posted this announcement at http://self-issued.info/?p=1026.) > > -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Wed May 15 12:57:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772D621F8733 for ; Wed, 15 May 2013 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ83EiSsoFUc for ; Wed, 15 May 2013 12:57:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 452FE21F871C for ; Wed, 15 May 2013 12:57:21 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.202) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.687.1; Wed, 15 May 2013 19:57:20 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Wed, 15 May 2013 19:57:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 15 May 2013 19:57:13 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award Thread-Index: Ac5RkRHsmjk4DQHIScSJKb59Lo5YdQACbvgAAALZZAA= Date: Wed, 15 May 2013 19:57:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436772FF1D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> <5193D528.4030901@gmx.net> In-Reply-To: <5193D528.4030901@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(377454002)(479174002)(24454002)(13464003)(199002)(189002)(33656001)(79102001)(47976001)(56816002)(20776003)(69226001)(81342001)(23726002)(81542001)(49866001)(63696002)(50986001)(47736001)(4396001)(47446002)(76482001)(16406001)(54316002)(74662001)(47776003)(54356001)(74876001)(55846006)(44976003)(66066001)(6806003)(65816001)(80022001)(77982001)(74366001)(46102001)(59766001)(46406003)(31966008)(15202345002)(56776001)(74706001)(51856001)(53806001)(74502001)(50466002)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB011; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08476BC6EF Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 19:57:50 -0000 Link to some photos: https://www.facebook.com/media/set/?set=3Da.1015157794= 4262856.1073741829.503057855&type=3D1&l=3D4f3fe44c99. I'll add the officia= l ones from Kuppinger Cole once they're posted. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Wednesday, May 15, 2013 11:34 AM To: Mike Jones Cc: oauth@ietf.org; hannes.tschofenig@gmx.net Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award That's great to hear. Hope you have taken some pictures from the awards ceremony. On 05/15/2013 08:24 PM, Mike Jones wrote: > I'm pleased to report that OAuth 2.0 has won the 2013 European=20 > Identity Award for Best Innovation/New Standard. I was honored to=20 > accept the award from Kuppinger Cole at the 2013 European Identity and=20 > Cloud Conference on behalf of=20 > all who contributed to creating the OAuth 2.0 standards [RFC 6749=20 > , RFC 6750=20 > ] and building solutions with them. > > (I also posted this announcement at http://self-issued.info/?p=3D1026.) > > -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Wed May 15 13:11:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33E621F85CE for ; Wed, 15 May 2013 13:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+EFOzeYHsq4 for ; Wed, 15 May 2013 13:11:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7C21F853A for ; Wed, 15 May 2013 13:11:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 08CFD1F07DB; Wed, 15 May 2013 16:11:34 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EE1E71F027F; Wed, 15 May 2013 16:11:33 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Wed, 15 May 2013 16:11:33 -0400 From: "Richer, Justin P." To: Nat Sakimura Thread-Topic: [OAUTH-WG] Use of Version Control Systems for Draft Editing Thread-Index: AQHOT7B/uAAqrhn+I0ao7H4KgkqSGpkDH4EAgAA6JoCAA5rQgA== Date: Wed, 15 May 2013 20:11:33 +0000 Message-ID: <265449F1-D674-44CE-957B-204E765B6D15@mitre.org> References: <5190B512.6060903@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.156] Content-Type: multipart/alternative; boundary="_000_265449F1D67444CE957B204E765B6D15mitreorg_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 20:11:38 -0000 --_000_265449F1D67444CE957B204E765B6D15mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have already been using an approach like this for all of the drafts that = I edit, most notably the DynReg WG document and both the Introspection and = Chaining individual submissions. I run everything through my GitHub reposit= ory here: https://github.com/jricher/oauth-spec/ I use the issue tracker there to note down things that come up in the WG co= nversations on the list, so that when I actually do get to go edit things, = I don't forget anything. Once or twice, I have gotten issues submitted dire= ctly to github, but the actual conversation around any real changes (beyond= typos) always comes back to the list. I do think it would be worthwhile to= connect the mailing list to the notifications of the tracker for official = documents. It would be fairly easy to set up a GitHub organization that's b= acked by the mailing list's address for notifications, and I think other de= velopment platforms have similar capabilities. However, I completely disagree with ODIF's decision regarding editing tools= . I've made some edits to the OIDF specs myself, and I find the "plain text= editor" rule to be a draconian overreaction that makes creating good edits= tedious, slow, and error-prone. In my personal experience, good tools like= XML Mind's XML2RFC plugin are profoundly useful, and the formatting artifa= cts they create are minimal and easily ignored. The diffs that are tracked = in Git are *far* from useless, and if you ask me, if you want to do a *real= * diff on these documents you'd use the rfcdiff anyway, which ignores the X= ML formatting changes and focuses on the actual content. It's not perfect e= ither, but it's far from useless. -- Justin On May 13, 2013, at 9:08 AM, Nat Sakimura > wrote: I am probably biased since I am the one who introduced ticket driven versio= n control to OIDF but it proved to be very valuable especially for transpar= ency purposes. Each changes are linked to the ticket so it is easy to see w= hy that change was made. As to the comments v.s. mailing list relationship is concerned, I think it = is possible to forward all the comments to the list, and in case of IETF, i= t should do so. One feedback on the experience we had at OIDF is that XML Editing tools cha= nges all sort of formatting making the diff at bitbucket useless. So, we ha= d to resort to emacs/vim/ etc. my 2c. Nat Sakimura 2013/5/13 Stephen Farrell > Hiya, On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: > Hi all, > the OpenID Connect had gained some experience with using version control = systems > for editing specifications (and the use of issue trackers), see > http://openid.bitbucket.org/. Based on a recent discussion in the IETF (a= mong > the working group chairs) I am wondering what your experience is with tho= se > tools and whether you see value in using these tools for document editing= in the > OAuth working group. Sounds like a fine plan if the wg want to try it. Only thing I'd note is that it means editors need to be *very* careful to bring discussion back to the wg list when that's needed, since you will likely get comments in the version control environment that are not cc'd to the wg list. (The IETF will be considering generic solutions for that, if you're interested get involved with the tools team.) In turn, I suspect that means that wg chairs need to make sure there's an editor who really gets when a change needs to be discussed on the list and when its ok to just fix a typo. The httpbis wg have some experience doing this btw and have hit that specific issue of comments being made on github but not the list. There's a recent thread [1] that ends with good advice from the wg chair. And in case someone asks, reasons why we need the wg list cc'd include open-ness and to be clear as to what's an IETF contribution. There're probably more but these are enough;-) Cheers, S. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html > 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 -- 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_265449F1D67444CE957B204E765B6D15mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I have already been using an approach like this for all of the drafts that = I edit, most notably the DynReg WG document and both the Introspection and = Chaining individual submissions. I run everything through my GitHub reposit= ory here:


I use the issue tracker there to note down things that come up in the = WG conversations on the list, so that when I actually do get to go edit thi= ngs, I don't forget anything. Once or twice, I have gotten issues submitted= directly to github, but the actual conversation around any real changes (beyond typos) always comes back to t= he list. I do think it would be worthwhile to connect the mailing list to t= he notifications of the tracker for official documents. It would be fairly = easy to set up a GitHub organization that's backed by the mailing list's address for notifications, and I think= other development platforms have similar capabilities. 

However, I completely disagree with ODIF's decision regarding editing = tools. I've made some edits to the OIDF specs myself, and I find the &= quot;plain text editor" rule to be a draconian overreaction that makes= creating good edits tedious, slow, and error-prone. In my personal experience, good tools like XML Mind's XML2RFC plugin are prof= oundly useful, and the formatting artifacts they create are minimal and eas= ily ignored. The diffs that are tracked in Git are *far* from useless, and = if you ask me, if you want to do a *real* diff on these documents you'd use the rfcdiff anyway, which ignor= es the XML formatting changes and focuses on the actual content. It's not p= erfect either, but it's far from useless. 

 -- Justin



On May 13, 2013, at 9:08 AM, Nat Sakimura <sakimura@gmail.com>
 wrote:

I am probably biased since I am the one who introduced tic= ket driven version control to OIDF but it proved to be very valuable especi= ally for transparency purposes. Each changes are linked to the ticket so it= is easy to see why that change was made. 

As to the comments v.s. mailing list relationship is concerned, I thin= k it is possible to forward all the comments to the list, and in case of IE= TF, it should do so. 

One feedback on the experience we had at OIDF is that XML Editing tool= s changes all sort of formatting making the diff at bitbucket useless. So, = we had to resort to emacs/vim/ etc. 

my 2c. 

Nat Sakimura




2013/5/13 Stephen Farrell <= stephen.farr= ell@cs.tcd.ie>

Hiya,

On 05/13/2013 09:04 AM, Hannes Tschofenig wrote:
> Hi all,
> the OpenID Connect had gained some experience with using version contr= ol systems
> for editing specifications (and the use of issue trackers), see
> http://open= id.bitbucket.org/. Based on a recent discussion in the IETF (among
> the working group chairs) I am wondering what your experience is with = those
> tools and whether you see value in using these tools for document edit= ing in the
> OAuth working group.

Sounds like a fine plan if the wg want to try it. Only thing I'd
note is that it means editors need to be *very* careful to bring
discussion back to the wg list when that's needed, since you will
likely get comments in the version control environment that are
not cc'd to the wg list. (The IETF will be considering generic
solutions for that, if you're interested get involved with the
tools team.) In turn, I suspect that means that wg chairs need
to make sure there's an editor who really gets when a change needs
to be discussed on the list and when its ok to just fix a typo.

The httpbis wg have some experience doing this btw and have hit
that specific issue of comments being made on github but not the
list. There's a recent thread [1] that ends with good advice from
the wg chair.

And in case someone asks, reasons why we need the wg list cc'd
include open-ness and to be clear as to what's an IETF
contribution. There're probably more but these are enough;-)

Cheers,
S.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html


> Ciao
> Hannes
>
>
>
> _______________________________________________
> 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



--
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_265449F1D67444CE957B204E765B6D15mitreorg_-- From igor.faynberg@alcatel-lucent.com Wed May 15 13:21:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3C21F86CE for ; Wed, 15 May 2013 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr9u-TMziHjF for ; Wed, 15 May 2013 13:21:26 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6821F86AE for ; Wed, 15 May 2013 13:21:25 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4FKLOni000368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 May 2013 15:21:24 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r4FKLN0E011718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 15 May 2013 15:21:24 -0500 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 r4FKLNYN023138; Wed, 15 May 2013 15:21:23 -0500 (CDT) Message-ID: <5193EE43.2000202@alcatel-lucent.com> Date: Wed, 15 May 2013 16:21:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> <5193D528.4030901@gmx.net> <4E1F6AAD24975D4BA5B16804296739436772FF1D@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436772FF1D@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------040509020205050606050807" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 20:21:30 -0000 This is a multi-part message in MIME format. --------------040509020205050606050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Where is the link to some /bottles? /Time to celebrate! On 5/15/2013 3:57 PM, Mike Jones wrote: > Link to some photos: https://www.facebook.com/media/set/?set=a.10151577944262856.1073741829.503057855&type=1&l=4f3fe44c99. I'll add the official ones from Kuppinger Cole once they're posted. > > -- Mike > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Wednesday, May 15, 2013 11:34 AM > To: Mike Jones > Cc: oauth@ietf.org; hannes.tschofenig@gmx.net > Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award > > That's great to hear. > > Hope you have taken some pictures from the awards ceremony. > > On 05/15/2013 08:24 PM, Mike Jones wrote: >> I'm pleased to report that OAuth 2.0 has won the 2013 European >> Identity Award for Best Innovation/New Standard. I was honored to >> accept the award from Kuppinger Cole at the 2013 European Identity and >> Cloud Conference on behalf of >> all who contributed to creating the OAuth 2.0 standards [RFC 6749 >> , RFC 6750 >> ] and building solutions with them. >> >> (I also posted this announcement at http://self-issued.info/?p=1026.) >> >> -- 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 --------------040509020205050606050807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Where is the link to some bottles?  Time to celebrate!

On 5/15/2013 3:57 PM, Mike Jones wrote: 
Link to some photos: https://www.facebook.com/media/set/?set=a.10151577944262856.1073741829.503057855&type=1&l=4f3fe44c99.  I'll add the official ones from Kuppinger Cole once they're posted.

				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] 
Sent: Wednesday, May 15, 2013 11:34 AM
To: Mike Jones
Cc: oauth@ietf.org; hannes.tschofenig@gmx.net
Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award

That's great to hear.

Hope you have taken some pictures from the awards ceremony.

On 05/15/2013 08:24 PM, Mike Jones wrote:

I'm pleased to report that OAuth 2.0 has won the 2013 European 
Identity Award for Best Innovation/New Standard.  I was honored to 
accept the award from Kuppinger Cole at the 2013 European Identity and 
Cloud Conference <http://www.id-conf.com/events/eic2013/> on behalf of 
all who contributed to creating the OAuth 2.0 standards [RFC 6749 
<http://tools.ietf.org/html/rfc6749>, RFC 6750 
<http://tools.ietf.org/html/rfc6750>] and building solutions with them.

(I also posted this announcement at http://self-issued.info/?p=1026.)

                                                             -- 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
--------------040509020205050606050807-- From jricher@mitre.org Wed May 15 13:22:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16DE21F86D8 for ; Wed, 15 May 2013 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma5JiJNSJk06 for ; Wed, 15 May 2013 13:22:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87D11E80AD for ; Wed, 15 May 2013 13:22:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE1DB22600EF; Wed, 15 May 2013 16:21:55 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 98A2F1F027F; Wed, 15 May 2013 16:21:55 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Wed, 15 May 2013 16:21:55 -0400 From: "Richer, Justin P." To: Antonio Sanso Thread-Topic: [OAUTH-WG] Recap of two well known OAuth related attacks Thread-Index: Ac5P7Kgk2IO6JLdIQgSAEFhZyghq+gB3rYAA Date: Wed, 15 May 2013 20:21:54 +0000 Message-ID: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.156] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 20:22:26 -0000 The biggest problem with this attack is the passing of the access token to = a backend server (and its subsequent passing of that token to someone else)= and the assumption that the presentation of the access token means that th= e user is authenticated and present. It simply doesn't mean that, and this = is a bad assumption that unfortunately many people make thanks to providers= like Facebook using OAuth (or, mostly-OAuth since they're not actually RFC= compliant) in the authentication protocol. It's also a problem that so many people are using the implicit flow "becaus= e it's easy", missing the point of why it's there in the first place. The i= mplicit flow is really only intended for cases where you can't hide secrets= from the user agent, cases like an in-browser application. The flow diagra= ms that you have don't fit the implicit flow very well at all, since the ac= cess token is getting passed back to some other service.=20 -- Justin On May 13, 2013, at 11:14 AM, Antonio Sanso wrote: > Hi *, >=20 > I wrote a blog post showing two well known OAuth related attacks. I paste= here the link for your consideration: >=20 > http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-de= vil-wears.html >=20 > Any comment is more than appreciated. >=20 > Regards >=20 > Antonio > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed May 15 13:30:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1C11E80DF for ; Wed, 15 May 2013 13:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9yjdZS-D8ef for ; Wed, 15 May 2013 13:30:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA34421F86DD for ; Wed, 15 May 2013 13:30:50 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4FKUm4s025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 May 2013 20:30:48 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4FKUmZO020484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 May 2013 20:30:49 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4FKUmmd004380 for ; Wed, 15 May 2013 20:30:48 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 May 2013 13:30:48 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_3FBFFF9E-CB0F-41BD-9A42-2C91D677ACF3" Date: Wed, 15 May 2013 13:30:54 -0700 Message-Id: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 20:30:56 -0000 --Apple-Mail=_3FBFFF9E-CB0F-41BD-9A42-2C91D677ACF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. Overall =20 ----------- I think dynamic registration is a critical part of the OAuth framework = now that we are starting to consider how individual client applications = should operate when there is one or more deployments of a particular = resource API. We've moved from the simple use case of a single API = provider like Facebook or Flickr and moved on to standards based, open = source based, and commercial based deployments where there are multiple = service endpoints and many clients to manage. The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: 1. How is a new client application recognized for the first time when = deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? How does a = client authenticate the first time and subsequent times to the = registration service? 3. How is versioning of clients managed? Should each new version of a = client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. 4. What is the registration access token? Why is is used? What is its = life-cycle? When is it issued, when is it changed? When is it deleted? If we distinguish between first time registration of a particular client = software package, it is possible that somethings like authentication = method can be negotiate in or out-of-band at that time. Subsequent = registrations should only have parameters for items that could change = per deployment (like tos_uri). I think token_endpoint_auth_method is = one thing that should not be negotiated per instance. When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? Specific items: --------------------- "token_endpoint_auth_method" There is some confusion as to whether this applies to server or client = authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" * Currently, the API only supports a single value instead of an array. = If the purpose is to allow the client to know what auth methods it = supports, this should be an array indicated what methods the client = supports - or it should not be used. * There is no authn method for "client_secret_saml" or = "private_key_saml". There are no profiles referenced or defined for "client_secret_jwt" or = "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced = cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. A possible suggestion is to remove client_secret_jwt and private_key_jwt = and define those as register extensions since these profiles are not = defined. About "tos_uri" and "policy_uri" The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? Also, aren't these really URIs or are they meant to be URLs? About "jwks_uri" A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 =20 Should be URL instead of URI? Section 2.1 In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. =93As such, a server supporting these fields SHOULD take steps to ensure = that a client cannot register itself into an inconsistent state.=94 We may want to define more detailed HTTP error response. E.g. 400 status = code + defined error code (=93invalid_client_metadata=94)? Section 2.2 May want to add: When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in = =93client_name=94, instead of =93client_name#en=94) the OAuth server may = use interpret the language used based on server configuration or = heuristics. Section 3 Existing text: =93In order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=94 I would suggest to change the first =93SHOULD=94 to =93MAY=94. In most = cloud services, the first client is registered by a human user. Then, = other clients can be further used to automate other client registration. = So, the first request would typically come with an authenticated user = identity.=20 On the flip side, the earlier paragraph: =93The 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.=94 I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= . That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. About section 4.3: If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the Registration Access Token used to make this request SHOULD be immediately revoked. If the Client does not exist on this server, shouldn't it return a "404 = Not Found"? If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. =20 About section 5.1: Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. Suggest rename =93expires_at=94 to =93client_secret_expires_at=94,=20 Suggest to rename =93issued_at=94 to =93id_issued_at=94 Section 7 When a client_secret expires is it the intent that clients do an update = or refresh to get a new client secret? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_3FBFFF9E-CB0F-41BD-9A42-2C91D677ACF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Finally, there seems to = be an inconsistent style approach with 












urn:ietf:params:oauth:grant-type:jwt-bearer = is missing.

=93As such, a server = supporting these fields SHOULD take steps to ensure that a client = cannot register itself into an inconsistent state.=94

We may want = to define more detailed HTTP error response. E.g. 400 status code + = defined error code (=93invalid_client_metadata=94)?
Section = 2.2

May want to add:

When =93#=94 language tag is missing, (e.g. =93#en=94 is = missing in =93client_name=94, instead of =93client_name#en=94) the = OAuth server may use interpret the language used based on = server configuration or = heuristics.

Section = 3

Existing text:

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

I would suggest to change the first =93SHOULD=94= to =93MAY=94.   In most cloud services, the first client = is registered by a human user. Then, other clients can be = further used to automate other client registration.  So, = the first request would typically come with an authenticated user = identity. 

On the flip side, the earlier = paragraph:

=93The 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.=94

I tend to think it = would be better to change this =93MAY=94 to =93SHOULD=94.

That = access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.

About section = 4.3:

If the client does not exist on this =
server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately =
revoked.

If the Client does not exist = on this server, shouldn't it return a "404 Not Found"?

If = revoking the registration access token, is it bound to a single client = registration?  This is not clear.  What is the lifecycle = around registration access token? Only hint is in the Client Information = Response in section 5.1.
 
About section = 5.1:

Is registration_access_token unique?  Or = is it shared by multiple instances?   If shared, then = registration_access_token can't be revoked on delete of = client.

Suggest rename =93expires_at=94 to = =93client_secret_expires_at=94, 

Suggest to rename = =93issued_at=94 to =93id_issued_at=94

Section = 7

When a client_secret expires is it the = intent that clients do an update or refresh to get a new client = secret?

Phil

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





= --Apple-Mail=_3FBFFF9E-CB0F-41BD-9A42-2C91D677ACF3-- From melvincarvalho@gmail.com Wed May 15 14:15:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52B21F907E for ; Wed, 15 May 2013 14:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3IvwDjF4E3Y for ; Wed, 15 May 2013 14:15:43 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3321F8733 for ; Wed, 15 May 2013 14:15:43 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fg20so32984lab.29 for ; Wed, 15 May 2013 14:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hzIykeyTnMKba+TFObP11IieWHEjDu7Hl7SOE5fjU+0=; b=A/HW5epMiMxiS3JajW4D5Jl3L4DcJuMgKd09EP3wNvY631zhFbE7NeBO6eN5rQAlIq tkzHCBHLTwB91ovWtQVb51vIryZsH71HevR1rzjugQON0WjTqGtSWLjZCHVrMWWpHRCS 7ZlhlNwsUQPVipmg0NXfIUmefKnS70TsLdTqEHKEIpyUQxbFk63JNHnrM6wE+HdPon/d AAv9zPp0pN9bt4npFmK9GOqMoBXBG/VfGvwk9g4QbWukINdlz+fCVOZ1bAv97mbQKljx Zls3Z54CwoDobT5KLu5snbs3UPRc6u5qJQOskcxfxvgUry5Ct7LXkzD8Pkosz0JNwi8l 9nvQ== MIME-Version: 1.0 X-Received: by 10.112.156.133 with SMTP id we5mr18618316lbb.22.1368652542033; Wed, 15 May 2013 14:15:42 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Wed, 15 May 2013 14:15:41 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 15 May 2013 23:15:41 +0200 Message-ID: From: Melvin Carvalho To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2680c96c78304dcc840e9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 15 May 2013 21:15:44 -0000 --001a11c2680c96c78304dcc840e9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15 May 2013 19:24, Mike Jones wrote: > I=92m pleased to report that OAuth 2.0 has won the 2013 European Identit= y > Award for Best Innovation/New Standard. I was honored to accept the awar= d > from Kuppinger Cole at the 2013 European Identity and Cloud Conferenceon behalf of all who contributed to cr= eating the OAuth 2.0 standards [RFC > 6749 , RFC 6750] > and building solutions with them.**** > > ** ** > > (I also posted this announcement at http://self-issued.info/?p=3D1026.) > Congrats! > **** > > ** ** > > -- Mike**** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c2680c96c78304dcc840e9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 15 May 2013 19:24, Mike Jones <Michael.Jones@microsof= t.com> wrote:

I=92m pleased to report that OAuth 2.0 has won the 2= 013 European Identity Award for Best Innovation/New Standard.=A0 I was hono= red to accept the award from Kuppinger Cole at the 2013 E= uropean Identity and Cloud Conference on behalf of all who contributed = to creating the OAuth 2.0 standards [RFC 6749, RFC 6750] and building solutions with them.

=A0

(I also posted this announcement at http://self-issued.info/?p=3D1026.)

Congrats!
=A0

=

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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


--001a11c2680c96c78304dcc840e9-- From jricher@mitre.org Wed May 15 17:54:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1B1F0D31 for ; Wed, 15 May 2013 17:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.393 X-Spam-Level: X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryJZ2AcWagSC for ; Wed, 15 May 2013 17:54:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D09C91F0D27 for ; Wed, 15 May 2013 17:53:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F04741F0F2F; Wed, 15 May 2013 20:53:58 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DF0141F0F2B; Wed, 15 May 2013 20:53:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Wed, 15 May 2013 20:53:58 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUasmqYhOH+9Tj0KmdipKXhmNOJkHP2iA Date: Thu, 16 May 2013 00:53:58 +0000 Message-ID: <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> In-Reply-To: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.156] Content-Type: multipart/alternative; boundary="_000_6AF52CCD4D6B469684653345FFFDBE9Cmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 00:54:05 -0000 --_000_6AF52CCD4D6B469684653345FFFDBE9Cmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Phil, many thanks for the extremely thorough review! It is very useful inde= ed. My comments and responses to each point are inline. On May 15, 2013, at 4:30 PM, Phil Hunt > wrote: It seems unfortunate that I have not gotten a chance to get into this level= of detail much earlier. But then, I guess that's what LC review is for! My= apologies for not getting many of these concerns to the WG much earlier. Overall ----------- I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Faceboo= k or Flickr and moved on to standards based, open source based, and commerc= ial based deployments where there are multiple service endpoints and many c= lients to manage. The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec: 1. How is a new client application recognized for the first time when depl= oyed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does c= hange with versions? In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together = classes of clients (see below for more discussion on this very point). But = in general, a client is just going to show up as a new instance to the AS a= nd get issued a new, unique client_id, and that's that. 2. How are client credentials managed. Are we assuming client credentials = have a limited lifetime or rotation policy? The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it = may be after multiple refactorings), then I welcome suggestions and specifi= c text as to how to make that clear. How does a client authenticate the first time and subsequent times to the= registration service? This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either: - Not authenticate at all (this is the true public, open registration, an= d it is recommended that servers do this) - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the= spec, by design. Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is= an OAuth 2.0 Bearer token that is unique to the client instance. 3. How is versioning of clients managed? Should each new version of a clie= nt require a change in client registration including possibly changing clie= nt_id and authentication credential? I don't have a strong feeling, but it = is something that implementors should consider. This is up to the AS, really, and I don't think that any global policy woul= d ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding= a discussion in the security considerations if it merits mentioning though= , so that we can help both client developers and server developers institut= e reasonably good policy. 4. What is the registration access token? Why is is used? What is its life= -cycle? When is it issued, when is it changed? When is it deleted? See the response above above and the definition in =A71.2: Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client. If this can be clarified, I welcome text suggestions. If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like = tos_uri). I think token_endpoint_auth_method is one thing that should not = be negotiated per instance. When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiated or be di= fferent for the same client software? Should not all instances use the same= authentication method. I'm confused by this -- as far as the dynamic registration spec is concerne= d, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy o= f the client code connecting to any new authorization server. That pairing = creates the client_id, and therefore the instance, and therefore the regist= ration access token, and therefore the registration itself at a conceptual = level. So there is no way other than per-instance for a client to ask for a= particular token_endpoint_auth_method. Where else would the AS find out ab= out it? And there's no way other than per-instance for the server to tell t= he client which token_endpoint_auth_method to use. All instances will proba= bly ask for the same token_endpoint_auth_method from all auth servers they = talk to, right? And each AS will tell each instance that registers with it = to use a particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a significant = amount of other machinery. Which is not to say that it's not useful in some circumstances to tie toget= her different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the= initial access token that the clients use to call the registration endpoin= t the first time, as well as a discovery protocol against a centralized se= rver that handles pre-registration. All of this machinery is, in my opinion= , a stupendous overkill for the general case, though if some folks find use= for it outside of BB+ then it'd be a good thing to abstract out and make i= ts own spec that extends the Dyn Reg spec in a fully compatible way. Furthe= rmore, even in Blue Button+ we specify that all auth servers MUST also acce= pt open registration, without an initial access token, where the client sim= ply shows up and says "hey, here are my parameters." The auth server has no= way to know in this case any kind of out-of-band negotiation for different= things. In BB+ we are writing very specific policy guidelines about how to= present the UX and things to the end user for all of these different cases= . But again, all of this is specific to the BB+ use case, and I don't see v= alue in dragging it in to the registration spec on its own. I believe it wo= uld be far too limiting. Finally, there seems to be an inconsistent style approach with draft-hardjo= no-oauth-resource-reg which uses ETags. Should this draft do so as well? That's an individual submission, not a working group draft. Nobody has, unt= il now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I person= ally don't see their utility here, though, and I wouldn't want to include a= wholly new mechanism this late. Specific items: --------------------- "token_endpoint_auth_method" There is some confusion as to whether this applies to server or client auth= entication. Suggest renaming parameter to "token_endpoint_client_auth_meth= od" This is the first I've heard of this particular confusion. I'm fine with ei= ther name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. * Currently, the API only supports a single value instead of an array. If = the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it s= hould not be used. I would rather like this to be an array, personally, and brought it up with= the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% posi= tive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. Also note that this field, like all others in =A72, represents two things: = the client telling the server "I want to use this value for this field", an= d the server telling the client "this is the value you have for this field"= . It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator i= s nice enough to tell you what their decision was instead of just decapitat= ing you. * There is no authn method for "client_secret_saml" or "private_key_saml". Nobody has really asked that these two be included or specified. The extens= ion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use= ? There are no profiles referenced or defined for "client_secret_jwt" or "pri= vate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover th= ese types of flows. They only cover bearer flows. "client_secret_jwt" and = "private_key_jwt" seem to have some meaning within OpenID Connect, but I no= te that OIDC does not fully define these either. The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically. There is no authentication method defined for "client_bearer_saml" or "clie= nt_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration spec should accept these. I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to. A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined. That's possible, but they are in active use already. About "tos_uri" and "policy_uri" The distinction between tos_uri and policy_uri is unclear. Can we clarify = or combine them? Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for the= m to be split. Also, aren't these really URIs or are they meant to be URLs? There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at u= s, which is a plus. About "jwks_uri" A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-key-09 is needed. Yes, you're correct, I'll add that. Should be URL instead of URI? See above. :) Section 2.1 In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. It's there in the copy of -10 I'm reading off of ietf.org = right now =85 ? =93As such, a server supporting these fields SHOULD take steps to ensure th= at a client cannot register itself into an inconsistent state.=94 We may want to define more detailed HTTP error response. E.g. 400 status co= de + defined error code (=93invalid_client_metadata=94)? I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special. Section 2.2 May want to add: When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in =93clie= nt_name=94, instead of =93client_name#en=94) the OAuth server may use inter= pret the language used based on server configuration or heuristics. That seems inconsistent with what we already have: If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or scrip= t of the string value, and the string value MUST be used as-is wherever it = is presented in a user interface. Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. Section 3 Existing text: =93In order to support open registration and facilitate wider interoperabil= ity, the Client Registration Endpoint SHOULD allow initial registration req= uests with no authentication. These requests MAY be rate-limited or otherw= ise limited to prevent a denial-of-service attack on the Client Registratio= n Endpoint.=94 I would suggest to change the first =93SHOULD=94 to =93MAY=94. In most cl= oud services, the first client is registered by a human user. Then, other c= lients can be further used to automate other client registration. So, the = first request would typically come with an authenticated user identity. I think the weight of "SHOULD" is appropriate here, because I believe that = turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule. On the flip side, the earlier paragraph: =93The Client Registration Endpoint MAY accept an initial authorization cre= dential in the form of an OAuth 2.0 [RFC6749] access token in order to limi= t registration to only previously authorized parties. The method by which t= his access token is obtained by the registrant is generally out-of-band and= is out of scope of this specification.=94 I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= . That access token would carry a human user authenticated identity somehow. = In some cases, it can be a pure authenticated user assertion token. Again, disagree, for the same reasoning as above. About section 4.3: If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the Registration Access Token used to make this request SHOULD be immediately revoked. If the Client does not exist on this server, shouldn't it return a "404 Not= Found"? If revoking the registration access token, is it bound to a single client r= egistration? This is not clear. What is the lifecycle around registration= access token? Only hint is in the Client Information Response in section 5= .1. The language about the 401 here (and in other nearby sections) is specifica= lly so that you treat a missing client and a bad registration access token = the same way. You see, returning a 404 here actually indicates things were = in an inconsistent state. Namely, that the registration access token was st= ill valid but the client that the registration access token was attached to= doesn't exist anymore. The registration access token in meant to be tied t= o a client's instance (or registration), so it's actually more sensible to = act as though the registration access token isn't valid anymore. In at leas= t some implementations (specifically ours at MITRE that's built on SECOAUTH= in Java), you'd never be able to reach the 404 state due to consistency ch= ecking with the inbound token. Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at = the issuance of a new client_id with that instance. That token might be rev= oked and a new one issued on Read and Update requests to the Client Configu= ration Endpoint (and the client needs to be prepared for that -- same as th= e client_secret), and it will be revoked when the client is deleted either = with a Delete call to the Client Configuration Endpoint or something happen= ing out-of-band to kill the client. Should we add more explanatory text to the definition in the terminology se= ction? Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd like. About section 5.1: Is registration_access_token unique? Or is it shared by multiple instances= ? If shared, then registration_access_token can't be revoked on delete of= client. Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, Suggest to rename =93issued_at=94 to =93id_issued_at=94 While I do like the suggestion of changing these to client_secret_expires_a= t and client_id_issued_at, and I think these are more clear and readable, I= don't want to change the syntax during last call unless there is a clear n= eed and a clear consensus for doing so. Section 7 When a client_secret expires is it the intent that clients do an update or = refresh to get a new client secret? Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this. Again, thanks for the very thorough read through. Have you implemented any = of the spec yet, either as-is or with any of your suggested changes? -- Justin --_000_6AF52CCD4D6B469684653345FFFDBE9Cmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <89919BC5F4913F40B73B376E3D0E4FF5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Phil, many thanks for the extremely thorough review! It is very useful inde= ed. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is fo= r! My apologies for not getting many of these concerns to the WG much earli= er.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework= now that we are starting to consider how individual client applications sh= ould operate when there is one or more deployments of a particular resource= API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to = standards based, open source based, and commercial based deployments where = there are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of iss= ues that I would like to see made more clear in early part of the spec:

1.  How is a new client application recognized for the first time= when deployed against a particular SP endpoint?  Should clients actua= lly assert an application_id UUID that never changes and possibly a version= id that does change with versions?

In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a p= articular OpenID Connect provider, then you can define semantics for tying = together classes of clients (see below for more discussion on this very point). But in general, a client is just = going to show up as a new instance to the AS and get issued a new, unique c= lient_id, and that's that. 


2.  How are client credentials managed. Are we assuming client cr= edentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings= ), then I welcome suggestions and specific text as to how to make that clea= r. 

  How does a client authenticate the first time and subsequent ti= mes to the registration service?

This is a separate question all together, as it does not involve the c= lient_secret or client_id at all. Rather, the first time the client shows u= p to the registration service, it may either:
  - Not authenticate at all (this is the true public, open regist= ration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a beare= r token). How the client gets that bearer token and what the bearer token m= eans to the AS beyond "this client is authorized to register" is = out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean the= same instance of a client with a particular client_id) shows up at the reg= istration endpoint (actually, the Client Configuration Endpoint), it uses i= ts Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token t= hat is unique to the client instance.


3.  How is versioning of clients managed? Should each new version= of a client require a change in client registration including possibly cha= nging client_id and authentication credential? I don't have a strong feelin= g, but it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global policy= would ever fly here. Especially if you consider that the entire notion of = "version" is more fluid these days than it ever has been. I would= n't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both cl= ient developers and server developers institute reasonably good policy.

4.  What is the registration access token? Why is is used? What i= s its life-cycle?  When is it issued, when is it changed? When is it d= eleted?

See the response above above and the definition in =A71.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Aut= horization Server through the Client Registration Endpoint which is used by= the Client to authenticate itself during read, update, and delete operatio= ns. This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.


If we distinguish between first time registration of a particular clie= nt software package, it is possible that somethings like authentication met= hod can be negotiate in or out-of-band at that time. Subsequent registratio= ns should only have parameters for items that could change per deployment (like tos_uri).  I think token= _endpoint_auth_method is one thing that should not be negotiated per instan= ce.

When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiate= d or be different for the same client software? Should not all instances us= e the same authentication method.

I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change p= er instance. And instance, you should keep in mind, is defined as any one c= opy of the client code connecting to any new authorization server. That pairing creates the client_id, and t= herefore the instance, and therefore the registration access token, and the= refore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the A= S find out about it? And there's no way other than per-instance for the ser= ver to tell the client which token_endpoint_auth_method to use. All instanc= es will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And = each AS will tell each instance that registers with it to use a particular = auth method. There is no way to tie together different instances across (or= within) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth serve= rs. This is why, with Blue Button+, we specified a specific token forma= t for the initial access token that the clients use to call the registration endpoint the first time,  as= well as a discovery protocol against a centralized server that handles pre= -registration. All of this machinery is, in my opinion, a stupendous overki= ll for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abst= ract out and make its own spec that extends the Dyn Reg spec in a fully com= patible way. Furthermore, even in Blue Button+ we specify that all auth= servers MUST also accept open registration, without an initial access token, where the client simply shows up and says= "hey, here are my parameters." The auth server has no way to kno= w in this case any kind of out-of-band negotiation for different things. In= BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these di= fferent cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its own= . I believe it would be far too limiting.


Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg=  which uses ETags. Should this draft do so as well?

That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource = registration draft comes from) uses ETags, hence their inclusion there. I p= ersonally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this l= ate.


Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client= authentication.  Suggest renaming parameter to "token_endpoint_c= lient_auth_method"

This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes withou= t very, very compelling reasons to do so.


* Currently, the API only supports a single value instead of an array.=  If the purpose is to allow the client to know what auth methods it s= upports, this should be an array indicated what methods the client supports= - or it should not be used.

I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it w= as decided that a single value was simpler and sufficient for the purpose. = The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this= very issue in the WG here but didn't receive any traction on it, so single= it remains.

Also note that this field, like all others in =A72, represents two thi= ngs: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last= word anyway. But at least this dictator is nice enough to tell you what th= eir decision was instead of just decapitating you.


* There is no authn method for "client_secret_saml" or "= ;private_key_saml".

Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an absolute URI) would allow someone else to defi= ne these. Is the definition in the SAML Assertion draft sufficient for thei= r use?


There are no profiles referenced or defined for "client_secret= _jwt" or "private_key_jwt". Neither of the JWT or SAML Beare= r drafts referenced cover these types of flows. They only cover bearer flow= s.  "client_secret_jwt" and "private_key_jwt" seem= to have some meaning within OpenID Connect, but I note that OIDC does not ful= ly define these either.

The JWT assertion draft does say how to use a JWT for client authentic= ation, and the DynReg text differentiates between a client signing said JWT= with its own secret symmetrically vs. a client using its own private key, = asymmetrically.


There is no authentication method defined for "client_bearer_saml= " or "client_bearer_jwt" or "client_bearer_ref". &= nbsp;Since the bearer specs say this is acceptable,  the dynamic regis= tration spec should accept these.

I don't understand this bit -- where are these defined in RFC6750? I d= on't even know what client_bearer_ref would refer to.


A possible suggestion is to remove client_secret_jwt and private_key_j= wt and define those as register extensions since these profiles are not def= ined.

That's possible, but they are in active use already. 



About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can w= e clarify or combine them?

Terms of service and policy are two different documents. One is someth= ing that a user accepts (generally describing what the user will do), one i= s a statement of what the service provider (in this case, the client) will = do. More importantly, we used to have only one, and several people asked for them to be split.
 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is appar= ently trying to deprecate URL in favor of URI in new specs. So in practice = they'll nearly always be URLs, but since all URLs are URIs we're not techni= cally incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.


About "jwks_uri"

A normative reference for http://tools.ie= tf.org/html/draft-ietf-jose-json-web-key-09 is needed. 

Yes, you're correct, I'll add that.

=  
Should be URL instead of URI?

See above. :)


Section 2.1

In the table urn:ietf:params:oauth:gr= ant-type:jwt-bearer is missing.

It's there in the copy of -10 I'm reading off of ietf.org right now =85 ?


=93As such, a server supporting these fields SHOULD take steps to= ensure that a client cannot register itself into an inconsistent state.=94=

We may want to define more detailed HTTP error response. E.g. 400 stat= us code + defined error code (=93invalid_client_metadata=94)?

I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce grant-type= and response-type restrictions, but servers that can't or don't care about= restricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When =93#= =94 language tag is missing, (e.g. =93#en=94 is missing in =93client_name= =94, instead of =93client_name#en=94) the OAuth server may use interpr= et the language used based on server configuration or heuristics.=

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make any assumptions about the language, character set, or = script of the string value, and the string value MUST be used as-is whereve= r it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try to = get fancy.


Section 3

Existing text:

=93In order to supp= ort open registration and facilitate wider interoperability, the Clien= t Registration Endpoint SHOULD allow initial registration re= quests with no authentication.  These requests MAY be r= ate-limited or otherwise limited to prevent a denial-of-service attack on the Cli= ent Registration Endpoint.=94

I would suggest to change the first =93SHOULD=94 to =93MAY=94.   = In most cloud services, the first client is registered by a human user= . Then, other clients can be further used to automate other clien= t registration.  So, the first request would typically come = with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because = I believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the rule.&nb= sp;


On the flip side, the earlier paragraph:

=93The Client Regis= tration Endpoint MAY accept an initial authorization credential i= n the form of an OAuth 2.0 [RFC6749] access token in order to lim= it registration to only previously authorized parties. The method by which this access token is obtained by the registrant is ge= nerally out-of-band and is out of scope of this specification.=94

I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= .

That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion toke= n.

Again, disagree, for the same reasoning as above.


About section 4.3:

If the client does not exist on this server, the server =
MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return = a "404 Not Found"?

If revoking the registration access token, is it bound to a single client r= egistration?  This is not clear.  What is the lifecycle around re= gistration access token? Only hint is in the Client Information Response in= section 5.1.

The language about the 401 here (and in other nearby sections) is spec= ifically so that you treat a missing client and a bad registration access t= oken the same way. You see, returning a 404 here actually indicates th= ings were in an inconsistent state. Namely, that the registration access token was still valid but the client that the= registration access token was attached to doesn't exist anymore. The regis= tration access token in meant to be tied to a client's instance (or registr= ation), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at = least some implementations (specifically ours at MITRE that's built on SECO= AUTH in Java), you'd never be able to reach the 404 state due to consistenc= y checking with the inbound token.

Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begin= s at the issuance of a new client_id with that instance. That token might b= e revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the cli= ent needs to be prepared for that -- same as the client_secret), and it wil= l be revoked when the client is deleted either with a Delete call to the Cl= ient Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sin= ce I don't think it's as clear as we'd like.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple= instances?   If shared, then registration_access_token can't be revok= ed on delete of client.

Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, 
Suggest to rename =93issued_at=94 to =93id_issued_at=94

While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readab= le, I don't want to change the syntax during last call unless there is a cl= ear need and a clear consensus for doing so.


Section 7

When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed ab= ove, I'm not sure that's as clear as it needs to be, and I welcome suggesti= ons on how to clarify this.



Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either as-is or with any of your suggested changes?

 -- Justin
--_000_6AF52CCD4D6B469684653345FFFDBE9Cmitreorg_-- From jricher@mitre.org Wed May 15 18:03:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAA21F85EE for ; Wed, 15 May 2013 18:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htLdCRTglBxf for ; Wed, 15 May 2013 18:03:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3211E80D7 for ; Wed, 15 May 2013 18:02:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FF9B1F0891; Wed, 15 May 2013 21:02:59 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2F3F51F08A3; Wed, 15 May 2013 21:02:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Wed, 15 May 2013 21:02:59 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award Thread-Index: Ac5RkRHsmjk4DQHIScSJKb59Lo5YdQAK0L0AAA2GIgA= Date: Thu, 16 May 2013 01:02:58 +0000 Message-ID: <5314046D-26D4-49F1-BB76-28C237EB9C8E@mitre.org> References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> <5193D528.4030901@gmx.net> In-Reply-To: <5193D528.4030901@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.156] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 01:03:10 -0000 Hooray! Congratulations to the whole working group! -- Justin On May 15, 2013, at 2:34 PM, Hannes Tschofenig = wrote: > That's great to hear. >=20 > Hope you have taken some pictures from the awards ceremony. >=20 > On 05/15/2013 08:24 PM, Mike Jones wrote: >> I=92m pleased to report that OAuth 2.0 has won the 2013 European Identit= y >> Award for Best Innovation/New Standard. I was honored to accept the >> award from Kuppinger Cole at the 2013 European Identity and Cloud >> Conference on behalf of all who >> contributed to creating the OAuth 2.0 standards [RFC 6749 >> , RFC 6750 >> ] and building solutions with them. >>=20 >> (I also posted this announcement at http://self-issued.info/?p=3D1026.) >>=20 >> -- Mike >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed May 15 18:17:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5611711E80D7 for ; Wed, 15 May 2013 18:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHQiz8rNgK+a for ; Wed, 15 May 2013 18:17:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53711E80E9 for ; Wed, 15 May 2013 18:17:26 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4G1HNvj005195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 01:17:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4G1HNeP020400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2013 01:17:24 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4G1HNsq027923; Thu, 16 May 2013 01:17:23 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 May 2013 18:17:22 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-4F579264-EB8D-494B-A911-846D1B434983 Content-Transfer-Encoding: 7bit Message-Id: <8E963F09-3631-4254-9C06-69E39461D094@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 15 May 2013 18:17:18 -0700 To: "Richer, Justin P." X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 01:17:32 -0000 --Apple-Mail-4F579264-EB8D-494B-A911-846D1B434983 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Justin, I will look over your comments. But looking at some, i was not looking for a= n explanation but rather I think the text should explain. =20 For example the registration access token seemed very mysterious. It took a l= ot of effort to understand what was going on.=20 Maybe i am seeing this as I am looking at the spec with fresh eyes? Phil On 2013-05-15, at 17:53, "Richer, Justin P." wrote: > Phil, many thanks for the extremely thorough review! It is very useful ind= eed.=20 >=20 > My comments and responses to each point are inline. =20 >=20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: >=20 >> It seems unfortunate that I have not gotten a chance to get into this lev= el of detail much earlier. But then, I guess that's what LC review is for! M= y apologies for not getting many of these concerns to the WG much earlier. >>=20 >> Overall =20 >> ----------- >> I think dynamic registration is a critical part of the OAuth framework no= w that we are starting to consider how individual client applications should= operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Facebook= or Flickr and moved on to standards based, open source based, and commercia= l based deployments where there are multiple service endpoints and many clie= nts to manage. >>=20 >> The dynamic registration spec is actually dealing with a couple of issues= that I would like to see made more clear in early part of the spec: >>=20 >> 1. How is a new client application recognized for the first time when de= ployed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does ch= ange with versions? >=20 > In the general case, why is any recognition required? If you're doing thin= gs as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together c= lasses of clients (see below for more discussion on this very point). But in= general, a client is just going to show up as a new instance to the AS and g= et issued a new, unique client_id, and that's that.=20 >=20 >>=20 >> 2. How are client credentials managed. Are we assuming client credential= s have a limited lifetime or rotation policy? >=20 > The intent was that client_secret could be rotated, as indicated by the ex= pires_at member of the response. If a client's secret expires, it calls the r= ead operation on the Client Configuration Endpoint (=C2=A74.2) to get its ne= w client_secret. If this is unclear in the current text (which I suspect it m= ay be after multiple refactorings), then I welcome suggestions and specific t= ext as to how to make that clear.=20 >=20 >> How does a client authenticate the first time and subsequent times to t= he registration service? >=20 > This is a separate question all together, as it does not involve the clien= t_secret or client_id at all. Rather, the first time the client shows up to t= he registration service, it may either: > - Not authenticate at all (this is the true public, open registration, a= nd it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer token).= How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the s= pec, by design. >=20 > Subsequent times that the same registered client (by which we mean the sam= e instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Reg= istration Access Token that it was issued on initial registration. This is a= n OAuth 2.0 Bearer token that is unique to the client instance. >=20 >>=20 >> 3. How is versioning of clients managed? Should each new version of a cl= ient require a change in client registration including possibly changing cli= ent_id and authentication credential? I don't have a strong feeling, but it i= s something that implementors should consider. >=20 > This is up to the AS, really, and I don't think that any global policy wou= ld ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding a= discussion in the security considerations if it merits mentioning though, s= o that we can help both client developers and server developers institute re= asonably good policy. >=20 >>=20 >> 4. What is the registration access token? Why is is used? What is its li= fe-cycle? When is it issued, when is it changed? When is it deleted? >=20 > See the response above above and the definition in =C2=A71.2:=20 >=20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authori= zation Server through the Client Registration Endpoint which is used by the C= lient to authenticate itself during read, update, and delete operations. Thi= s token is associated with a particular Client. >=20 > If this can be clarified, I welcome text suggestions. >=20 >>=20 >> If we distinguish between first time registration of a particular client s= oftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sho= uld only have parameters for items that could change per deployment (like to= s_uri). I think token_endpoint_auth_method is one thing that should not be n= egotiated per instance. >=20 >> When subsequent instances register, I have to ask the question, for examp= le when would things like "token_endpoint_auth_method" be negotiated or be d= ifferent for the same client software? Should not all instances use the same= authentication method. >=20 >=20 > I'm confused by this -- as far as the dynamic registration spec is concern= ed, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy of= the client code connecting to any new authorization server. That pairing c= reates the client_id, and therefore the instance, and therefore the registra= tion access token, and therefore the registration itself at a conceptual lev= el. So there is no way other than per-instance for a client to ask for a par= ticular token_endpoint_auth_method. Where else would the AS find out about i= t? And there's no way other than per-instance for the server to tell the cli= ent which token_endpoint_auth_method to use. All instances will probably ask= for the same token_endpoint_auth_method from all auth servers they talk to,= right? And each AS will tell each instance that registers with it to use a p= articular auth method. There is no way to tie together different instances a= cross (or within) auth servers without specifying a significant amount of ot= her machinery. >=20 > Which is not to say that it's not useful in some circumstances to tie toge= ther different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the i= nitial access token that the clients use to call the registration endpoint t= he first time, as well as a discovery protocol against a centralized server= that handles pre-registration. All of this machinery is, in my opinion, a s= tupendous overkill for the general case, though if some folks find use for i= t outside of BB+ then it'd be a good thing to abstract out and make its own s= pec that extends the Dyn Reg spec in a fully compatible way. Furthermore, ev= en in Blue Button+ we specify that all auth servers MUST also accept open re= gistration, without an initial access token, where the client simply shows u= p and says "hey, here are my parameters." The auth server has no way to know= in this case any kind of out-of-band negotiation for different things. In B= B+ we are writing very specific policy guidelines about how to present the U= X and things to the end user for all of these different cases. But again, al= l of this is specific to the BB+ use case, and I don't see value in dragging= it in to the registration spec on its own. I believe it would be far too li= miting. >=20 >>=20 >> Finally, there seems to be an inconsistent style approach with draft-hard= jono-oauth-resource-reg which uses ETags. Should this draft do so as well? >=20 > That's an individual submission, not a working group draft. Nobody has, un= til now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I persona= lly don't see their utility here, though, and I wouldn't want to include a w= holly new mechanism this late. >=20 >>=20 >> Specific items: >> --------------------- >> "token_endpoint_auth_method" >>=20 >> There is some confusion as to whether this applies to server or client au= thentication. Suggest renaming parameter to "token_endpoint_client_auth_met= hod" >=20 > This is the first I've heard of this particular confusion. I'm fine with e= ither name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. >=20 >>=20 >> * Currently, the API only supports a single value instead of an array. I= f the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it sh= ould not be used. >=20 > I would rather like this to be an array, personally, and brought it up wit= h the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The IE= TF draft has inherited this decision. I *believe* (though am not 100% positi= ve) that I brought up this very issue in the WG here but didn't receive any t= raction on it, so single it remains. >=20 > Also note that this field, like all others in =C2=A72, represents two thin= gs: the client telling the server "I want to use this value for this field",= and the server telling the client "this is the value you have for this fiel= d". It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator is= nice enough to tell you what their decision was instead of just decapitatin= g you. >=20 >>=20 >> * There is no authn method for "client_secret_saml" or "private_key_saml"= . >=20 > Nobody has really asked that these two be included or specified. The exten= sion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use?= >=20 >>=20 >> There are no profiles referenced or defined for "client_secret_jwt" or "p= rivate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover t= hese types of flows. They only cover bearer flows. "client_secret_jwt" and "= private_key_jwt" seem to have some meaning within OpenID Connect, but I note= that OIDC does not fully define these either. >=20 > The JWT assertion draft does say how to use a JWT for client authenticatio= n, and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymme= trically. >=20 >>=20 >> There is no authentication method defined for "client_bearer_saml" or "cl= ient_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is= acceptable, the dynamic registration spec should accept these. >=20 > I don't understand this bit -- where are these defined in RFC6750? I don't= even know what client_bearer_ref would refer to. >=20 >>=20 >> A possible suggestion is to remove client_secret_jwt and private_key_jwt a= nd define those as register extensions since these profiles are not defined.= >=20 > That's possible, but they are in active use already.=20 >=20 >>=20 >>=20 >> About "tos_uri" and "policy_uri" >>=20 >> The distinction between tos_uri and policy_uri is unclear. Can we clarif= y or combine them? >=20 > Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a st= atement of what the service provider (in this case, the client) will do. Mor= e importantly, we used to have only one, and several people asked for them t= o be split. > =20 >>=20 >> Also, aren't these really URIs or are they meant to be URLs? >=20 > There was already discussion about this on the list: The IETF is apparentl= y trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically i= ncorrect in following the new policy. And it makes the IESG less mad at us, w= hich is a plus. >=20 >>=20 >> About "jwks_uri" >>=20 >> A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json= -web-key-09 is needed.=20 >=20 > Yes, you're correct, I'll add that. >=20 >> =20 >> Should be URL instead of URI? >=20 > See above. :) >=20 >>=20 >> Section 2.1 >>=20 >> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >> is missing. >=20 > It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80= =A6 ? >=20 >>=20 >> =E2=80=9CAs such, a server supporting these fields SHOULD take steps to e= nsure that a client cannot register itself into an inconsistent state.=E2=80= =9D >>=20 >> We may want to define more detailed HTTP error response. E.g. 400 status c= ode + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)? >=20 > I'd be fine with defining a more explicit error state in this case. I thin= k it would help interop for the servers that want to enforce grant-type and r= esponse-type restrictions, but servers that can't or don't care about restri= cting grants types and whatnot don't have to do anything special. >=20 >>=20 >> Section 2.2 >>=20 >> May want to add: >>=20 >> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_= name#en=E2=80=9D) the OAuth server may use interpret the language used based= on server configuration or heuristics. >=20 > That seems inconsistent with what we already have: >=20 > If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or script= of the string value, and the string value MUST be used as-is wherever it is= presented in a user interface. >=20 > Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. >=20 >>=20 >> Section 3 >>=20 >> Existing text: >>=20 >> =E2=80=9CIn order to support open registration and facilitate wider inter= operability, the Client Registration Endpoint SHOULD allow initial registrat= ion requests with no authentication. These requests MAY be rate-limited or o= therwise limited to prevent a denial-of-service attack on the Client Registr= ation Endpoint.=E2=80=9D >>=20 >> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80=9C= MAY=E2=80=9D. In most cloud services, the first client is registered by a h= uman user. Then, other clients can be further used to automate other client r= egistration. So, the first request would typically come with an authenticat= ed user identity.=20 >=20 > I think the weight of "SHOULD" is appropriate here, because I believe that= turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule.=20 >=20 >>=20 >> On the flip side, the earlier paragraph: >>=20 >> =E2=80=9CThe Client Registration Endpoint MAY accept an initial authoriza= tion credential in the form of an OAuth 2.0 [RFC6749] access token in order t= o limit registration to only previously authorized parties. The method by wh= ich this access token is obtained by the registrant is generally out-of-band= and is out of scope of this specification.=E2=80=9D >>=20 >> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D t= o =E2=80=9CSHOULD=E2=80=9D. >>=20 >> That access token would carry a human user authenticated identity somehow= . In some cases, it can be a pure authenticated user assertion token. >=20 > Again, disagree, for the same reasoning as above. >=20 >>=20 >> About section 4.3: >>=20 >> If the client does not exist on this server, the server MUST respond >> with HTTP 401 Unauthorized, and the Registration Access Token used to >> make this request SHOULD be immediately revoked. >>=20 >> If the Client does not exist on this server, shouldn't it return a "404 N= ot Found"? >>=20 >> If revoking the registration access token, is it bound to a single client= registration? This is not clear. What is the lifecycle around registratio= n access token? Only hint is in the Client Information Response in section 5= .1. >=20 > The language about the 401 here (and in other nearby sections) is specific= ally so that you treat a missing client and a bad registration access token t= he same way. You see, returning a 404 here actually indicates things were in= an inconsistent state. Namely, that the registration access token was still= valid but the client that the registration access token was attached to doe= sn't exist anymore. The registration access token in meant to be tied to a c= lient's instance (or registration), so it's actually more sensible to act as= though the registration access token isn't valid anymore. In at least some i= mplementations (specifically ours at MITRE that's built on SECOAUTH in Java)= , you'd never be able to reach the 404 state due to consistency checking wit= h the inbound token. >=20 > Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at t= he issuance of a new client_id with that instance. That token might be revok= ed and a new one issued on Read and Update requests to the Client Configurat= ion Endpoint (and the client needs to be prepared for that -- same as the cl= ient_secret), and it will be revoked when the client is deleted either with a= Delete call to the Client Configuration Endpoint or something happening out= -of-band to kill the client.=20 >=20 > Should we add more explanatory text to the definition in the terminology s= ection? Elsewhere? I'm very open to concrete suggestions with this, since I d= on't think it's as clear as we'd like. >=20 >> =20 >> About section 5.1: >>=20 >> Is registration_access_token unique? Or is it shared by multiple instanc= es? If shared, then registration_access_token can't be revoked on delete o= f client. >>=20 >> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_exp= ires_at=E2=80=9D,=20 >>=20 >> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D >=20 > While I do like the suggestion of changing these to client_secret_expires_= at and client_id_issued_at, and I think these are more clear and readable, I= don't want to change the syntax during last call unless there is a clear ne= ed and a clear consensus for doing so. >=20 >>=20 >> Section 7 >>=20 >> When a client_secret expires is it the intent that clients do an update o= r refresh to get a new client secret? >=20 > Yes, the client is supposed to either call the read or update methods on t= he client configuration endpoint to get its new secret. As discussed above, I= 'm not sure that's as clear as it needs to be, and I welcome suggestions on h= ow to clarify this. >=20 >=20 >=20 > Again, thanks for the very thorough read through. Have you implemented any= of the spec yet, either as-is or with any of your suggested changes? >=20 > -- Justin --Apple-Mail-4F579264-EB8D-494B-A911-846D1B434983 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Justin,

I wil= l look over your comments. But looking at some, i was not looking for an exp= lanation but rather I think the text should explain.  

For example the registration access token seemed very mysterious. I= t took a lot of effort to understand what was going on. 

=
Maybe i am seeing this as I am looking at the spec with fresh eye= s?

Phil

On 2013-05-15, at 17:53, "Richer, Justin= P." <jricher@mitre.org> wrot= e:

Phil, many thanks for the extremely thorough review! It is very useful indee= d. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

It seems unfortunate that I have not gotten a chance to get into this l= evel of detail much earlier. But then, I guess that's what LC review is for!= My apologies for not getting many of these concerns to the WG much earlier.=

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework n= ow that we are starting to consider how individual client applications shoul= d operate when there is one or more deployments of a particular resource API= . We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to s= tandards based, open source based, and commercial based deployments where th= ere are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of issu= es that I would like to see made more clear in early part of the spec:
=

1.  How is a new client application recognized for the first time w= hen deployed against a particular SP endpoint?  Should clients actually= assert an application_id UUID that never changes and possibly a version id t= hat does change with versions?

In the general case, why is any recognition required? If you're doing t= hings as part of a larger protocol ecosystem, like Blue Button+ or a particu= lar OpenID Connect provider, then you can define semantics for tying togethe= r classes of clients (see below for more discussion on this very point). But in general, a client is just g= oing to show up as a new instance to the AS and get issued a new, unique cli= ent_id, and that's that. 


2.  How are client credentials managed. Are we assuming client cre= dentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the expi= res_at member of the response. If a client's secret expires, it calls the re= ad operation on the Client Configuration Endpoint (=C2=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings)= , then I welcome suggestions and specific text as to how to make that clear.=  

  How does a client authenticate the first time and subsequent tim= es to the registration service?

This is a separate question all together, as it does not involve the cl= ient_secret or client_id at all. Rather, the first time the client shows up t= o the registration service, it may either:
  - Not authenticate at all (this is the true public, open registr= ation, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer= token). How the client gets that bearer token and what the bearer token mea= ns to the AS beyond "this client is authorized to register" is out of scope f= or the spec, by design.

Subsequent times that the same registered client (by which we mean the s= ame instance of a client with a particular client_id) shows up at the regist= ration endpoint (actually, the Client Configuration Endpoint), it uses its R= egistration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token th= at is unique to the client instance.


3.  How is versioning of clients managed? Should each new version o= f a client require a change in client registration including possibly changi= ng client_id and authentication credential? I don't have a strong feeling, b= ut it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global policy w= ould ever fly here. Especially if you consider that the entire notion of "ve= rsion" is more fluid these days than it ever has been. I wouldn't mind addin= g a discussion in the security considerations if it merits mentioning though, so that we can help both cli= ent developers and server developers institute reasonably good policy.
=

4.  What is the registration access token? Why is is used? What is= its life-cycle?  When is it issued, when is it changed? When is it del= eted?

See the response above above and the definition in =C2=A71.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Auth= orization Server through the Client Registration Endpoint which is used by t= he Client to authenticate itself during read, update, and delete operations.= This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.


If we distinguish between first time registration of a particular clien= t software package, it is possible that somethings like authentication metho= d can be negotiate in or out-of-band at that time. Subsequent registrations s= hould only have parameters for items that could change per deployment (like tos_uri).  I think token_= endpoint_auth_method is one thing that should not be negotiated per instance= .

When subsequent instances register, I have to ask the question, for example w= hen would things like "token_endpoint_auth_method" be negotiated or be diffe= rent for the same client software? Should not all instances use the same aut= hentication method.

I'm confused by this -- as far as the dynamic registration spec is conc= erned, all instances are separate from each other. All parameters change per= instance. And instance, you should keep in mind, is defined as any one copy= of the client code connecting to any new authorization server. That pairing creates the client_id, and th= erefore the instance, and therefore the registration access token, and there= fore the registration itself at a conceptual level. So there is no way other= than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS= find out about it? And there's no way other than per-instance for the serve= r to tell the client which token_endpoint_auth_method to use. All instances w= ill probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And e= ach AS will tell each instance that registers with it to use a particular au= th method. There is no way to tie together different instances across (or wi= thin) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to tie t= ogether different instances of the same code across (or within) auth servers= . This is why, with Blue Button+, we specified a specific token format for t= he initial access token that the clients use to call the registration endpoint the first time,  as w= ell as a discovery protocol against a centralized server that handles pre-re= gistration. All of this machinery is, in my opinion, a stupendous overkill f= or the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract o= ut and make its own spec that extends the Dyn Reg spec in a fully compatible= way. Furthermore, even in Blue Button+ we specify that all auth servers MUS= T also accept open registration, without an initial access token, where the client simply shows up and says "= hey, here are my parameters." The auth server has no way to know in this cas= e any kind of out-of-band negotiation for different things. In BB+ we are wr= iting very specific policy guidelines about how to present the UX and things to the end user for all of these dif= ferent cases. But again, all of this is specific to the BB+ use case, and I d= on't see value in dragging it in to the registration spec on its own. I beli= eve it would be far too limiting.


Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg w= hich uses ETags. Should this draft do so as well?

That's an individual submission, not a working group draft. Nobody has,= until now, even mentioned the use of ETags here. UMA (where the resource re= gistration draft comes from) uses ETags, hence their inclusion there. I pers= onally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this la= te.


Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client a= uthentication.  Suggest renaming parameter to "token_endpoint_client_au= th_method"

This is the first I've heard of this particular confusion. I'm fine wit= h either name but at this stage I don't want to make syntax changes without v= ery, very compelling reasons to do so.


* Currently, the API only supports a single value instead of an array. &= nbsp;If the purpose is to allow the client to know what auth methods it supp= orts, this should be an array indicated what methods the client supports - o= r it should not be used.

I would rather like this to be an array, personally, and brought it up w= ith the OpenID Connect working group about six months ago. But there it was d= ecided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this v= ery issue in the WG here but didn't receive any traction on it, so single it= remains.

Also note that this field, like all others in =C2=A72, represents two t= hings: the client telling the server "I want to use this value for this fiel= d", and the server telling the client "this is the value you have for this f= ield". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last w= ord anyway. But at least this dictator is nice enough to tell you what their= decision was instead of just decapitating you.


* There is no authn method for "client_secret_saml" or "private_key_sam= l".

Nobody has really asked that these two be included or specified. The ex= tension mechanism (using an absolute URI) would allow someone else to define= these. Is the definition in the SAML Assertion draft sufficient for their u= se?


There are no profiles referenced or defined for "client_secret_jwt" o= r "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cov= er these types of flows. They only cover bearer flows.  "client_secret_= jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not full= y define these either.

The JWT assertion draft does say how to use a JWT for client authentica= tion, and the DynReg text differentiates between a client signing said JWT w= ith its own secret symmetrically vs. a client using its own private key, asy= mmetrically.


There is no authentication method defined for "client_bearer_saml" or "= client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say t= his is acceptable,  the dynamic registration spec should accept these.<= /div>

I don't understand this bit -- where are these defined in RFC6750? I do= n't even know what client_bearer_ref would refer to.


A possible suggestion is to remove client_secret_jwt and private_key_jw= t and define those as register extensions since these profiles are not defin= ed.

That's possible, but they are in active use already. 



About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can we= clarify or combine them?

Terms of service and policy are two different documents. One is somethi= ng that a user accepts (generally describing what the user will do), one is a= statement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for them to be split.
 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is appare= ntly trying to deprecate URL in favor of URI in new specs. So in practice th= ey'll nearly always be URLs, but since all URLs are URIs we're not technical= ly incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.


About "jwks_uri"

A normative reference for http://tools.ietf.or= g/html/draft-ietf-jose-json-web-key-09&= nbsp;is needed. 

Yes, you're correct, I'll add that.

&= nbsp;
Should be URL instead of URI?

See above. :)


Section 2.1

In the table urn:ietf:params:oauth:gran= t-type:jwt-bearer is missing.

It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80=A6 ?


=E2=80=9CAs such, a server supporting these fields SHOULD take steps&nb= sp;to ensure that a client cannot register itself into an inconsistent state= .=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 statu= s code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?
=

I'd be fine with defining a more explicit error state in this case. I t= hink it would help interop for the servers that want to enforce grant-type a= nd response-type restrictions, but servers that can't or don't care about re= stricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When =E2=80= =9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80=9D is missin= g in =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_name#en=E2= =80=9D) the OAuth server may use interpret the language used based = ;on server configuration or heuristics.

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties usi= ng it MUST NOT make any assumptions about the language, character set, or sc= ript of the string value, and the string value MUST be used as-is wherever i= t is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try to g= et fancy.


Section 3

Existing text:

=E2=80=9CIn order to= support open registration and facilitate wider interoperability, the C= lient Registration Endpoint SHOULD allow initial registration = ;requests with no authentication.  These requests MAY be = ;rate-limited or otherwise limited to prevent a denial-of-service attack on the Clie= nt Registration Endpoint.=E2=80=9D

I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY= =E2=80=9D.   In most cloud services, the first client is regi= stered by a human user. Then, other clients can be further used to auto= mate other client registration.  So, the first request w= ould typically come with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because I believe t= hat turning off open registration at the AS (which is what this is talking a= bout) really ought to be the exception rather than the rule. 


On the flip side, the earlier paragraph:

=E2=80=9CThe Client R= egistration Endpoint MAY accept an initial authorization credentia= l in the form of an OAuth 2.0 [RFC6749] access token in order to l= imit registration to only previously authorized parties. The method by which this access token is obtained by the registrant is gen= erally out-of-band and is out of scope of this specification.=E2=80=9D

I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D to =E2= =80=9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity someh= ow. In some cases, it can be a pure authenticated user assertion token.=

Again, disagree, for the same reasoning as above.


About section 4.3:

If the client does not exist on this server, the server MUST r=
espond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return a= "404 Not Found"?

If revoking the registration access token, is it bound to a single client re= gistration?  This is not clear.  What is the lifecycle around regi= stration access token? Only hint is in the Client Information Response in se= ction 5.1.

The language about the 401 here (and in other nearby sections) is speci= fically so that you treat a missing client and a bad registration access tok= en the same way. You see, returning a 404 here actually indicates thing= s were in an inconsistent state. Namely, that the registration access token was still valid but the client that the r= egistration access token was attached to doesn't exist anymore. The registra= tion access token in meant to be tied to a client's instance (or registratio= n), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at l= east some implementations (specifically ours at MITRE that's built on SECOAU= TH in Java), you'd never be able to reach the 404 state due to consistency c= hecking with the inbound token.

Since the intent of the registration access token is that it's bound to= a single instance, its lifecycle is generally tied to the lifecycle begins a= t the issuance of a new client_id with that instance. That token might be re= voked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the clie= nt needs to be prepared for that -- same as the client_secret), and it will b= e revoked when the client is deleted either with a Delete call to the Client= Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the terminolog= y section? Elsewhere? I'm very open to concrete suggestions with this, since= I don't think it's as clear as we'd like.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple i= nstances?   If shared, then registration_access_token can't be revoked o= n delete of client.

Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_expire= s_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2=80= =9D

While I do like the suggestion of changing these to client_secret_expir= es_at and client_id_issued_at, and I think these are more clear and readable= , I don't want to change the syntax during last call unless there is a clear= need and a clear consensus for doing so.


Section 7

When a client_secret expires is it the intent that clients do an update= or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update methods o= n the client configuration endpoint to get its new secret. As discussed abov= e, I'm not sure that's as clear as it needs to be, and I welcome suggestions= on how to clarify this.



Again, thanks for the very thorough read through. Have you implemented a= ny of the spec yet, either as-is or with any of your suggested changes?

 -- Justin
= --Apple-Mail-4F579264-EB8D-494B-A911-846D1B434983-- From jricher@mitre.org Wed May 15 18:49:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34AA11E80E6 for ; Wed, 15 May 2013 18:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKTTs-3S84Ab for ; Wed, 15 May 2013 18:49:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E57F11E80EA for ; Wed, 15 May 2013 18:49:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 23A051F0A2E; Wed, 15 May 2013 21:49:34 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0D5711F0A22; Wed, 15 May 2013 21:49:34 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Wed, 15 May 2013 21:49:33 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUasmqYhOH+9Tj0KmdipKXhmNOJkHP2iAgAAGhgCAAAkDgA== Date: Thu, 16 May 2013 01:49:33 +0000 Message-ID: <1413870B-D56F-40CF-8C51-8E610355C2DD@mitre.org> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8E963F09-3631-4254-9C06-69E39461D094@oracle.com> In-Reply-To: <8E963F09-3631-4254-9C06-69E39461D094@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.156] Content-Type: multipart/alternative; boundary="_000_1413870BD56F40CF8C518E610355C2DDmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 01:49:40 -0000 --_000_1413870BD56F40CF8C518E610355C2DDmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think that's exactly the case, which is why it's such valuable feedback. = It's obvious to me, as the editor, what all the parts do. What I was hoping= to do with the explanations below was ferret out what key bit of informati= on was missing from which part of the spec, so that we can make things more= explicit and clear where needed. Looking forward to your responses, -- Justin On May 15, 2013, at 9:17 PM, Phil Hunt > wrote: Justin, I will look over your comments. But looking at some, i was not looking for = an explanation but rather I think the text should explain. For example the registration access token seemed very mysterious. It took a= lot of effort to understand what was going on. Maybe i am seeing this as I am looking at the spec with fresh eyes? Phil On 2013-05-15, at 17:53, "Richer, Justin P." > wrote: Phil, many thanks for the extremely thorough review! It is very useful inde= ed. My comments and responses to each point are inline. On May 15, 2013, at 4:30 PM, Phil Hunt > wrote: It seems unfortunate that I have not gotten a chance to get into this level= of detail much earlier. But then, I guess that's what LC review is for! My= apologies for not getting many of these concerns to the WG much earlier. Overall ----------- I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Faceboo= k or Flickr and moved on to standards based, open source based, and commerc= ial based deployments where there are multiple service endpoints and many c= lients to manage. The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec: 1. How is a new client application recognized for the first time when depl= oyed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does c= hange with versions? In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together = classes of clients (see below for more discussion on this very point). But = in general, a client is just going to show up as a new instance to the AS a= nd get issued a new, unique client_id, and that's that. 2. How are client credentials managed. Are we assuming client credentials = have a limited lifetime or rotation policy? The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it = may be after multiple refactorings), then I welcome suggestions and specifi= c text as to how to make that clear. How does a client authenticate the first time and subsequent times to the= registration service? This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either: - Not authenticate at all (this is the true public, open registration, an= d it is recommended that servers do this) - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the= spec, by design. Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is= an OAuth 2.0 Bearer token that is unique to the client instance. 3. How is versioning of clients managed? Should each new version of a clie= nt require a change in client registration including possibly changing clie= nt_id and authentication credential? I don't have a strong feeling, but it = is something that implementors should consider. This is up to the AS, really, and I don't think that any global policy woul= d ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding= a discussion in the security considerations if it merits mentioning though= , so that we can help both client developers and server developers institut= e reasonably good policy. 4. What is the registration access token? Why is is used? What is its life= -cycle? When is it issued, when is it changed? When is it deleted? See the response above above and the definition in =A71.2: Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client. If this can be clarified, I welcome text suggestions. If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like = tos_uri). I think token_endpoint_auth_method is one thing that should not = be negotiated per instance. When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiated or be di= fferent for the same client software? Should not all instances use the same= authentication method. I'm confused by this -- as far as the dynamic registration spec is concerne= d, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy o= f the client code connecting to any new authorization server. That pairing = creates the client_id, and therefore the instance, and therefore the regist= ration access token, and therefore the registration itself at a conceptual = level. So there is no way other than per-instance for a client to ask for a= particular token_endpoint_auth_method. Where else would the AS find out ab= out it? And there's no way other than per-instance for the server to tell t= he client which token_endpoint_auth_method to use. All instances will proba= bly ask for the same token_endpoint_auth_method from all auth servers they = talk to, right? And each AS will tell each instance that registers with it = to use a particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a significant = amount of other machinery. Which is not to say that it's not useful in some circumstances to tie toget= her different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the= initial access token that the clients use to call the registration endpoin= t the first time, as well as a discovery protocol against a centralized se= rver that handles pre-registration. All of this machinery is, in my opinion= , a stupendous overkill for the general case, though if some folks find use= for it outside of BB+ then it'd be a good thing to abstract out and make i= ts own spec that extends the Dyn Reg spec in a fully compatible way. Furthe= rmore, even in Blue Button+ we specify that all auth servers MUST also acce= pt open registration, without an initial access token, where the client sim= ply shows up and says "hey, here are my parameters." The auth server has no= way to know in this case any kind of out-of-band negotiation for different= things. In BB+ we are writing very specific policy guidelines about how to= present the UX and things to the end user for all of these different cases= . But again, all of this is specific to the BB+ use case, and I don't see v= alue in dragging it in to the registration spec on its own. I believe it wo= uld be far too limiting. Finally, there seems to be an inconsistent style approach with draft-hardjo= no-oauth-resource-reg which uses ETags. Should this draft do so as well? That's an individual submission, not a working group draft. Nobody has, unt= il now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I person= ally don't see their utility here, though, and I wouldn't want to include a= wholly new mechanism this late. Specific items: --------------------- "token_endpoint_auth_method" There is some confusion as to whether this applies to server or client auth= entication. Suggest renaming parameter to "token_endpoint_client_auth_meth= od" This is the first I've heard of this particular confusion. I'm fine with ei= ther name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. * Currently, the API only supports a single value instead of an array. If = the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it s= hould not be used. I would rather like this to be an array, personally, and brought it up with= the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% posi= tive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. Also note that this field, like all others in =A72, represents two things: = the client telling the server "I want to use this value for this field", an= d the server telling the client "this is the value you have for this field"= . It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator i= s nice enough to tell you what their decision was instead of just decapitat= ing you. * There is no authn method for "client_secret_saml" or "private_key_saml". Nobody has really asked that these two be included or specified. The extens= ion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use= ? There are no profiles referenced or defined for "client_secret_jwt" or "pri= vate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover th= ese types of flows. They only cover bearer flows. "client_secret_jwt" and = "private_key_jwt" seem to have some meaning within OpenID Connect, but I no= te that OIDC does not fully define these either. The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically. There is no authentication method defined for "client_bearer_saml" or "clie= nt_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration spec should accept these. I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to. A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined. That's possible, but they are in active use already. About "tos_uri" and "policy_uri" The distinction between tos_uri and policy_uri is unclear. Can we clarify = or combine them? Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for the= m to be split. Also, aren't these really URIs or are they meant to be URLs? There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at u= s, which is a plus. About "jwks_uri" A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-key-09 is needed. Yes, you're correct, I'll add that. Should be URL instead of URI? See above. :) Section 2.1 In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. It's there in the copy of -10 I'm reading off of ietf.org= right now =85 ? =93As such, a server supporting these fields SHOULD take steps to ensure th= at a client cannot register itself into an inconsistent state.=94 We may want to define more detailed HTTP error response. E.g. 400 status co= de + defined error code (=93invalid_client_metadata=94)? I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special. Section 2.2 May want to add: When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in =93clie= nt_name=94, instead of =93client_name#en=94) the OAuth server may use inter= pret the language used based on server configuration or heuristics. That seems inconsistent with what we already have: If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or scrip= t of the string value, and the string value MUST be used as-is wherever it = is presented in a user interface. Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. Section 3 Existing text: =93In order to support open registration and facilitate wider interoperabil= ity, the Client Registration Endpoint SHOULD allow initial registration req= uests with no authentication. These requests MAY be rate-limited or otherw= ise limited to prevent a denial-of-service attack on the Client Registratio= n Endpoint.=94 I would suggest to change the first =93SHOULD=94 to =93MAY=94. In most cl= oud services, the first client is registered by a human user. Then, other c= lients can be further used to automate other client registration. So, the = first request would typically come with an authenticated user identity. I think the weight of "SHOULD" is appropriate here, because I believe that = turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule. On the flip side, the earlier paragraph: =93The Client Registration Endpoint MAY accept an initial authorization cre= dential in the form of an OAuth 2.0 [RFC6749] access token in order to limi= t registration to only previously authorized parties. The method by which t= his access token is obtained by the registrant is generally out-of-band and= is out of scope of this specification.=94 I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= . That access token would carry a human user authenticated identity somehow. = In some cases, it can be a pure authenticated user assertion token. Again, disagree, for the same reasoning as above. About section 4.3: If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the Registration Access Token used to make this request SHOULD be immediately revoked. If the Client does not exist on this server, shouldn't it return a "404 Not= Found"? If revoking the registration access token, is it bound to a single client r= egistration? This is not clear. What is the lifecycle around registration= access token? Only hint is in the Client Information Response in section 5= .1. The language about the 401 here (and in other nearby sections) is specifica= lly so that you treat a missing client and a bad registration access token = the same way. You see, returning a 404 here actually indicates things were = in an inconsistent state. Namely, that the registration access token was st= ill valid but the client that the registration access token was attached to= doesn't exist anymore. The registration access token in meant to be tied t= o a client's instance (or registration), so it's actually more sensible to = act as though the registration access token isn't valid anymore. In at leas= t some implementations (specifically ours at MITRE that's built on SECOAUTH= in Java), you'd never be able to reach the 404 state due to consistency ch= ecking with the inbound token. Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at = the issuance of a new client_id with that instance. That token might be rev= oked and a new one issued on Read and Update requests to the Client Configu= ration Endpoint (and the client needs to be prepared for that -- same as th= e client_secret), and it will be revoked when the client is deleted either = with a Delete call to the Client Configuration Endpoint or something happen= ing out-of-band to kill the client. Should we add more explanatory text to the definition in the terminology se= ction? Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd like. About section 5.1: Is registration_access_token unique? Or is it shared by multiple instances= ? If shared, then registration_access_token can't be revoked on delete of= client. Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, Suggest to rename =93issued_at=94 to =93id_issued_at=94 While I do like the suggestion of changing these to client_secret_expires_a= t and client_id_issued_at, and I think these are more clear and readable, I= don't want to change the syntax during last call unless there is a clear n= eed and a clear consensus for doing so. Section 7 When a client_secret expires is it the intent that clients do an update or = refresh to get a new client secret? Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this. Again, thanks for the very thorough read through. Have you implemented any = of the spec yet, either as-is or with any of your suggested changes? -- Justin --_000_1413870BD56F40CF8C518E610355C2DDmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8ABA615141B5EF488A770F6E360A28F9@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I think that's exactly the case, which is why it's such valuable feedback. = It's obvious to me, as the editor, what all the parts do. What I was hoping= to do with the explanations below was ferret out what key bit of informati= on was missing from which part of the spec, so that we can make things more explicit and clear where needed.

Looking forward to your responses,

 -- Justin

On May 15, 2013, at 9:17 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

I will look over your comments. But looking at some, i was not looking= for an explanation but rather I think the text should explain.  

For example the registration access token seemed very mysterious. It t= ook a lot of effort to understand what was going on. 

Maybe i am seeing this as I am looking at the spec with fresh eyes?

Phil

On 2013-05-15, at 17:53, "Richer, Justin P." <jricher@mitre.org> wrote:

Phil, many thanks for the extremely thorough revi= ew! It is very useful indeed. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is fo= r! My apologies for not getting many of these concerns to the WG much earli= er.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework= now that we are starting to consider how individual client applications sh= ould operate when there is one or more deployments of a particular resource= API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to = standards based, open source based, and commercial based deployments where = there are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of iss= ues that I would like to see made more clear in early part of the spec:

1.  How is a new client application recognized for the first time= when deployed against a particular SP endpoint?  Should clients actua= lly assert an application_id UUID that never changes and possibly a version= id that does change with versions?

In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a p= articular OpenID Connect provider, then you can define semantics for tying = together classes of clients (see below for more discussion on this very point). But in general, a client is just = going to show up as a new instance to the AS and get issued a new, unique c= lient_id, and that's that. 


2.  How are client credentials managed. Are we assuming client cr= edentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings= ), then I welcome suggestions and specific text as to how to make that clea= r. 

  How does a client authenticate the first time and subsequent ti= mes to the registration service?

This is a separate question all together, as it does not involve the c= lient_secret or client_id at all. Rather, the first time the client shows u= p to the registration service, it may either:
  - Not authenticate at all (this is the true public, open regist= ration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a beare= r token). How the client gets that bearer token and what the bearer token m= eans to the AS beyond "this client is authorized to register" is = out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean the= same instance of a client with a particular client_id) shows up at the reg= istration endpoint (actually, the Client Configuration Endpoint), it uses i= ts Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token t= hat is unique to the client instance.


3.  How is versioning of clients managed? Should each new version= of a client require a change in client registration including possibly cha= nging client_id and authentication credential? I don't have a strong feelin= g, but it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global policy= would ever fly here. Especially if you consider that the entire notion of = "version" is more fluid these days than it ever has been. I would= n't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both cl= ient developers and server developers institute reasonably good policy.

4.  What is the registration access token? Why is is used? What i= s its life-cycle?  When is it issued, when is it changed? When is it d= eleted?

See the response above above and the definition in =A71.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Aut= horization Server through the Client Registration Endpoint which is used by= the Client to authenticate itself during read, update, and delete operatio= ns. This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.


If we distinguish between first time registration of a particular clie= nt software package, it is possible that somethings like authentication met= hod can be negotiate in or out-of-band at that time. Subsequent registratio= ns should only have parameters for items that could change per deployment (like tos_uri).  I think token= _endpoint_auth_method is one thing that should not be negotiated per instan= ce.

When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiate= d or be different for the same client software? Should not all instances us= e the same authentication method.

I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change p= er instance. And instance, you should keep in mind, is defined as any one c= opy of the client code connecting to any new authorization server. That pairing creates the client_id, and t= herefore the instance, and therefore the registration access token, and the= refore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the A= S find out about it? And there's no way other than per-instance for the ser= ver to tell the client which token_endpoint_auth_method to use. All instanc= es will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And = each AS will tell each instance that registers with it to use a particular = auth method. There is no way to tie together different instances across (or= within) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth serve= rs. This is why, with Blue Button+, we specified a specific token forma= t for the initial access token that the clients use to call the registration endpoint the first time,  as= well as a discovery protocol against a centralized server that handles pre= -registration. All of this machinery is, in my opinion, a stupendous overki= ll for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abst= ract out and make its own spec that extends the Dyn Reg spec in a fully com= patible way. Furthermore, even in Blue Button+ we specify that all auth= servers MUST also accept open registration, without an initial access token, where the client simply shows up and says= "hey, here are my parameters." The auth server has no way to kno= w in this case any kind of out-of-band negotiation for different things. In= BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these di= fferent cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its own= . I believe it would be far too limiting.


Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg=  which uses ETags. Should this draft do so as well?

That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource = registration draft comes from) uses ETags, hence their inclusion there. I p= ersonally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this l= ate.


Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client= authentication.  Suggest renaming parameter to "token_endpoint_c= lient_auth_method"

This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes withou= t very, very compelling reasons to do so.


* Currently, the API only supports a single value instead of an array.=  If the purpose is to allow the client to know what auth methods it s= upports, this should be an array indicated what methods the client supports= - or it should not be used.

I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it w= as decided that a single value was simpler and sufficient for the purpose. = The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this= very issue in the WG here but didn't receive any traction on it, so single= it remains.

Also note that this field, like all others in =A72, represents two thi= ngs: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last= word anyway. But at least this dictator is nice enough to tell you what th= eir decision was instead of just decapitating you.


* There is no authn method for "client_secret_saml" or "= ;private_key_saml".

Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an absolute URI) would allow someone else to defi= ne these. Is the definition in the SAML Assertion draft sufficient for thei= r use?


There are no profiles referenced or defined for "client_secret= _jwt" or "private_key_jwt". Neither of the JWT or SAML Beare= r drafts referenced cover these types of flows. They only cover bearer flow= s.  "client_secret_jwt" and "private_key_jwt" seem= to have some meaning within OpenID Connect, but I note that OIDC does not ful= ly define these either.

The JWT assertion draft does say how to use a JWT for client authentic= ation, and the DynReg text differentiates between a client signing said JWT= with its own secret symmetrically vs. a client using its own private key, = asymmetrically.


There is no authentication method defined for "client_bearer_saml= " or "client_bearer_jwt" or "client_bearer_ref". &= nbsp;Since the bearer specs say this is acceptable,  the dynamic regis= tration spec should accept these.

I don't understand this bit -- where are these defined in RFC6750? I d= on't even know what client_bearer_ref would refer to.


A possible suggestion is to remove client_secret_jwt and private_key_j= wt and define those as register extensions since these profiles are not def= ined.

That's possible, but they are in active use already. 



About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can w= e clarify or combine them?

Terms of service and policy are two different documents. One is someth= ing that a user accepts (generally describing what the user will do), one i= s a statement of what the service provider (in this case, the client) will = do. More importantly, we used to have only one, and several people asked for them to be split.
 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is appar= ently trying to deprecate URL in favor of URI in new specs. So in practice = they'll nearly always be URLs, but since all URLs are URIs we're not techni= cally incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.


About "jwks_uri"

A normative reference for http://tools.ie= tf.org/html/draft-ietf-jose-json-web-key-09 is needed. 

Yes, you're correct, I'll add that.

=  
Should be URL instead of URI?

See above. :)


Section 2.1

In the table urn:ietf:params:oauth:gr= ant-type:jwt-bearer is missing.

It's there in the copy of -10 I'm reading off of ietf.org right now =85 ?


=93As such, a server supporting these fields SHOULD take steps to= ensure that a client cannot register itself into an inconsistent state.=94=

We may want to define more detailed HTTP error response. E.g. 400 stat= us code + defined error code (=93invalid_client_metadata=94)?

I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce grant-type= and response-type restrictions, but servers that can't or don't care about= restricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When =93#= =94 language tag is missing, (e.g. =93#en=94 is missing in =93client_name= =94, instead of =93client_name#en=94) the OAuth server may use interpr= et the language used based on server configuration or heuristics.=

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make any assumptions about the language, character set, or = script of the string value, and the string value MUST be used as-is whereve= r it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try to = get fancy.


Section 3

Existing text:

=93In order to supp= ort open registration and facilitate wider interoperability, the Clien= t Registration Endpoint SHOULD allow initial registration re= quests with no authentication.  These requests MAY be r= ate-limited or otherwise limited to prevent a denial-of-service attack on the Cli= ent Registration Endpoint.=94

I would suggest to change the first =93SHOULD=94 to =93MAY=94.   = In most cloud services, the first client is registered by a human user= . Then, other clients can be further used to automate other clien= t registration.  So, the first request would typically come = with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because = I believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the rule.&nb= sp;


On the flip side, the earlier paragraph:

=93The Client Regis= tration Endpoint MAY accept an initial authorization credential i= n the form of an OAuth 2.0 [RFC6749] access token in order to lim= it registration to only previously authorized parties. The method by which this access token is obtained by the registrant is ge= nerally out-of-band and is out of scope of this specification.=94

I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= .

That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion toke= n.

Again, disagree, for the same reasoning as above.


About section 4.3:

If the client does not exist on this server, the server =
MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return = a "404 Not Found"?

If revoking the registration access token, is it bound to a single client r= egistration?  This is not clear.  What is the lifecycle around re= gistration access token? Only hint is in the Client Information Response in= section 5.1.

The language about the 401 here (and in other nearby sections) is spec= ifically so that you treat a missing client and a bad registration access t= oken the same way. You see, returning a 404 here actually indicates th= ings were in an inconsistent state. Namely, that the registration access token was still valid but the client that the= registration access token was attached to doesn't exist anymore. The regis= tration access token in meant to be tied to a client's instance (or registr= ation), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at = least some implementations (specifically ours at MITRE that's built on SECO= AUTH in Java), you'd never be able to reach the 404 state due to consistenc= y checking with the inbound token.

Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begin= s at the issuance of a new client_id with that instance. That token might b= e revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the cli= ent needs to be prepared for that -- same as the client_secret), and it wil= l be revoked when the client is deleted either with a Delete call to the Cl= ient Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sin= ce I don't think it's as clear as we'd like.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple= instances?   If shared, then registration_access_token can't be revok= ed on delete of client.

Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, 
Suggest to rename =93issued_at=94 to =93id_issued_at=94

While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readab= le, I don't want to change the syntax during last call unless there is a cl= ear need and a clear consensus for doing so.


Section 7

When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed ab= ove, I'm not sure that's as clear as it needs to be, and I welcome suggesti= ons on how to clarify this.



Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either as-is or with any of your suggested changes?

 -- Justin

--_000_1413870BD56F40CF8C518E610355C2DDmitreorg_-- From phil.hunt@oracle.com Wed May 15 19:30:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C034F11E80F0 for ; Wed, 15 May 2013 19:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg2g7oDRydY5 for ; Wed, 15 May 2013 19:30:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5079021F8A74 for ; Wed, 15 May 2013 19:30:54 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4G2UoAF026884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 02:30:51 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4G2UoWR010918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2013 02:30:51 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4G2UoEZ006106; Thu, 16 May 2013 02:30:50 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 May 2013 19:30:48 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_686AE6A2-48A6-4A3D-AED4-88F7F3F6E906" From: Phil Hunt In-Reply-To: <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> Date: Wed, 15 May 2013 19:30:55 -0700 Message-Id: References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 02:30:59 -0000 --Apple-Mail=_686AE6A2-48A6-4A3D-AED4-88F7F3F6E906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See my specific comments below=85 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > Phil, many thanks for the extremely thorough review! It is very useful = indeed.=20 >=20 > My comments and responses to each point are inline.=20 >=20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: >=20 >> It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. >>=20 >> Overall =20 >> ----------- >> I think dynamic registration is a critical part of the OAuth = framework now that we are starting to consider how individual client = applications should operate when there is one or more deployments of a = particular resource API. We've moved from the simple use case of a = single API provider like Facebook or Flickr and moved on to standards = based, open source based, and commercial based deployments where there = are multiple service endpoints and many clients to manage. >>=20 >> The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: >>=20 >> 1. How is a new client application recognized for the first time = when deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? >=20 > In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. >=20 >>=20 >> 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? >=20 > The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 Something like this should be in the draft. >=20 >> How does a client authenticate the first time and subsequent times = to the registration service? >=20 > This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: > - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. >=20 > Subsequent times that the same registered client (by which we mean the = same instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. Something like this should be in the draft. >=20 >>=20 >> 3. How is versioning of clients managed? Should each new version of = a client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. >=20 > This is up to the AS, really, and I don't think that any global policy = would ever fly here. Especially if you consider that the entire notion = of "version" is more fluid these days than it ever has been. I wouldn't = mind adding a discussion in the security considerations if it merits = mentioning though, so that we can help both client developers and server = developers institute reasonably good policy. I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. Since you = have an update are clients expected to update /re-register or not? I'm = not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. >=20 >>=20 >> 4. What is the registration access token? Why is is used? What is = its life-cycle? When is it issued, when is it changed? When is it = deleted? >=20 > See the response above above and the definition in =A71.2:=20 >=20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. >=20 > If this can be clarified, I welcome text suggestions. The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. Client Registration Endpoint: The OAuth 2.0 Endpoint through which a Client can request new registration. The means of the Client obtaining the URL for this endpoint are out of scope for this specification. o Client Configuration Endpoint: The OAuth 2.0 Endpoint through which a specific Client can manage its registration information, provided by the Authorization Server to the Client. This URL for this endpoint is communicated to the client by the Authorization Server in the Client Information Response. o Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client. >=20 >>=20 >> If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. >=20 >> When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. >=20 >=20 > I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? We still disagree on this. It is my assertion that clients should NEVER = ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. I haven't heard a reason justifying this parameter other then "it is = needed". Why? > And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. >=20 > Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. >=20 >>=20 >> Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? >=20 > That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. >=20 >>=20 >> Specific items: >> --------------------- >> "token_endpoint_auth_method" >>=20 >> There is some confusion as to whether this applies to server or = client authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" >=20 > This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. The question was raised to me by some new developers. It seems obvious = to us as experienced OAuth persons, but to new developers it seems = unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) >=20 >>=20 >> * Currently, the API only supports a single value instead of an = array. If the purpose is to allow the client to know what auth methods = it supports, this should be an array indicated what methods the client = supports - or it should not be used. >=20 > I would rather like this to be an array, personally, and brought it up = with the OpenID Connect working group about six months ago. But there it = was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method = based on its own policy. >=20 > Also note that this field, like all others in =A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. This is the heart of my objection. This fuzziness is is going to lead to = interop issues. >=20 >>=20 >> * There is no authn method for "client_secret_saml" or = "private_key_saml". >=20 > Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. >=20 >>=20 >> There are no profiles referenced or defined for "client_secret_jwt" = or "private_key_jwt". Neither of the JWT or SAML Bearer drafts = referenced cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. >=20 > The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. Actually my interpretation is the JWT draft assumes the JWT Bearer is a = bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) Regardless, you are introducing a new profile which is undefined. >=20 >>=20 >> There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. >=20 > I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. 6750 says you can use a bearer assertion (e.g. obtained from an IDP) and = wield it as an authentication assertion. The client is NOT creating or = modifying the assertion. The client is simply passing one it previously = obtained. What you are describing is not bearer. It is holder of key. Very very = different.=20 >=20 >>=20 >> A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. >=20 > That's possible, but they are in active use already.=20 That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. >=20 >>=20 >>=20 >> About "tos_uri" and "policy_uri" >>=20 >> The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? >=20 > Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. > =20 >>=20 >> Also, aren't these really URIs or are they meant to be URLs? >=20 > There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. Arg. Nice. Then the text should say the value passed must resolve to a = valid web page, document, whatever. >=20 >>=20 >> About "jwks_uri" >>=20 >> A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 >=20 > Yes, you're correct, I'll add that. >=20 >> =20 >> Should be URL instead of URI? >=20 > See above. :) >=20 >>=20 >> Section 2.1 >>=20 >> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >> is missing. >=20 > It's there in the copy of -10 I'm reading off of ietf.org right now =85 = ? ' Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >=20 >=20 >>=20 >> =93As such, a server supporting these fields SHOULD take steps to = ensure that a client cannot register itself into an inconsistent state.=94= >>=20 >> We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=93invalid_client_metadata=94)? >=20 > I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. >=20 >>=20 >> Section 2.2 >>=20 >> May want to add: >>=20 >> When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in = =93client_name=94, instead of =93client_name#en=94) the OAuth server may = use interpret the language used based on server configuration or = heuristics. >=20 > That seems inconsistent with what we already have: >=20 > If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. >=20 > Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. I will discuss with our developers. I'm not sure the as-is works. =20 Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? >=20 >>=20 >> Section 3 >>=20 >> Existing text: >>=20 >> =93In order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=94 >>=20 >> I would suggest to change the first =93SHOULD=94 to =93MAY=94. In = most cloud services, the first client is registered by a human user. = Then, other clients can be further used to automate other client = registration. So, the first request would typically come with an = authenticated user identity.=20 >=20 > I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 I think you are reading it wrong -- a double-negative issue. The end of = the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? >=20 >>=20 >> On the flip side, the earlier paragraph: >>=20 >> =93The 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.=94 >>=20 >> I tend to think it would be better to change this =93MAY=94 to = =93SHOULD=94. >>=20 >> That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. >=20 > Again, disagree, for the same reasoning as above. Same reasoning.=20 >=20 >>=20 >> About section 4.3: >>=20 >> If the client does not exist on this server, the server MUST respond >> with HTTP 401 Unauthorized, and the Registration Access Token used = to >> make this request SHOULD be immediately revoked. >>=20 >> If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >>=20 >> If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. >=20 > The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. >=20 > Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 >=20 > Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. I think we should look at it. >=20 >> =20 >> About section 5.1: >>=20 >> Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. >>=20 >> Suggest rename =93expires_at=94 to =93client_secret_expires_at=94,=20 >>=20 >> Suggest to rename =93issued_at=94 to =93id_issued_at=94 >=20 > While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, > I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. That's why we are having last call. To confirm consensus on the draft.=20= Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. >=20 >>=20 >> Section 7 >>=20 >> When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? >=20 > Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. >=20 >=20 >=20 > Again, thanks for the very thorough read through. Have you implemented = any of the spec yet, either as-is or with any of your suggested changes? Yes. Much of the feedback is coming from our development community.=20 >=20 > -- Justin --Apple-Mail=_686AE6A2-48A6-4A3D-AED4-88F7F3F6E906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = my specific comments below=85

Phil

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





On 2013-05-15, at 5:53 PM, Richer, Justin P. = wrote:

Phil, many thanks for the extremely thorough review! It is very useful = indeed. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

It seems unfortunate that I have not gotten a chance to get into = this level of detail much earlier. But then, I guess that's what LC = review is for! My apologies for not getting many of these concerns to = the WG much earlier.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth = framework now that we are starting to consider how individual client = applications should operate when there is one or more deployments of a = particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on = to standards based, open source based, and commercial based deployments = where there are multiple service endpoints and many clients to = manage.

The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec:

1.  How is a new client application recognized for the first = time when deployed against a particular SP endpoint?  Should = clients actually assert an application_id UUID that never changes and = possibly a version id that does change with versions?

In the general case, why is any recognition required? If you're = doing things as part of a larger protocol ecosystem, like Blue Button+ = or a particular OpenID Connect provider, then you can define semantics = for tying together classes of clients (see below for more discussion on this very point). But in general, a client is = just going to show up as a new instance to the AS and get issued a new, = unique client_id, and that's = that. 

I = think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. =  It is useful to understand that a client application represents a = set of code that should behave in a consistent way.  It seems to me = the first time a new application shows up is very different from the = subsequent instances that register. For example, after the first = registration, subsequent instances don't need special review or approval = to the same degree.


2.  How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the = expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=A74.2) = to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple = refactorings), then I welcome suggestions and specific text as to how to = make that clear. 
Something = like this should be in the draft.

  How does a client authenticate the first time and subsequent = times to the registration service?

This is a separate question all together, as it does not involve = the client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a = bearer token). How the client gets that bearer token and what the bearer = token means to the AS beyond "this client is authorized to register" is = out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean = the same instance of a client with a particular client_id) shows up at = the registration endpoint (actually, the Client Configuration Endpoint), = it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer = token that is unique to the client = instance.

Somethi= ng like this should be in the draft.


3.  How is versioning of clients managed? Should each new = version of a client require a change in client registration including = possibly changing client_id and authentication credential? I don't have = a strong feeling, but it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global = policy would ever fly here. Especially if you consider that the entire = notion of "version" is more fluid these days than it ever has been. I = wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both = client developers and server developers institute reasonably good = policy.

I guess = the issue is that when a client upgrades it may have access to the old = credentials. What is the intent then of registration.  Since you = have an update are clients expected to update /re-register or not? =  I'm not sure this is a security consideration but more part of the = whole change management function dynamic registration = supports.


4.  What is the registration access token? Why is is used? = What is its life-cycle?  When is it issued, when is it changed? = When is it deleted?

See the response above above and the definition in = =A71.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client.

If this can be clarified, I welcome text = suggestions.

The = latter part of 1.2 didn't seem like terminology but rather architecture = or part of the introduction that describes what the spec does. The third = point doesn't seem to fit with the other two except to say that the = dynamic registration endpoints use their own access tokens called = registration access tokens.

Client Registration Endpoint: The =
OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.

   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.

   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.




If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance.

When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method.

I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, = and therefore the instance, and therefore the registration access token, = and therefore the registration itself at a conceptual level. So there is = no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would = the AS find out about it? =

We still = disagree on this. It is my assertion that clients should NEVER ask for a = particular token auth method. Since it is the AS that is authenticating = the client, then it is the AS's right to set the authentication policy. =  The role of dynamic reg endpoint is to inform the client what it = must do.  My assumption is that during the first time a piece of = software is registered (the first instance), there could be some OOB = discussion by an administrator to approve the particular authentication = type for the AS in question.

I haven't heard a = reason justifying this parameter other then "it is needed". =  Why?

And there's = no way other than per-instance for the server to tell the client which = token_endpoint_auth_method to use. All instances will probably ask for = the same token_endpoint_auth_method from all auth servers they talk to, right? = And each AS will tell each instance that registers with it to use a = particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to = tie together different instances of the same code across (or within) = auth servers. This is why, with Blue Button+, we specified a specific = token format for the initial access token that the clients use to call the registration endpoint the first time, =  as well as a discovery protocol against a centralized server that = handles pre-registration. All of this machinery is, in my opinion, a = stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to = abstract out and make its own spec that extends the Dyn Reg spec in a = fully compatible way. Furthermore, even in Blue Button+ we specify that = all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these = different cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its = own. I believe it would be far too = limiting.


Finally, there seems to be an inconsistent style approach = with 


Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or = client authentication.  Suggest renaming parameter to = "token_endpoint_client_auth_method"

This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do = so.

The = question was raised to me by some new developers. It seems obvious to us = as experienced OAuth persons, but to new developers it seems unclear. =  Also, now that you are introducing registration authentication, = the whole thing gets very confusing. So it is useful disambiguate all = the parameters where possible.  That said, I wouldn't mind shorter = names (maybe not quite as short as the JOSE stuff ;-)


* Currently, the API only supports a single value instead of an = array.  If the purpose is to allow the client to know what auth = methods it supports, this should be an array indicated what methods the = client supports - or it should not be used.

I would rather like this to be an array, personally, and brought it = up with the OpenID Connect working group about six months ago. But there = it was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up = this very issue in the WG here but didn't receive any traction on it, so = single it = remains.

I can = get behind multiple values. In this case, it changes the meaning of the = parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can = perform. This allows the server to assign the appropriate method based = on its own policy.

Also note that this field, like all others in =A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the = last word anyway. But at least this dictator is nice enough to tell you = what their decision was instead of just decapitating = you.

This is = the heart of my objection. This fuzziness is is going to lead to interop = issues.


* There is no authn method for "client_secret_saml" or = "private_key_saml".

Nobody has really asked that these two be included or specified. = The extension mechanism (using an absolute URI) would allow someone else = to define these. Is the definition in the SAML Assertion draft = sufficient for their = use?

I think = this is coming from the fact that there is a JWT bearer draft and a SAML = bearer draft.  The truth is you are defining an authentication that = isn't even defined.


There are no profiles referenced or defined for = "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML = Bearer drafts referenced cover these types of flows. They only cover = bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not = fully define these either.

The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, = asymmetrically.

<= div>Actually my interpretation is the JWT draft assumes the JWT Bearer = is a bearer token.  The assumption is that if a client has the = assertion it has the right to present it.  IOW. The JWT Bearer = Draft is most definitively not a JWT HoK Draft. =  :-)


6750 says = you can use a bearer assertion (e.g. obtained from an IDP) and wield it = as an authentication assertion.  The client is NOT creating or = modifying the assertion. The client is simply passing one it previously = obtained.

What you are describing is not = bearer. It is holder of key. Very very different. 


A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined.

That's possible, but they are in active use = already. 

Th= at may be true. But then you need to write another draft so the rest of = us can implement it in an interoperable way.  Me I prefer not to = guess what you are doing.



About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear. =  Can we clarify or combine them?

Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several people asked for them to be = split.

Several = developers were confused by this. In particular they couldn't figure out = which was used for what.  Just passing along the = feedback.
 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a = plus.

Arg. = Nice.  Then the text should say the value passed must resolve to a = valid web page, document, whatever.
'
Sorry I = meant: 


=93As such, a server supporting these fields SHOULD take = steps to ensure that a client cannot register itself into an = inconsistent state.=94

We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=93invalid_client_metadata=94)?

I'd be fine with defining a more explicit error state in this case. = I think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When =93#=94 language tag is missing, (e.g. =93#en=94 is = missing in =93client_name=94, instead of =93client_name#en=94) the = OAuth server may use interpret the language used based on = server configuration or heuristics.

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try = to get fancy.

I = will discuss with our developers. I'm not sure the as-is works. =  

Is it the intent that when the client = has localized "client_name" for example, it should pass all language = variations in a JSON array?

Or, should part of = the registration be to indicate which interface language the client = wishes to use?  Then it only passes a single value for that = registration?


Section 3

Existing text:

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

I would suggest to change the first =93SHOULD=94 to =93MAY=94.  =  In most cloud services, the first client is registered by a = human user. Then, other clients can be further used to = automate other client registration.  So, the = first request would typically come with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because I = believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the = rule. 

I = think you are reading it wrong -- a double-negative issue. The end of = the sentence is "no authentication".  You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you?

On the flip side, the earlier paragraph:

=93The 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.=94

I tend to think it would be better to change this =93MAY=94 to = =93SHOULD=94.

That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.

Again, disagree, for the same reasoning as = above.

Same = reasoning. 


About section 4.3:

If the =
client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it = return a "404 Not Found"?

If revoking the registration access token, is it bound to a single = client registration?  This is not clear.  What is the = lifecycle around registration access token? Only hint is in the Client = Information Response in section 5.1.

The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that = the registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In = at least some implementations (specifically ours at MITRE that's built = on SECOAUTH in Java), you'd never be able to reach the 404 state due to = consistency checking with the inbound token.

Since the intent of the registration access token is that it's = bound to a single instance, its lifecycle is generally tied to the = lifecycle begins at the issuance of a new client_id with that instance. = That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the = client needs to be prepared for that -- same as the client_secret), and = it will be revoked when the client is deleted either with a Delete call = to the Client Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd = like.

I think = we should look at it.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by = multiple instances?   If shared, then registration_access_token = can't be revoked on delete of client.

Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, 
Suggest to rename =93issued_at=94 to =93id_issued_at=94

While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, =

I = don't want to change the syntax during last call unless there is a clear = need and a clear consensus for doing = so.

That's why = we are having last call. To confirm consensus on the = draft. 

Same reasoning as earlier. You now = have multiple tokens (registration access and client) in play. The spec = needs to be clear which one it is talking about.


Section 7

When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update = methods on the client configuration endpoint to get its new secret. As = discussed above, I'm not sure that's as clear as it needs to be, and I = welcome suggestions on how to clarify this.



Again, thanks for the very thorough read through. Have you = implemented any of the spec yet, either as-is or with any of your = suggested changes?

Yes. Much of = the feedback is coming from our development = community. 

 -- Justin

= --Apple-Mail=_686AE6A2-48A6-4A3D-AED4-88F7F3F6E906-- From sakimura@gmail.com Thu May 16 01:44:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4221F907E for ; Thu, 16 May 2013 01:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI3f+gF4OPSG for ; Thu, 16 May 2013 01:44:25 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8457821F8F38 for ; Thu, 16 May 2013 01:44:24 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id t13so102114lbd.1 for ; Thu, 16 May 2013 01:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=jhjIntGBRF0S4slVs3ZpWoNmV0Vm8l7Iq3V3asDqcwU=; b=0gF2AjTmCoK13V8BmGNfa7HqWAZIfNJ2H6pPyRwV/0taEogMwGX4v490x8NzYGVGaP NK2Z1PCIxF17P/NCIe41+95NRN7JXu3h05C1Bod6BdpxZL8wK4MgDVvg3Bvzt0ZiUBQ3 JRoNu9YA//Fl8rd3LyOS6ouz+XTCwobCz12KxK5y+AWsLvAv2PPUxI0gaOaCyyVCwcGD Swts6BiZ3oAx0CAOJY0QCRDBPyzfsmNm1DYKhIW7dOwIHhv3ZErKWGl9xSvmt6UQLOG3 Md2VB846WVhURLa9e8ejoNLgQBeLxClQNozu+X7bredXq4I2o7m3SD4mf5Lik47pTCLp nlpw== X-Received: by 10.112.6.135 with SMTP id b7mr19372579lba.104.1368693863394; Thu, 16 May 2013 01:44:23 -0700 (PDT) References: <5190B512.6060903@cs.tcd.ie> <265449F1-D674-44CE-957B-204E765B6D15@mitre.org> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <265449F1-D674-44CE-957B-204E765B6D15@mitre.org> Date: Thu, 16 May 2013 10:44:25 +0200 Message-ID: <-2191260347151674055@unknownmsgid> To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=14dae947303b88b76404dcd1df18 Cc: oauth Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 08:44:29 -0000 --14dae947303b88b76404dcd1df18 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit I am by no means suggesting IETF to use Vim/emacs. That is counter productive. I was merely pointing out that one has to decide the diff policy wisely. I like XMLMind's XML2RFC. Too bad it became commercial product only. Intelligent diffs would work fine. However, there have been push back to that since that made it difficult for the users that just look at the web. In IETF, we should take the rfcdiff, IMHO, so whitespace changes in XML should not be an issue. Nat 2013/05/15 22:11$B!"(B"Richer, Justin P." $B$N%a%C%;!<%8(B: I have already been using an approach like this for all of the drafts that I edit, most notably the DynReg WG document and both the Introspection and Chaining individual submissions. I run everything through my GitHub repository here: https://github.com/jricher/oauth-spec/ I use the issue tracker there to note down things that come up in the WG conversations on the list, so that when I actually do get to go edit things, I don't forget anything. Once or twice, I have gotten issues submitted directly to github, but the actual conversation around any real changes (beyond typos) always comes back to the list. I do think it would be worthwhile to connect the mailing list to the notifications of the tracker for official documents. It would be fairly easy to set up a GitHub organization that's backed by the mailing list's address for notifications, and I think other development platforms have similar capabilities. However, I completely disagree with ODIF's decision regarding editing tools. I've made some edits to the OIDF specs myself, and I find the "plain text editor" rule to be a draconian overreaction that makes creating good edits tedious, slow, and error-prone. In my personal experience, good tools like XML Mind's XML2RFC plugin are profoundly useful, and the formatting artifacts they create are minimal and easily ignored. The diffs that are tracked in Git are *far* from useless, and if you ask me, if you want to do a *real* diff on these documents you'd use the rfcdiff anyway, which ignores the XML formatting changes and focuses on the actual content. It's not perfect either, but it's far from useless. -- Justin On May 13, 2013, at 9:08 AM, Nat Sakimura wrote: I am probably biased since I am the one who introduced ticket driven version control to OIDF but it proved to be very valuable especially for transparency purposes. Each changes are linked to the ticket so it is easy to see why that change was made. As to the comments v.s. mailing list relationship is concerned, I think it is possible to forward all the comments to the list, and in case of IETF, it should do so. One feedback on the experience we had at OIDF is that XML Editing tools changes all sort of formatting making the diff at bitbucket useless. So, we had to resort to emacs/vim/ etc. my 2c. Nat Sakimura 2013/5/13 Stephen Farrell > > Hiya, > > On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: > > Hi all, > > the OpenID Connect had gained some experience with using version control > systems > > for editing specifications (and the use of issue trackers), see > > http://openid.bitbucket.org/. Based on a recent discussion in the IETF > (among > > the working group chairs) I am wondering what your experience is with > those > > tools and whether you see value in using these tools for document > editing in the > > OAuth working group. > > Sounds like a fine plan if the wg want to try it. Only thing I'd > note is that it means editors need to be *very* careful to bring > discussion back to the wg list when that's needed, since you will > likely get comments in the version control environment that are > not cc'd to the wg list. (The IETF will be considering generic > solutions for that, if you're interested get involved with the > tools team.) In turn, I suspect that means that wg chairs need > to make sure there's an editor who really gets when a change needs > to be discussed on the list and when its ok to just fix a typo. > > The httpbis wg have some experience doing this btw and have hit > that specific issue of comments being made on github but not the > list. There's a recent thread [1] that ends with good advice from > the wg chair. > > And in case someone asks, reasons why we need the wg list cc'd > include open-ness and to be clear as to what's an IETF > contribution. There're probably more but these are enough;-) > > Cheers, > S. > > [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html > > > > > 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 > -- 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 --14dae947303b88b76404dcd1df18 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGRpdiBk aXI9Imx0ciI+PGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUs MjU1LDApIj5JIGFtIGJ5IG5vIG1lYW5zIHN1Z2dlc3RpbmcgSUVURiB0byB1c2UgVmltL2VtYWNz LiBUaGF0IGlzIGNvdW50ZXIgcHJvZHVjdGl2ZS4gSSB3YXMgbWVyZWx5IHBvaW50aW5nIG91dCB0 aGF0IG9uZSBoYXMgdG8gZGVjaWRlIHRoZSBkaWZmIHBvbGljeSB3aXNlbHkuJm5ic3A7PC9zcGFu PjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUs MjU1LDApIj48YnI+PC9zcGFuPjwvZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJn YmEoMjU1LDI1NSwyNTUsMCkiPkkgbGlrZSBYTUxNaW5kJiMzOTtzIFhNTDJSRkMuIFRvbyBiYWQg aXQgYmVjYW1lIGNvbW1lcmNpYWwgcHJvZHVjdCBvbmx5LiZuYnNwOzwvc3Bhbj48ZGl2PjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1LDI1NSwyNTUsMCkiPjxicj4NCjwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1LDI1NSwy NTUsMCkiPkludGVsbGlnZW50IGRpZmZzIHdvdWxkIHdvcmsgZmluZS4gSG93ZXZlciwgdGhlcmUg aGF2ZSBiZWVuIHB1c2ggYmFjayB0byB0aGF0IHNpbmNlIHRoYXQgbWFkZSBpdCBkaWZmaWN1bHQg Zm9yIHRoZSB1c2VycyB0aGF0IGp1c3QgbG9vayBhdCB0aGUgd2ViLiZuYnNwOzwvc3Bhbj48L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSww KSI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJn YmEoMjU1LDI1NSwyNTUsMCkiPkluIElFVEYsIHdlIHNob3VsZCB0YWtlIHRoZSByZmNkaWZmLCBJ TUhPLCBzbyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gWE1MIHNob3VsZCBub3QgYmUgYW4gaXNzdWUu Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpy Z2JhKDI1NSwyNTUsMjU1LDApIj48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJh Y2tncm91bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSwwKSI+TmF0PC9zcGFuPjwvZGl2PjwvZGl2 PjwvZGl2PjxkaXYgc3R5bGU+PGJyPjIwMTMvMDUvMTUgMjI6MTEbJEIhIhsoQiZxdW90O1JpY2hl ciwgSnVzdGluIFAuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmci PmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgGyRCJE4lYSVDJTshPCU4GyhCOjxicj4NCjxicj48 L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT48ZGl2Pg0KDQo8bWV0YSBodHRwLWVx dWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0x Ij4NCg0KDQpJIGhhdmUgYWxyZWFkeSBiZWVuIHVzaW5nIGFuIGFwcHJvYWNoIGxpa2UgdGhpcyBm b3IgYWxsIG9mIHRoZSBkcmFmdHMgdGhhdCBJIGVkaXQsIG1vc3Qgbm90YWJseSB0aGUgRHluUmVn IFdHIGRvY3VtZW50IGFuZCBib3RoIHRoZSBJbnRyb3NwZWN0aW9uIGFuZCBDaGFpbmluZyBpbmRp dmlkdWFsIHN1Ym1pc3Npb25zLiBJIHJ1biBldmVyeXRoaW5nIHRocm91Z2ggbXkgR2l0SHViIHJl cG9zaXRvcnkgaGVyZToNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9qcmljaGVyL29hdXRoLXNwZWMvIj5odHRwczovL2dpdGh1Yi5jb20vanJpY2hl ci9vYXV0aC1zcGVjLzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdXNlIHRo ZSBpc3N1ZSB0cmFja2VyIHRoZXJlIHRvIG5vdGUgZG93biB0aGluZ3MgdGhhdCBjb21lIHVwIGlu IHRoZSBXRyBjb252ZXJzYXRpb25zIG9uIHRoZSBsaXN0LCBzbyB0aGF0IHdoZW4gSSBhY3R1YWxs eSBkbyBnZXQgdG8gZ28gZWRpdCB0aGluZ3MsIEkgZG9uJiMzOTt0IGZvcmdldCBhbnl0aGluZy4g T25jZSBvciB0d2ljZSwgSSBoYXZlIGdvdHRlbiBpc3N1ZXMgc3VibWl0dGVkIGRpcmVjdGx5IHRv IGdpdGh1YiwgYnV0IHRoZSBhY3R1YWwNCiBjb252ZXJzYXRpb24gYXJvdW5kIGFueSByZWFsIGNo YW5nZXMgKGJleW9uZCB0eXBvcykgYWx3YXlzIGNvbWVzIGJhY2sgdG8gdGhlIGxpc3QuIEkgZG8g dGhpbmsgaXQgd291bGQgYmUgd29ydGh3aGlsZSB0byBjb25uZWN0IHRoZSBtYWlsaW5nIGxpc3Qg dG8gdGhlIG5vdGlmaWNhdGlvbnMgb2YgdGhlIHRyYWNrZXIgZm9yIG9mZmljaWFsIGRvY3VtZW50 cy4gSXQgd291bGQgYmUgZmFpcmx5IGVhc3kgdG8gc2V0IHVwIGEgR2l0SHViIG9yZ2FuaXphdGlv bg0KIHRoYXQmIzM5O3MgYmFja2VkIGJ5IHRoZSBtYWlsaW5nIGxpc3QmIzM5O3MgYWRkcmVzcyBm b3Igbm90aWZpY2F0aW9ucywgYW5kIEkgdGhpbmsgb3RoZXIgZGV2ZWxvcG1lbnQgcGxhdGZvcm1z IGhhdmUgc2ltaWxhciBjYXBhYmlsaXRpZXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5Ib3dldmVyLCBJIGNvbXBsZXRlbHkgZGlzYWdyZWUgd2l0aCBPRElGJiMzOTtzIGRl Y2lzaW9uIHJlZ2FyZGluZyBlZGl0aW5nIHRvb2xzLiZuYnNwO0kmIzM5O3ZlIG1hZGUgc29tZSBl ZGl0cyB0byB0aGUgT0lERiBzcGVjcyBteXNlbGYsIGFuZCBJIGZpbmQgdGhlICZxdW90O3BsYWlu IHRleHQgZWRpdG9yJnF1b3Q7IHJ1bGUgdG8gYmUgYSBkcmFjb25pYW4gb3ZlcnJlYWN0aW9uIHRo YXQgbWFrZXMgY3JlYXRpbmcgZ29vZCBlZGl0cyB0ZWRpb3VzLCBzbG93LCBhbmQgZXJyb3ItcHJv bmUuJm5ic3A7SW4NCiBteSBwZXJzb25hbCBleHBlcmllbmNlLCBnb29kIHRvb2xzIGxpa2UgWE1M IE1pbmQmIzM5O3MgWE1MMlJGQyBwbHVnaW4gYXJlIHByb2ZvdW5kbHkgdXNlZnVsLCBhbmQgdGhl IGZvcm1hdHRpbmcgYXJ0aWZhY3RzIHRoZXkgY3JlYXRlIGFyZSBtaW5pbWFsIGFuZCBlYXNpbHkg aWdub3JlZC4gVGhlIGRpZmZzIHRoYXQgYXJlIHRyYWNrZWQgaW4gR2l0IGFyZSAqZmFyKiBmcm9t IHVzZWxlc3MsIGFuZCBpZiB5b3UgYXNrIG1lLCBpZiB5b3Ugd2FudCB0byBkbw0KIGEgKnJlYWwq IGRpZmYgb24gdGhlc2UgZG9jdW1lbnRzIHlvdSYjMzk7ZCB1c2UgdGhlIHJmY2RpZmYgYW55d2F5 LCB3aGljaCBpZ25vcmVzIHRoZSBYTUwgZm9ybWF0dGluZyBjaGFuZ2VzIGFuZCBmb2N1c2VzIG9u IHRoZSBhY3R1YWwgY29udGVudC4gSXQmIzM5O3Mgbm90IHBlcmZlY3QgZWl0aGVyLCBidXQgaXQm IzM5O3MgZmFyIGZyb20gdXNlbGVzcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PiZuYnNwOy0tIEp1c3RpbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE1heSAxMywgMjAxMywgYXQgOTowOCBB TSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5z YWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mbmJzcDt3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPkkgYW0gcHJvYmFibHkgYmlhc2VkIHNpbmNlIEkgYW0g dGhlIG9uZSB3aG8gaW50cm9kdWNlZCB0aWNrZXQgZHJpdmVuIHZlcnNpb24gY29udHJvbCB0byBP SURGIGJ1dCBpdCBwcm92ZWQgdG8gYmUgdmVyeSB2YWx1YWJsZSBlc3BlY2lhbGx5IGZvciB0cmFu c3BhcmVuY3kgcHVycG9zZXMuIEVhY2ggY2hhbmdlcyBhcmUgbGlua2VkIHRvIHRoZSB0aWNrZXQg c28gaXQgaXMgZWFzeSB0byBzZWUgd2h5IHRoYXQgY2hhbmdlIHdhcw0KIG1hZGUuJm5ic3A7DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyB0byB0aGUgY29tbWVudHMgdi5zLiBtYWlsaW5nIGxp c3QgcmVsYXRpb25zaGlwIGlzIGNvbmNlcm5lZCwgSSB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBm b3J3YXJkIGFsbCB0aGUgY29tbWVudHMgdG8gdGhlIGxpc3QsIGFuZCBpbiBjYXNlIG9mIElFVEYs IGl0IHNob3VsZCBkbyBzby4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9u ZSBmZWVkYmFjayBvbiB0aGUgZXhwZXJpZW5jZSB3ZSBoYWQgYXQgT0lERiBpcyB0aGF0IFhNTCBF ZGl0aW5nIHRvb2xzIGNoYW5nZXMgYWxsIHNvcnQgb2YgZm9ybWF0dGluZyBtYWtpbmcgdGhlIGRp ZmYgYXQgYml0YnVja2V0IHVzZWxlc3MuIFNvLCB3ZSBoYWQgdG8gcmVzb3J0IHRvIGVtYWNzL3Zp bS8gZXRjLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+bXkgMmMuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5OYXQgU2FraW11cmE8YnI+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTMv NS8xMyBTdGVwaGVuIEZhcnJlbGwgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86 c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoZW4uZmFycmVs bEBjcy50Y2QuaWU8L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCkhpeWEsPGJyPg0KPGRpdj4NCjxkaXYgY2xhc3M9 Img1Ij48YnI+DQpPbiAwNS8xMy8yMDEzIDA5OjA0IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90 ZTo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7IHRoZSBPcGVuSUQgQ29ubmVjdCBoYWQgZ2Fp bmVkIHNvbWUgZXhwZXJpZW5jZSB3aXRoIHVzaW5nIHZlcnNpb24gY29udHJvbCBzeXN0ZW1zPGJy Pg0KJmd0OyBmb3IgZWRpdGluZyBzcGVjaWZpY2F0aW9ucyAoYW5kIHRoZSB1c2Ugb2YgaXNzdWUg dHJhY2tlcnMpLCBzZWU8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQuYml0YnVja2V0 Lm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLmJpdGJ1Y2tldC5vcmcvPC9hPi4g QmFzZWQgb24gYSByZWNlbnQgZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiAoYW1vbmc8YnI+DQomZ3Q7 IHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycykgSSBhbSB3b25kZXJpbmcgd2hhdCB5b3VyIGV4cGVy aWVuY2UgaXMgd2l0aCB0aG9zZTxicj4NCiZndDsgdG9vbHMgYW5kIHdoZXRoZXIgeW91IHNlZSB2 YWx1ZSBpbiB1c2luZyB0aGVzZSB0b29scyBmb3IgZG9jdW1lbnQgZWRpdGluZyBpbiB0aGU8YnI+ DQomZ3Q7IE9BdXRoIHdvcmtpbmcgZ3JvdXAuPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NClNv dW5kcyBsaWtlIGEgZmluZSBwbGFuIGlmIHRoZSB3ZyB3YW50IHRvIHRyeSBpdC4gT25seSB0aGlu ZyBJJiMzOTtkPGJyPg0Kbm90ZSBpcyB0aGF0IGl0IG1lYW5zIGVkaXRvcnMgbmVlZCB0byBiZSAq dmVyeSogY2FyZWZ1bCB0byBicmluZzxicj4NCmRpc2N1c3Npb24gYmFjayB0byB0aGUgd2cgbGlz dCB3aGVuIHRoYXQmIzM5O3MgbmVlZGVkLCBzaW5jZSB5b3Ugd2lsbDxicj4NCmxpa2VseSBnZXQg Y29tbWVudHMgaW4gdGhlIHZlcnNpb24gY29udHJvbCBlbnZpcm9ubWVudCB0aGF0IGFyZTxicj4N Cm5vdCBjYyYjMzk7ZCB0byB0aGUgd2cgbGlzdC4gKFRoZSBJRVRGIHdpbGwgYmUgY29uc2lkZXJp bmcgZ2VuZXJpYzxicj4NCnNvbHV0aW9ucyBmb3IgdGhhdCwgaWYgeW91JiMzOTtyZSBpbnRlcmVz dGVkIGdldCBpbnZvbHZlZCB3aXRoIHRoZTxicj4NCnRvb2xzIHRlYW0uKSBJbiB0dXJuLCBJIHN1 c3BlY3QgdGhhdCBtZWFucyB0aGF0IHdnIGNoYWlycyBuZWVkPGJyPg0KdG8gbWFrZSBzdXJlIHRo ZXJlJiMzOTtzIGFuIGVkaXRvciB3aG8gcmVhbGx5IGdldHMgd2hlbiBhIGNoYW5nZSBuZWVkczxi cj4NCnRvIGJlIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBhbmQgd2hlbiBpdHMgb2sgdG8ganVzdCBm aXggYSB0eXBvLjxicj4NCjxicj4NClRoZSBodHRwYmlzIHdnIGhhdmUgc29tZSBleHBlcmllbmNl IGRvaW5nIHRoaXMgYnR3IGFuZCBoYXZlIGhpdDxicj4NCnRoYXQgc3BlY2lmaWMgaXNzdWUgb2Yg Y29tbWVudHMgYmVpbmcgbWFkZSBvbiBnaXRodWIgYnV0IG5vdCB0aGU8YnI+DQpsaXN0LiBUaGVy ZSYjMzk7cyBhIHJlY2VudCB0aHJlYWQgWzFdIHRoYXQgZW5kcyB3aXRoIGdvb2QgYWR2aWNlIGZy b208YnI+DQp0aGUgd2cgY2hhaXIuPGJyPg0KPGJyPg0KQW5kIGluIGNhc2Ugc29tZW9uZSBhc2tz LCByZWFzb25zIHdoeSB3ZSBuZWVkIHRoZSB3ZyBsaXN0IGNjJiMzOTtkPGJyPg0KaW5jbHVkZSBv cGVuLW5lc3MgYW5kIHRvIGJlIGNsZWFyIGFzIHRvIHdoYXQmIzM5O3MgYW4gSUVURjxicj4NCmNv bnRyaWJ1dGlvbi4gVGhlcmUmIzM5O3JlIHByb2JhYmx5IG1vcmUgYnV0IHRoZXNlIGFyZSBlbm91 Z2g7LSk8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KUy48YnI+DQo8YnI+DQpbMV0gPGEgaHJlZj0i aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvaWV0Zi1odHRwLXdnLzIwMTNBcHJK dW4vMDMzNC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vbGlzdHMudzMub3JnL0FyY2hp dmVzL1B1YmxpYy9pZXRmLWh0dHAtd2cvMjAxM0Fwckp1bi8wMzM0Lmh0bWw8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48YnI+DQomZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGRpdj48YnI+DQo8L2Rpdj4N Ci0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCjxkaXY+Q2hhaXJtYW4sIE9wZW5JRCBGb3Vu ZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPC9kaXY+DQo8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQoN Cg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+DQo= --14dae947303b88b76404dcd1df18-- From stephen.farrell@cs.tcd.ie Thu May 16 02:00:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BC421F8E3C for ; Thu, 16 May 2013 02:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id disQCufDRxnI for ; Thu, 16 May 2013 02:00:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72FD921F8E8E for ; Thu, 16 May 2013 02:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96937BE9F; Thu, 16 May 2013 10:00:16 +0100 (IST) 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 mdFcyxDTTBqw; Thu, 16 May 2013 10:00:11 +0100 (IST) Received: from [10.20.81.221] (outbound.ladiesgaelic.ie [86.47.217.115]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CD9E5BE98; Thu, 16 May 2013 10:00:09 +0100 (IST) Message-ID: <5194A019.20607@cs.tcd.ie> Date: Thu, 16 May 2013 10:00:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nat Sakimura References: <5190B512.6060903@cs.tcd.ie> <265449F1-D674-44CE-957B-204E765B6D15@mitre.org> <-2191260347151674055@unknownmsgid> In-Reply-To: <-2191260347151674055@unknownmsgid> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: oauth Subject: Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 09:00:56 -0000 Folks, please take generic discussion to the tools list. [1] That's where it'll have some effect. If you're only talking about what the oauth wg ought do that's fine, but this reads as more generic. Thanks, S. [1] https://www.ietf.org/mailman/listinfo/tools-discuss On 05/16/2013 09:44 AM, Nat Sakimura wrote: > I am by no means suggesting IETF to use Vim/emacs. That is counter > productive. I was merely pointing out that one has to decide the diff > policy wisely. > > I like XMLMind's XML2RFC. Too bad it became commercial product only. > > Intelligent diffs would work fine. However, there have been push back to > that since that made it difficult for the users that just look at the web. > > In IETF, we should take the rfcdiff, IMHO, so whitespace changes in XML > should not be an issue. > > Nat > > 2013/05/15 22:11、"Richer, Justin P." のメッセージ: > > I have already been using an approach like this for all of the drafts that > I edit, most notably the DynReg WG document and both the Introspection and > Chaining individual submissions. I run everything through my GitHub > repository here: > > https://github.com/jricher/oauth-spec/ > > I use the issue tracker there to note down things that come up in the WG > conversations on the list, so that when I actually do get to go edit > things, I don't forget anything. Once or twice, I have gotten issues > submitted directly to github, but the actual conversation around any real > changes (beyond typos) always comes back to the list. I do think it would > be worthwhile to connect the mailing list to the notifications of the > tracker for official documents. It would be fairly easy to set up a GitHub > organization that's backed by the mailing list's address for notifications, > and I think other development platforms have similar capabilities. > > However, I completely disagree with ODIF's decision regarding editing > tools. I've made some edits to the OIDF specs myself, and I find the "plain > text editor" rule to be a draconian overreaction that makes creating good > edits tedious, slow, and error-prone. In my personal experience, good tools > like XML Mind's XML2RFC plugin are profoundly useful, and the formatting > artifacts they create are minimal and easily ignored. The diffs that are > tracked in Git are *far* from useless, and if you ask me, if you want to do > a *real* diff on these documents you'd use the rfcdiff anyway, which > ignores the XML formatting changes and focuses on the actual content. It's > not perfect either, but it's far from useless. > > -- Justin > > > > On May 13, 2013, at 9:08 AM, Nat Sakimura > wrote: > > I am probably biased since I am the one who introduced ticket driven > version control to OIDF but it proved to be very valuable especially for > transparency purposes. Each changes are linked to the ticket so it is easy > to see why that change was made. > > As to the comments v.s. mailing list relationship is concerned, I think it > is possible to forward all the comments to the list, and in case of IETF, > it should do so. > > One feedback on the experience we had at OIDF is that XML Editing tools > changes all sort of formatting making the diff at bitbucket useless. So, we > had to resort to emacs/vim/ etc. > > my 2c. > > Nat Sakimura > > > > > 2013/5/13 Stephen Farrell > >> >> Hiya, >> >> On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: >>> Hi all, >>> the OpenID Connect had gained some experience with using version control >> systems >>> for editing specifications (and the use of issue trackers), see >>> http://openid.bitbucket.org/. Based on a recent discussion in the IETF >> (among >>> the working group chairs) I am wondering what your experience is with >> those >>> tools and whether you see value in using these tools for document >> editing in the >>> OAuth working group. >> >> Sounds like a fine plan if the wg want to try it. Only thing I'd >> note is that it means editors need to be *very* careful to bring >> discussion back to the wg list when that's needed, since you will >> likely get comments in the version control environment that are >> not cc'd to the wg list. (The IETF will be considering generic >> solutions for that, if you're interested get involved with the >> tools team.) In turn, I suspect that means that wg chairs need >> to make sure there's an editor who really gets when a change needs >> to be discussed on the list and when its ok to just fix a typo. >> >> The httpbis wg have some experience doing this btw and have hit >> that specific issue of comments being made on github but not the >> list. There's a recent thread [1] that ends with good advice from >> the wg chair. >> >> And in case someone asks, reasons why we need the wg list cc'd >> include open-ness and to be clear as to what's an IETF >> contribution. There're probably more but these are enough;-) >> >> Cheers, >> S. >> >> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html >> >> >> >>> 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 >> > > > > -- > 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 > From jricher@mitre.org Thu May 16 05:16:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C0E21F9223 for ; Thu, 16 May 2013 05:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPt-JJ3GGP5l for ; Thu, 16 May 2013 05:16:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0BB621F9227 for ; Thu, 16 May 2013 05:16:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E382622602D8; Thu, 16 May 2013 08:16:10 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C416D22602D5; Thu, 16 May 2013 08:16:10 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Thu, 16 May 2013 08:16:10 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUasmqYhOH+9Tj0KmdipKXhmNOA== Date: Thu, 16 May 2013 12:16:10 +0000 Message-ID: <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.6.125] Content-Type: multipart/alternative; boundary="_000_8EFC75650E8146889AEB459E7503F609mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 12:16:18 -0000 --_000_8EFC75650E8146889AEB459E7503F609mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBNYXkgMTUsIDIwMTMsIGF0IDEwOjMwIFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQogd3JvdGU6DQoNCk9uIDIwMTMt MDUtMTUsIGF0IDU6NTMgUE0sIFJpY2hlciwgSnVzdGluIFAuIHdyb3RlOg0KDQpQaGlsLCBtYW55 IHRoYW5rcyBmb3IgdGhlIGV4dHJlbWVseSB0aG9yb3VnaCByZXZpZXchIEl0IGlzIHZlcnkgdXNl ZnVsIGluZGVlZC4NCg0KTXkgY29tbWVudHMgYW5kIHJlc3BvbnNlcyB0byBlYWNoIHBvaW50IGFy ZSBpbmxpbmUuDQoNCk9uIE1heSAxNSwgMjAxMywgYXQgNDozMCBQTSwgUGhpbCBIdW50IDxwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0K SXQgc2VlbXMgdW5mb3J0dW5hdGUgdGhhdCBJIGhhdmUgbm90IGdvdHRlbiBhIGNoYW5jZSB0byBn ZXQgaW50byB0aGlzIGxldmVsIG9mIGRldGFpbCBtdWNoIGVhcmxpZXIuIEJ1dCB0aGVuLCBJIGd1 ZXNzIHRoYXQncyB3aGF0IExDIHJldmlldyBpcyBmb3IhIE15IGFwb2xvZ2llcyBmb3Igbm90IGdl dHRpbmcgbWFueSBvZiB0aGVzZSBjb25jZXJucyB0byB0aGUgV0cgbXVjaCBlYXJsaWVyLg0KDQpP dmVyYWxsDQotLS0tLS0tLS0tLQ0KSSB0aGluayBkeW5hbWljIHJlZ2lzdHJhdGlvbiBpcyBhIGNy aXRpY2FsIHBhcnQgb2YgdGhlIE9BdXRoIGZyYW1ld29yayBub3cgdGhhdCB3ZSBhcmUgc3RhcnRp bmcgdG8gY29uc2lkZXIgaG93IGluZGl2aWR1YWwgY2xpZW50IGFwcGxpY2F0aW9ucyBzaG91bGQg b3BlcmF0ZSB3aGVuIHRoZXJlIGlzIG9uZSBvciBtb3JlIGRlcGxveW1lbnRzIG9mIGEgcGFydGlj dWxhciByZXNvdXJjZSBBUEkuIFdlJ3ZlIG1vdmVkIGZyb20gdGhlIHNpbXBsZSB1c2UgY2FzZSBv ZiBhIHNpbmdsZSBBUEkgcHJvdmlkZXIgbGlrZSBGYWNlYm9vayBvciBGbGlja3IgYW5kIG1vdmVk IG9uIHRvIHN0YW5kYXJkcyBiYXNlZCwgb3BlbiBzb3VyY2UgYmFzZWQsIGFuZCBjb21tZXJjaWFs IGJhc2VkIGRlcGxveW1lbnRzIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBzZXJ2aWNlIGVuZHBv aW50cyBhbmQgbWFueSBjbGllbnRzIHRvIG1hbmFnZS4NCg0KVGhlIGR5bmFtaWMgcmVnaXN0cmF0 aW9uIHNwZWMgaXMgYWN0dWFsbHkgZGVhbGluZyB3aXRoIGEgY291cGxlIG9mIGlzc3VlcyB0aGF0 IEkgd291bGQgbGlrZSB0byBzZWUgbWFkZSBtb3JlIGNsZWFyIGluIGVhcmx5IHBhcnQgb2YgdGhl IHNwZWM6DQoNCjEuICBIb3cgaXMgYSBuZXcgY2xpZW50IGFwcGxpY2F0aW9uIHJlY29nbml6ZWQg Zm9yIHRoZSBmaXJzdCB0aW1lIHdoZW4gZGVwbG95ZWQgYWdhaW5zdCBhIHBhcnRpY3VsYXIgU1Ag ZW5kcG9pbnQ/ICBTaG91bGQgY2xpZW50cyBhY3R1YWxseSBhc3NlcnQgYW4gYXBwbGljYXRpb25f aWQgVVVJRCB0aGF0IG5ldmVyIGNoYW5nZXMgYW5kIHBvc3NpYmx5IGEgdmVyc2lvbiBpZCB0aGF0 IGRvZXMgY2hhbmdlIHdpdGggdmVyc2lvbnM/DQoNCkluIHRoZSBnZW5lcmFsIGNhc2UsIHdoeSBp cyBhbnkgcmVjb2duaXRpb24gcmVxdWlyZWQ/IElmIHlvdSdyZSBkb2luZyB0aGluZ3MgYXMgcGFy dCBvZiBhIGxhcmdlciBwcm90b2NvbCBlY29zeXN0ZW0sIGxpa2UgQmx1ZSBCdXR0b24rIG9yIGEg cGFydGljdWxhciBPcGVuSUQgQ29ubmVjdCBwcm92aWRlciwgdGhlbiB5b3UgY2FuIGRlZmluZSBz ZW1hbnRpY3MgZm9yIHR5aW5nIHRvZ2V0aGVyIGNsYXNzZXMgb2YgY2xpZW50cyAoc2VlIGJlbG93 IGZvciBtb3JlIGRpc2N1c3Npb24gb24gdGhpcyB2ZXJ5IHBvaW50KS4gQnV0IGluIGdlbmVyYWws IGEgY2xpZW50IGlzIGp1c3QgZ29pbmcgdG8gc2hvdyB1cCBhcyBhIG5ldyBpbnN0YW5jZSB0byB0 aGUgQVMgYW5kIGdldCBpc3N1ZWQgYSBuZXcsIHVuaXF1ZSBjbGllbnRfaWQsIGFuZCB0aGF0J3Mg dGhhdC4NCg0KSSB0aGluayB3ZSBoYXZlIHRvIGRlZmluZSBtb3JlIGNsZWFybHkgd2hhdCBhbiAi aW5zdGFuY2UiIGlzLiBGb3IgbWUsIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgYW5kIHRoZXJlIGFy ZSBpbnN0YW5jZXMgb2YgdGhhdCBhcHBsaWNhdGlvbi4gIEl0IGlzIHVzZWZ1bCB0byB1bmRlcnN0 YW5kIHRoYXQgYSBjbGllbnQgYXBwbGljYXRpb24gcmVwcmVzZW50cyBhIHNldCBvZiBjb2RlIHRo YXQgc2hvdWxkIGJlaGF2ZSBpbiBhIGNvbnNpc3RlbnQgd2F5LiAgSXQgc2VlbXMgdG8gbWUgdGhl IGZpcnN0IHRpbWUgYSBuZXcgYXBwbGljYXRpb24gc2hvd3MgdXAgaXMgdmVyeSBkaWZmZXJlbnQg ZnJvbSB0aGUgc3Vic2VxdWVudCBpbnN0YW5jZXMgdGhhdCByZWdpc3Rlci4gRm9yIGV4YW1wbGUs IGFmdGVyIHRoZSBmaXJzdCByZWdpc3RyYXRpb24sIHN1YnNlcXVlbnQgaW5zdGFuY2VzIGRvbid0 IG5lZWQgc3BlY2lhbCByZXZpZXcgb3IgYXBwcm92YWwgdG8gdGhlIHNhbWUgZGVncmVlLg0KDQpC dXQgd2l0aG91dCBvdGhlciBtZWNoYW5pc21zIHRvIHRpZSB0aGluZ3MgdG9nZXRoZXIsIHRoZXJl J3Mgbm8gd2F5IGZvciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBrbm93IGlmIGFueSBjbGll bnQgaW5zdGFuY2UgaXMgdGllZCB0byBhbnkgb3RoZXIgY2xpZW50IGluc3RhbmNlLiBUaGVyZWZv cmUsIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGFuIEFTLCB0aGUgZmlyc3QgaW5zdGFuY2Ugb2Yg YW4gYXBwbGljYXRpb24gKGkuZS4sIHBhcnRpY3VsYXIgY29uZmlndXJhdGlvbiBvZiBhIHNldCBv ZiBjb2RlKSB0byByZWdpc3RlciBpcyBubyBkaWZmZXJlbnQgdG8gc3Vic2VxdWVudCBpbnN0YW5j ZXMgb2YgdGhhdCBzYW1lIGFwcGxpY2F0aW9uLiBIb3cgd2VyZSB5b3UgZW52aXNpb25pbmcgYW4g QVMga25vd2luZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBmaXJzdCBhbmQgc3Vic2VxdWVu dCBpbnN0YW5jZXMgb2YgYW4gYXBwbGljYXRpb24sIHNwZWNpZmljYWxseT8gSWYgdGhlcmUncyBh biAiYXBwbGljYXRpb25faWQiIGxpa2UgeW91IG1lbnRpb24gYWJvdmUsIEkgdGhpbmsgaXQgcmFp c2VzIG1vcmUgcXVlc3Rpb25zIHRoYW4gaXQgcmVzb2x2ZXM6IFdobyBpc3N1ZXMgdGhlIGFwcGxp Y2F0aW9uX2lkLCBzb21lIHNlcnZlciBvciB0aGUgYXBwbGljYXRpb24gaXRzZWxmPyBJcyBpdCB2 YWxpZGF0ZWQgYXQgYWxsPyBTaG91bGQgaXQgYmUgY29uc2lkZXJlZCBzZWNyZXQ/IFdoYXQgaGFw cGVucyB3aGVuIHNvbWVvbmUgc2ltcGx5IHN0ZWFscyBhbiBhcHBsaWNhdGlvbl9pZD8gRG9lcyBh biBBUyBoYXZlIHRvIGRvIGFueXRoaW5nIHRvIGNoZWNrIHdpdGggYW55IG90aGVyIEFTIHRvIHNl ZSBpZiB0aGUgYXBwbGljYXRpb25faWQgaGFzIGFscmVhZHkgYmVlbiB1c2VkIGVsc2V3aGVyZT8N Cg0KSSBkbyBhZ3JlZSB0aGF0IGEgZGlzY3Vzc2lvbiBvZiAiaW5zdGFuY2UgdnMuIGFwcGxpY2F0 aW9uIiB3b3VsZCBiZSBoZWxwZnVsIGluIGNsZWFyaW5nIHRoaXMgdXAsIEknbGwgbWFrZSBhIG5v dGUgdG8gYWRkIHRleHQgdG8gdGhhdCBlZmZlY3QuIChXZSBoYWQgdG8gZG8gc29tZXRoaW5nIHNp bWlsYXIgZm9yIEJCKykNCg0KDQoNCjIuICBIb3cgYXJlIGNsaWVudCBjcmVkZW50aWFscyBtYW5h Z2VkLiBBcmUgd2UgYXNzdW1pbmcgY2xpZW50IGNyZWRlbnRpYWxzIGhhdmUgYSBsaW1pdGVkIGxp ZmV0aW1lIG9yIHJvdGF0aW9uIHBvbGljeT8NCg0KVGhlIGludGVudCB3YXMgdGhhdCBjbGllbnRf c2VjcmV0IGNvdWxkIGJlIHJvdGF0ZWQsIGFzIGluZGljYXRlZCBieSB0aGUgZXhwaXJlc19hdCBt ZW1iZXIgb2YgdGhlIHJlc3BvbnNlLiBJZiBhIGNsaWVudCdzIHNlY3JldCBleHBpcmVzLCBpdCBj YWxscyB0aGUgcmVhZCBvcGVyYXRpb24gb24gdGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBv aW50ICjCpzQuMikgdG8gZ2V0IGl0cyBuZXcgY2xpZW50X3NlY3JldC4gSWYgdGhpcyBpcyB1bmNs ZWFyIGluIHRoZSBjdXJyZW50IHRleHQgKHdoaWNoIEkgc3VzcGVjdCBpdCBtYXkgYmUgYWZ0ZXIg bXVsdGlwbGUgcmVmYWN0b3JpbmdzKSwgdGhlbiBJIHdlbGNvbWUgc3VnZ2VzdGlvbnMgYW5kIHNw ZWNpZmljIHRleHQgYXMgdG8gaG93IHRvIG1ha2UgdGhhdCBjbGVhci4NClNvbWV0aGluZyBsaWtl IHRoaXMgc2hvdWxkIGJlIGluIHRoZSBkcmFmdC4NCg0KU2hvdWxkIHRoaXMgYmUgdXAgaW4gdGhl IGludHJvZHVjdG9yeSB0ZXh0LCBzb21ld2hlcmUgZWxzZSwgb3IgaGF2ZSBpdHMgb3duIHNlY3Rp b24/DQoNCg0KICBIb3cgZG9lcyBhIGNsaWVudCBhdXRoZW50aWNhdGUgdGhlIGZpcnN0IHRpbWUg YW5kIHN1YnNlcXVlbnQgdGltZXMgdG8gdGhlIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlPw0KDQpUaGlz IGlzIGEgc2VwYXJhdGUgcXVlc3Rpb24gYWxsIHRvZ2V0aGVyLCBhcyBpdCBkb2VzIG5vdCBpbnZv bHZlIHRoZSBjbGllbnRfc2VjcmV0IG9yIGNsaWVudF9pZCBhdCBhbGwuIFJhdGhlciwgdGhlIGZp cnN0IHRpbWUgdGhlIGNsaWVudCBzaG93cyB1cCB0byB0aGUgcmVnaXN0cmF0aW9uIHNlcnZpY2Us IGl0IG1heSBlaXRoZXI6DQogIC0gTm90IGF1dGhlbnRpY2F0ZSBhdCBhbGwgKHRoaXMgaXMgdGhl IHRydWUgcHVibGljLCBvcGVuIHJlZ2lzdHJhdGlvbiwgYW5kIGl0IGlzIHJlY29tbWVuZGVkIHRo YXQgc2VydmVycyBkbyB0aGlzKQ0KIC0gQXV0aGVudGljYXRlIHVzaW5nIGFuIE9BdXRoIDIuMCB0 b2tlbiAod2hpY2ggQVRNIG1lYW5zIGEgYmVhcmVyIHRva2VuKS4gSG93IHRoZSBjbGllbnQgZ2V0 cyB0aGF0IGJlYXJlciB0b2tlbiBhbmQgd2hhdCB0aGUgYmVhcmVyIHRva2VuIG1lYW5zIHRvIHRo ZSBBUyBiZXlvbmQgInRoaXMgY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gcmVnaXN0ZXIiIGlzIG91 dCBvZiBzY29wZSBmb3IgdGhlIHNwZWMsIGJ5IGRlc2lnbi4NCg0KU3Vic2VxdWVudCB0aW1lcyB0 aGF0IHRoZSBzYW1lIHJlZ2lzdGVyZWQgY2xpZW50IChieSB3aGljaCB3ZSBtZWFuIHRoZSBzYW1l IGluc3RhbmNlIG9mIGEgY2xpZW50IHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVudF9pZCkgc2hvd3Mg dXAgYXQgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCAoYWN0dWFsbHksIHRoZSBDbGllbnQgQ29u ZmlndXJhdGlvbiBFbmRwb2ludCksIGl0IHVzZXMgaXRzIFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9r ZW4gdGhhdCBpdCB3YXMgaXNzdWVkIG9uIGluaXRpYWwgcmVnaXN0cmF0aW9uLiBUaGlzIGlzIGFu IE9BdXRoIDIuMCBCZWFyZXIgdG9rZW4gdGhhdCBpcyB1bmlxdWUgdG8gdGhlIGNsaWVudCBpbnN0 YW5jZS4NCg0KU29tZXRoaW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgaW4gdGhlIGRyYWZ0Lg0KDQpP SywgdGhlIGRlZmluaXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gY2FuIGJl IGV4cGFuZGVkLCBidXQgSSB0aGluayB0aGF0IHRoZSByZXN0IG9mIGl0IGlzIGFscmVhZHkgaW4g dGhlcmUgaW4gwqczLiBJJ2Qgd2VsY29tZSBzdWdnZXN0aW9ucyBvbiB3aGljaCBiaXRzIG9mIHRo aXMgY291bGQgYmUgbWFkZSBjbGVhcmVyLg0KDQoNCg0KMy4gIEhvdyBpcyB2ZXJzaW9uaW5nIG9m IGNsaWVudHMgbWFuYWdlZD8gU2hvdWxkIGVhY2ggbmV3IHZlcnNpb24gb2YgYSBjbGllbnQgcmVx dWlyZSBhIGNoYW5nZSBpbiBjbGllbnQgcmVnaXN0cmF0aW9uIGluY2x1ZGluZyBwb3NzaWJseSBj aGFuZ2luZyBjbGllbnRfaWQgYW5kIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWw/IEkgZG9uJ3Qg aGF2ZSBhIHN0cm9uZyBmZWVsaW5nLCBidXQgaXQgaXMgc29tZXRoaW5nIHRoYXQgaW1wbGVtZW50 b3JzIHNob3VsZCBjb25zaWRlci4NCg0KVGhpcyBpcyB1cCB0byB0aGUgQVMsIHJlYWxseSwgYW5k IEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnkgZ2xvYmFsIHBvbGljeSB3b3VsZCBldmVyIGZseSBoZXJl LiBFc3BlY2lhbGx5IGlmIHlvdSBjb25zaWRlciB0aGF0IHRoZSBlbnRpcmUgbm90aW9uIG9mICJ2 ZXJzaW9uIiBpcyBtb3JlIGZsdWlkIHRoZXNlIGRheXMgdGhhbiBpdCBldmVyIGhhcyBiZWVuLiBJ IHdvdWxkbid0IG1pbmQgYWRkaW5nIGEgZGlzY3Vzc2lvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgaWYgaXQgbWVyaXRzIG1lbnRpb25pbmcgdGhvdWdoLCBzbyB0aGF0IHdlIGNhbiBo ZWxwIGJvdGggY2xpZW50IGRldmVsb3BlcnMgYW5kIHNlcnZlciBkZXZlbG9wZXJzIGluc3RpdHV0 ZSByZWFzb25hYmx5IGdvb2QgcG9saWN5Lg0KDQpJIGd1ZXNzIHRoZSBpc3N1ZSBpcyB0aGF0IHdo ZW4gYSBjbGllbnQgdXBncmFkZXMgaXQgbWF5IGhhdmUgYWNjZXNzIHRvIHRoZSBvbGQgY3JlZGVu dGlhbHMuIFdoYXQgaXMgdGhlIGludGVudCB0aGVuIG9mIHJlZ2lzdHJhdGlvbi4gIFNpbmNlIHlv dSBoYXZlIGFuIHVwZGF0ZSBhcmUgY2xpZW50cyBleHBlY3RlZCB0byB1cGRhdGUgL3JlLXJlZ2lz dGVyIG9yIG5vdD8gIEknbSBub3Qgc3VyZSB0aGlzIGlzIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlv biBidXQgbW9yZSBwYXJ0IG9mIHRoZSB3aG9sZSBjaGFuZ2UgbWFuYWdlbWVudCBmdW5jdGlvbiBk eW5hbWljIHJlZ2lzdHJhdGlvbiBzdXBwb3J0cy4NCg0KSWYgeW91ciB1cGdyYWRlZCB2ZXJzaW9u IG9mIHRoZSBjbGllbnQgc3RpbGwgaGFzIGFjY2VzcyB0byBpdHMgb2xkIGNyZWRlbnRpYWxzLCB3 aHkgd291bGRuJ3QgaXQganVzdCB1c2UgdGhvc2U/IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIGZvciBm b3JjaW5nIGEgcmUtcmVnaXN0cmF0aW9uLiBOb3IgZG8gSSBzZWUgYW55IHdheSB0aGF0IGFuIEFT IHdvdWxkIGV2ZW4gYmUgYWJsZSB0byB0ZWxsIHRoYXQgYSBjbGllbnQgaGFkIGJlZW4gdXBncmFk ZWQuIEFuIHVwZ3JhZGVkIGNsaWVudCBhbHdheXMgaGFzIHRoZSAqb3B0aW9uKiBvZiByZS1yZWdp c3RlcmluZyBpdHNlbGYgYW5kIGdldHRpbmcgYSBuZXcgY2xpZW50X2lkLg0KDQoNCg0KNC4gIFdo YXQgaXMgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4/IFdoeSBpcyBpcyB1c2VkPyBXaGF0 IGlzIGl0cyBsaWZlLWN5Y2xlPyAgV2hlbiBpcyBpdCBpc3N1ZWQsIHdoZW4gaXMgaXQgY2hhbmdl ZD8gV2hlbiBpcyBpdCBkZWxldGVkPw0KDQpTZWUgdGhlIHJlc3BvbnNlIGFib3ZlIGFib3ZlIGFu ZCB0aGUgZGVmaW5pdGlvbiBpbiDCpzEuMjoNCg0KUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjog QW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBpc3N1ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2Vy dmVyIHRocm91Z2ggdGhlIENsaWVudCBSZWdpc3RyYXRpb24gRW5kcG9pbnQgd2hpY2ggaXMgdXNl ZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgZHVyaW5nIHJlYWQsIHVwZGF0 ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiBUaGlzIHRva2VuIGlzIGFzc29jaWF0ZWQgd2l0aCBh IHBhcnRpY3VsYXIgQ2xpZW50Lg0KDQpJZiB0aGlzIGNhbiBiZSBjbGFyaWZpZWQsIEkgd2VsY29t ZSB0ZXh0IHN1Z2dlc3Rpb25zLg0KDQpUaGUgbGF0dGVyIHBhcnQgb2YgMS4yIGRpZG4ndCBzZWVt IGxpa2UgdGVybWlub2xvZ3kgYnV0IHJhdGhlciBhcmNoaXRlY3R1cmUgb3IgcGFydCBvZiB0aGUg aW50cm9kdWN0aW9uIHRoYXQgZGVzY3JpYmVzIHdoYXQgdGhlIHNwZWMgZG9lcy4gVGhlIHRoaXJk IHBvaW50IGRvZXNuJ3Qgc2VlbSB0byBmaXQgd2l0aCB0aGUgb3RoZXIgdHdvIGV4Y2VwdCB0byBz YXkgdGhhdCB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gZW5kcG9pbnRzIHVzZSB0aGVpciBvd24g YWNjZXNzIHRva2VucyBjYWxsZWQgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbnMuDQoNCg0KQ2xp ZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIuMCBFbmRwb2ludCB0aHJvdWdo IHdoaWNoDQogICAgICBhIENsaWVudCBjYW4gcmVxdWVzdCBuZXcgcmVnaXN0cmF0aW9uLiAgVGhl IG1lYW5zIG9mIHRoZSBDbGllbnQNCiAgICAgIG9idGFpbmluZyB0aGUgVVJMIGZvciB0aGlzIGVu ZHBvaW50IGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMNCiAgICAgIHNwZWNpZmljYXRpb24uDQoN CiAgIG8gIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50OiBUaGUgT0F1dGggMi4wIEVuZHBv aW50IHRocm91Z2gNCiAgICAgIHdoaWNoIGEgc3BlY2lmaWMgQ2xpZW50IGNhbiBtYW5hZ2UgaXRz IHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiwNCiAgICAgIHByb3ZpZGVkIGJ5IHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciB0byB0aGUgQ2xpZW50LiAgVGhpcyBVUkwgZm9yDQogICAgICB0aGlzIGVu ZHBvaW50IGlzIGNvbW11bmljYXRlZCB0byB0aGUgY2xpZW50IGJ5IHRoZSBBdXRob3JpemF0aW9u DQogICAgICBTZXJ2ZXIgaW4gdGhlIENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25zZS4NCg0KICAg byAgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjogQW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBp c3N1ZWQgYnkgdGhlDQogICAgICBBdXRob3JpemF0aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGll bnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50DQogICAgICB3aGljaCBpcyB1c2VkIGJ5IHRoZSBDbGll bnQgdG8gYXV0aGVudGljYXRlIGl0c2VsZiBkdXJpbmcgcmVhZCwNCiAgICAgIHVwZGF0ZSwgYW5k IGRlbGV0ZSBvcGVyYXRpb25zLiAgVGhpcyB0b2tlbiBpcyBhc3NvY2lhdGVkIHdpdGggYQ0KICAg ICAgcGFydGljdWxhciBDbGllbnQuDQoNCg0KVGhpcyBzZWN0aW9uIGlzIG1lYW50IHRvIGp1c3Qg aW50cm9kdWNlIHRoZSBuZXcgdGVybXMgdGhhdCBhcmUgdGhlbiBleHBsYWluZWQgaW4gZ3JlYXRl ciBkZXRhaWwgdGhyb3VnaG91dCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuIFllcywgaXQncyBh IGJpdCBhcmNoaXRlY3R1cmUsIGJ1dCBvbmx5IGluIHRoZSBzZW5zZSB0aGF0IHlvdSBuZWVkIHRv IGRlZmluZSB0aGUgdGVybXMgdGhhdCBtYWtlIHVwIHlvdXIgYXJjaGl0ZWN0dXJlLiBIb3cgd291 bGQgeW91IHN1Z2dlc3QgdGhhdCBpdCBjaGFuZ2U/DQoNCg0KDQoNCklmIHdlIGRpc3Rpbmd1aXNo IGJldHdlZW4gZmlyc3QgdGltZSByZWdpc3RyYXRpb24gb2YgYSBwYXJ0aWN1bGFyIGNsaWVudCBz b2Z0d2FyZSBwYWNrYWdlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWV0aGluZ3MgbGlrZSBhdXRo ZW50aWNhdGlvbiBtZXRob2QgY2FuIGJlIG5lZ290aWF0ZSBpbiBvciBvdXQtb2YtYmFuZCBhdCB0 aGF0IHRpbWUuIFN1YnNlcXVlbnQgcmVnaXN0cmF0aW9ucyBzaG91bGQgb25seSBoYXZlIHBhcmFt ZXRlcnMgZm9yIGl0ZW1zIHRoYXQgY291bGQgY2hhbmdlIHBlciBkZXBsb3ltZW50IChsaWtlIHRv c191cmkpLiAgSSB0aGluayB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCBpcyBvbmUgdGhpbmcg dGhhdCBzaG91bGQgbm90IGJlIG5lZ290aWF0ZWQgcGVyIGluc3RhbmNlLg0KDQpXaGVuIHN1YnNl cXVlbnQgaW5zdGFuY2VzIHJlZ2lzdGVyLCBJIGhhdmUgdG8gYXNrIHRoZSBxdWVzdGlvbiwgZm9y IGV4YW1wbGUgd2hlbiB3b3VsZCB0aGluZ3MgbGlrZSAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRo b2QiIGJlIG5lZ290aWF0ZWQgb3IgYmUgZGlmZmVyZW50IGZvciB0aGUgc2FtZSBjbGllbnQgc29m dHdhcmU/IFNob3VsZCBub3QgYWxsIGluc3RhbmNlcyB1c2UgdGhlIHNhbWUgYXV0aGVudGljYXRp b24gbWV0aG9kLg0KDQpJJ20gY29uZnVzZWQgYnkgdGhpcyAtLSBhcyBmYXIgYXMgdGhlIGR5bmFt aWMgcmVnaXN0cmF0aW9uIHNwZWMgaXMgY29uY2VybmVkLCBhbGwgaW5zdGFuY2VzIGFyZSBzZXBh cmF0ZSBmcm9tIGVhY2ggb3RoZXIuIEFsbCBwYXJhbWV0ZXJzIGNoYW5nZSBwZXIgaW5zdGFuY2Uu IEFuZCBpbnN0YW5jZSwgeW91IHNob3VsZCBrZWVwIGluIG1pbmQsIGlzIGRlZmluZWQgYXMgYW55 IG9uZSBjb3B5IG9mIHRoZSBjbGllbnQgY29kZSBjb25uZWN0aW5nIHRvIGFueSBuZXcgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuIFRoYXQgcGFpcmluZyBjcmVhdGVzIHRoZSBjbGllbnRfaWQsIGFuZCB0 aGVyZWZvcmUgdGhlIGluc3RhbmNlLCBhbmQgdGhlcmVmb3JlIHRoZSByZWdpc3RyYXRpb24gYWNj ZXNzIHRva2VuLCBhbmQgdGhlcmVmb3JlIHRoZSByZWdpc3RyYXRpb24gaXRzZWxmIGF0IGEgY29u Y2VwdHVhbCBsZXZlbC4gU28gdGhlcmUgaXMgbm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNl IGZvciBhIGNsaWVudCB0byBhc2sgZm9yIGEgcGFydGljdWxhciB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZC4gV2hlcmUgZWxzZSB3b3VsZCB0aGUgQVMgZmluZCBvdXQgYWJvdXQgaXQ/DQoNCldl IHN0aWxsIGRpc2FncmVlIG9uIHRoaXMuIEl0IGlzIG15IGFzc2VydGlvbiB0aGF0IGNsaWVudHMg c2hvdWxkIE5FVkVSIGFzayBmb3IgYSBwYXJ0aWN1bGFyIHRva2VuIGF1dGggbWV0aG9kLiBTaW5j ZSBpdCBpcyB0aGUgQVMgdGhhdCBpcyBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LCB0aGVuIGl0 IGlzIHRoZSBBUydzIHJpZ2h0IHRvIHNldCB0aGUgYXV0aGVudGljYXRpb24gcG9saWN5LiAgVGhl IHJvbGUgb2YgZHluYW1pYyByZWcgZW5kcG9pbnQgaXMgdG8gaW5mb3JtIHRoZSBjbGllbnQgd2hh dCBpdCBtdXN0IGRvLiAgTXkgYXNzdW1wdGlvbiBpcyB0aGF0IGR1cmluZyB0aGUgZmlyc3QgdGlt ZSBhIHBpZWNlIG9mIHNvZnR3YXJlIGlzIHJlZ2lzdGVyZWQgKHRoZSBmaXJzdCBpbnN0YW5jZSks IHRoZXJlIGNvdWxkIGJlIHNvbWUgT09CIGRpc2N1c3Npb24gYnkgYW4gYWRtaW5pc3RyYXRvciB0 byBhcHByb3ZlIHRoZSBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0aW9uIHR5cGUgZm9yIHRoZSBBUyBp biBxdWVzdGlvbi4NCg0KSSBoYXZlbid0IGhlYXJkIGEgcmVhc29uIGp1c3RpZnlpbmcgdGhpcyBw YXJhbWV0ZXIgb3RoZXIgdGhlbiAiaXQgaXMgbmVlZGVkIi4gIFdoeT8NCg0KVGhlIHJvbGUgb2Yg dGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHByb3RvY29sIGlzIHR3b2ZvbGQ6IGhhbGYgb2YgdGhh dCBpcyB0aGUgc2VydmVyIGluZm9ybWluZyB0aGUgY2xpZW50IHdoYXQgaXQgbXVzdCBkby4gQnV0 IHRoZSBvdGhlciBoYWxmIGlzIHRoZSBjbGllbnQgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIgd2hhdCBp dCAqY2FuKiBkbywgb3Igd2hhdCBpdCAqd2FudHMqIHRvIGRvLg0KDQpBbmQgYWdhaW4sIHRoZXJl J3Mgbm8gd2F5IHRvIGRpc3Rpbmd1aXNoIGEgZmlyc3QgaW5zdGFuY2UgZnJvbSBhIHN1YnNlcXVl bnQgaW5zdGFuY2UgdW5sZXNzIHlvdSdyZSBkb2luZyBzb21ldGhpbmcgaW4gYWRkaXRpb24uIE5v dGhpbmcgaXMgc3RvcHBpbmcgdGhlIHNhbWUgYXBwbGljYXRpb24gZnJvbSByZWdpc3RlcmluZyBh IG5ldyBpbnN0YW5jZSBvZiBpdHNlbGYgZm9yIGV2ZXJ5IHNpbmdsZSB1c2VyIG9yIGV2ZXJ5IHNp bmdsZSB0b2tlbiB0aGF0IGl0IHdhbnRzIHRvIGdldCBhY2Nlc3MgZm9yLiBUaGF0J3MgY29tcGxp Y2F0ZWQgYW5kIHdhc3RlZnVsIGFuZCBub3QgYSBncmVhdCBpZGVhLCBzdXJlLCBidXQgIHRoZXJl J3Mgbm8gdXNlZnVsIHdheSB0byBwcmV2ZW50IHRoYXQga2luZCBvZiBiZWhhdmlvciBpZiB5b3Ug YWxzbyB3YW50IG9wZW4gcmVnaXN0cmF0aW9uIG9mIGNsaWVudHMuDQoNCg0KQW5kIHRoZXJlJ3Mg bm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNlIGZvciB0aGUgc2VydmVyIHRvIHRlbGwgdGhl IGNsaWVudCB3aGljaCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCB0byB1c2UuIEFsbCBpbnN0 YW5jZXMgd2lsbCBwcm9iYWJseSBhc2sgZm9yIHRoZSBzYW1lIHRva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kIGZyb20gYWxsIGF1dGggc2VydmVycyB0aGV5IHRhbGsgdG8sIHJpZ2h0PyBBbmQgZWFj aCBBUyB3aWxsIHRlbGwgZWFjaCBpbnN0YW5jZSB0aGF0IHJlZ2lzdGVycyB3aXRoIGl0IHRvIHVz ZSBhIHBhcnRpY3VsYXIgYXV0aCBtZXRob2QuIFRoZXJlIGlzIG5vIHdheSB0byB0aWUgdG9nZXRo ZXIgZGlmZmVyZW50IGluc3RhbmNlcyBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0aCBzZXJ2ZXJzIHdp dGhvdXQgc3BlY2lmeWluZyBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBvdGhlciBtYWNoaW5lcnku DQoNCldoaWNoIGlzIG5vdCB0byBzYXkgdGhhdCBpdCdzIG5vdCB1c2VmdWwgaW4gc29tZSBjaXJj dW1zdGFuY2VzIHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIG9mIHRoZSBzYW1l IGNvZGUgYWNyb3NzIChvciB3aXRoaW4pIGF1dGggc2VydmVycy4gVGhpcyBpcyB3aHksIHdpdGgg Qmx1ZSBCdXR0b24rLCB3ZSBzcGVjaWZpZWQgYSBzcGVjaWZpYyB0b2tlbiBmb3JtYXQgZm9yIHRo ZSBpbml0aWFsIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBjbGllbnRzIHVzZSB0byBjYWxsIHRoZSBy ZWdpc3RyYXRpb24gZW5kcG9pbnQgdGhlIGZpcnN0IHRpbWUsICBhcyB3ZWxsIGFzIGEgZGlzY292 ZXJ5IHByb3RvY29sIGFnYWluc3QgYSBjZW50cmFsaXplZCBzZXJ2ZXIgdGhhdCBoYW5kbGVzIHBy ZS1yZWdpc3RyYXRpb24uIEFsbCBvZiB0aGlzIG1hY2hpbmVyeSBpcywgaW4gbXkgb3Bpbmlvbiwg YSBzdHVwZW5kb3VzIG92ZXJraWxsIGZvciB0aGUgZ2VuZXJhbCBjYXNlLCB0aG91Z2ggaWYgc29t ZSBmb2xrcyBmaW5kIHVzZSBmb3IgaXQgb3V0c2lkZSBvZiBCQisgdGhlbiBpdCdkIGJlIGEgZ29v ZCB0aGluZyB0byBhYnN0cmFjdCBvdXQgYW5kIG1ha2UgaXRzIG93biBzcGVjIHRoYXQgZXh0ZW5k cyB0aGUgRHluIFJlZyBzcGVjIGluIGEgZnVsbHkgY29tcGF0aWJsZSB3YXkuIEZ1cnRoZXJtb3Jl LCBldmVuIGluIEJsdWUgQnV0dG9uKyB3ZSBzcGVjaWZ5IHRoYXQgYWxsIGF1dGggc2VydmVycyBN VVNUIGFsc28gYWNjZXB0IG9wZW4gcmVnaXN0cmF0aW9uLCB3aXRob3V0IGFuIGluaXRpYWwgYWNj ZXNzIHRva2VuLCB3aGVyZSB0aGUgY2xpZW50IHNpbXBseSBzaG93cyB1cCBhbmQgc2F5cyAiaGV5 LCBoZXJlIGFyZSBteSBwYXJhbWV0ZXJzLiIgVGhlIGF1dGggc2VydmVyIGhhcyBubyB3YXkgdG8g a25vdyBpbiB0aGlzIGNhc2UgYW55IGtpbmQgb2Ygb3V0LW9mLWJhbmQgbmVnb3RpYXRpb24gZm9y IGRpZmZlcmVudCB0aGluZ3MuIEluIEJCKyB3ZSBhcmUgd3JpdGluZyB2ZXJ5IHNwZWNpZmljIHBv bGljeSBndWlkZWxpbmVzIGFib3V0IGhvdyB0byBwcmVzZW50IHRoZSBVWCBhbmQgdGhpbmdzIHRv IHRoZSBlbmQgdXNlciBmb3IgYWxsIG9mIHRoZXNlIGRpZmZlcmVudCBjYXNlcy4gQnV0IGFnYWlu LCBhbGwgb2YgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUgQkIrIHVzZSBjYXNlLCBhbmQgSSBkb24n dCBzZWUgdmFsdWUgaW4gZHJhZ2dpbmcgaXQgaW4gdG8gdGhlIHJlZ2lzdHJhdGlvbiBzcGVjIG9u IGl0cyBvd24uIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBmYXIgdG9vIGxpbWl0aW5nLg0KDQoNCg0K RmluYWxseSwgdGhlcmUgc2VlbXMgdG8gYmUgYW4gaW5jb25zaXN0ZW50IHN0eWxlIGFwcHJvYWNo IHdpdGggZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWctMDAudHh0PiB3aGljaCB1 c2VzIEVUYWdzLiBTaG91bGQgdGhpcyBkcmFmdCBkbyBzbyBhcyB3ZWxsPw0KDQpUaGF0J3MgYW4g aW5kaXZpZHVhbCBzdWJtaXNzaW9uLCBub3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0LiBOb2JvZHkg aGFzLCB1bnRpbCBub3csIGV2ZW4gbWVudGlvbmVkIHRoZSB1c2Ugb2YgRVRhZ3MgaGVyZS4gVU1B ICh3aGVyZSB0aGUgcmVzb3VyY2UgcmVnaXN0cmF0aW9uIGRyYWZ0IGNvbWVzIGZyb20pIHVzZXMg RVRhZ3MsIGhlbmNlIHRoZWlyIGluY2x1c2lvbiB0aGVyZS4gSSBwZXJzb25hbGx5IGRvbid0IHNl ZSB0aGVpciB1dGlsaXR5IGhlcmUsIHRob3VnaCwgYW5kIEkgd291bGRuJ3Qgd2FudCB0byBpbmNs dWRlIGEgd2hvbGx5IG5ldyBtZWNoYW5pc20gdGhpcyBsYXRlLg0KDQpZZXMuIFRob21hcycgZHJh ZnQgaXMgbm90IGEgV0cgZG9jdW1lbnQuIEJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiBoZSBkb2Vzbid0 IGhhdmUgYSBwb2ludC4gSXQncyB3b3J0aCBkaXNjdXNzaW5nLg0KDQpPbmUgY291bGQgYXJndWUg dGhhdCB0aGUgcG9pbnQgb2YgYW4gRVRhZyBpcyB0aGF0IGl0IGlzIHVzZWZ1bCBmb3IgY2hhbmdl IGRldGVjdGlvbiB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSB3cml0ZXJzIHRvIGEgcGFydGljdWxh ciByZXNvdXJjZS4gIEluIHRoZSBkZXNpZ24gb2YgZHluYW1pYyByZWdpc3RyYXRpb24gZW5kcG9p bnQsIHRoZXJlIHNob3VsZCBvbmx5IGJlIG9uZSB3cml0ZXIgLS0gdGhlIGNsaWVudC4gVGhpcyBp cyBhbiBpbXBvcnRhbnQgb2JzZXJ2YXRpb24uDQoNClRoZXJlIGFyZSBvdGhlciBtZWNoYW5pc21z IHRoYXQgaGFuZGxlIHRoaXMgLS0gbmFtZWx5LCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biBhbmQgdGhlIGNsaWVudF9pZC4gTWFueSBpbnN0YW5jZXMgaW5jbHVkZSB0aGUgY2xpZW50X2lk IGluIHNvbWUgZm9ybSBpbiB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24gZW5kcG9pbnQncyBVUkwg Zm9yIHNhbml0eSBjaGVja2luZywgYXMgZGVzY3JpYmVkIGluIMKnNC4xLg0KDQoNCg0KU3BlY2lm aWMgaXRlbXM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiJ0b2tlbl9lbmRwb2ludF9hdXRoX21l dGhvZCINCg0KVGhlcmUgaXMgc29tZSBjb25mdXNpb24gYXMgdG8gd2hldGhlciB0aGlzIGFwcGxp ZXMgdG8gc2VydmVyIG9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFN1Z2dlc3QgcmVuYW1pbmcg cGFyYW1ldGVyIHRvICJ0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QiDQoNClRoaXMg aXMgdGhlIGZpcnN0IEkndmUgaGVhcmQgb2YgdGhpcyBwYXJ0aWN1bGFyIGNvbmZ1c2lvbi4gSSdt IGZpbmUgd2l0aCBlaXRoZXIgbmFtZSBidXQgYXQgdGhpcyBzdGFnZSBJIGRvbid0IHdhbnQgdG8g bWFrZSBzeW50YXggY2hhbmdlcyB3aXRob3V0IHZlcnksIHZlcnkgY29tcGVsbGluZyByZWFzb25z IHRvIGRvIHNvLg0KDQpUaGUgcXVlc3Rpb24gd2FzIHJhaXNlZCB0byBtZSBieSBzb21lIG5ldyBk ZXZlbG9wZXJzLiBJdCBzZWVtcyBvYnZpb3VzIHRvIHVzIGFzIGV4cGVyaWVuY2VkIE9BdXRoIHBl cnNvbnMsIGJ1dCB0byBuZXcgZGV2ZWxvcGVycyBpdCBzZWVtcyB1bmNsZWFyLiAgQWxzbywgbm93 IHRoYXQgeW91IGFyZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRpb24gYXV0aGVudGljYXRpb24sIHRo ZSB3aG9sZSB0aGluZyBnZXRzIHZlcnkgY29uZnVzaW5nLiBTbyBpdCBpcyB1c2VmdWwgZGlzYW1i aWd1YXRlIGFsbCB0aGUgcGFyYW1ldGVycyB3aGVyZSBwb3NzaWJsZS4gIFRoYXQgc2FpZCwgSSB3 b3VsZG4ndCBtaW5kIHNob3J0ZXIgbmFtZXMgKG1heWJlIG5vdCBxdWl0ZSBhcyBzaG9ydCBhcyB0 aGUgSk9TRSBzdHVmZiA7LSkNCg0KRmFpciBlbm91Z2gsIGJ1dCBhZ2FpbiwgSSBvbmx5IHdhbnQg dG8gZG8gc3ludGF4IGNoYW5nZXMgaWYgdGhlIHJlc3Qgb2YgdGhlIFdHICpyZWFsbHkqIHdhbnRz IHRvLg0KDQoNCg0KKiBDdXJyZW50bHksIHRoZSBBUEkgb25seSBzdXBwb3J0cyBhIHNpbmdsZSB2 YWx1ZSBpbnN0ZWFkIG9mIGFuIGFycmF5LiAgSWYgdGhlIHB1cnBvc2UgaXMgdG8gYWxsb3cgdGhl IGNsaWVudCB0byBrbm93IHdoYXQgYXV0aCBtZXRob2RzIGl0IHN1cHBvcnRzLCB0aGlzIHNob3Vs ZCBiZSBhbiBhcnJheSBpbmRpY2F0ZWQgd2hhdCBtZXRob2RzIHRoZSBjbGllbnQgc3VwcG9ydHMg LSBvciBpdCBzaG91bGQgbm90IGJlIHVzZWQuDQoNCkkgd291bGQgcmF0aGVyIGxpa2UgdGhpcyB0 byBiZSBhbiBhcnJheSwgcGVyc29uYWxseSwgYW5kIGJyb3VnaHQgaXQgdXAgd2l0aCB0aGUgT3Bl bklEIENvbm5lY3Qgd29ya2luZyBncm91cCBhYm91dCBzaXggbW9udGhzIGFnby4gQnV0IHRoZXJl IGl0IHdhcyBkZWNpZGVkIHRoYXQgYSBzaW5nbGUgdmFsdWUgd2FzIHNpbXBsZXIgYW5kIHN1ZmZp Y2llbnQgZm9yIHRoZSBwdXJwb3NlLiBUaGUgSUVURiBkcmFmdCBoYXMgaW5oZXJpdGVkIHRoaXMg ZGVjaXNpb24uIEkgKmJlbGlldmUqICh0aG91Z2ggYW0gbm90IDEwMCUgcG9zaXRpdmUpIHRoYXQg SSBicm91Z2h0IHVwIHRoaXMgdmVyeSBpc3N1ZSBpbiB0aGUgV0cgaGVyZSBidXQgZGlkbid0IHJl Y2VpdmUgYW55IHRyYWN0aW9uIG9uIGl0LCBzbyBzaW5nbGUgaXQgcmVtYWlucy4NCg0KSSBjYW4g Z2V0IGJlaGluZCBtdWx0aXBsZSB2YWx1ZXMuIEluIHRoaXMgY2FzZSwgaXQgY2hhbmdlcyB0aGUg bWVhbmluZyBvZiB0aGUgcGFyYW1ldGVyLiBJbnN0ZWFkIG9mIHRoZSBjbGllbnQgZm9yY2luZyB0 aGUgc2VydmVyIHRvIHVzZSBhIHBhcnRpY3VsYXIgbWV0aG9kLCB0aGUgY2xpZW50IGlzIGluZm9y bWluZyB0aGUgc2VydmVyIGFib3V0IHdoYXQgbWV0aG9kcyBpdCBjYW4gcGVyZm9ybS4gVGhpcyBh bGxvd3MgdGhlIHNlcnZlciB0byBhc3NpZ24gdGhlIGFwcHJvcHJpYXRlIG1ldGhvZCBiYXNlZCBv biBpdHMgb3duIHBvbGljeS4NCg0KQWxzbyBub3RlIHRoYXQgdGhpcyBmaWVsZCwgbGlrZSBhbGwg b3RoZXJzIGluIMKnMiwgcmVwcmVzZW50cyB0d28gdGhpbmdzOiB0aGUgY2xpZW50IHRlbGxpbmcg dGhlIHNlcnZlciAiSSB3YW50IHRvIHVzZSB0aGlzIHZhbHVlIGZvciB0aGlzIGZpZWxkIiwgYW5k IHRoZSBzZXJ2ZXIgdGVsbGluZyB0aGUgY2xpZW50ICJ0aGlzIGlzIHRoZSB2YWx1ZSB5b3UgaGF2 ZSBmb3IgdGhpcyBmaWVsZCIuIEl0J3Mgbm90IGV4YWN0bHkgYSBuZWdvdGlhdGlvbiwgbW9yZSBs aWtlIG1ha2luZyBhIHBvbGl0ZSByZXF1ZXN0IHRvIGFuIGFic29sdXRlIGRpY3RhdG9yIHdobyBo YXMgdGhlIGxhc3Qgd29yZCBhbnl3YXkuIEJ1dCBhdCBsZWFzdCB0aGlzIGRpY3RhdG9yIGlzIG5p Y2UgZW5vdWdoIHRvIHRlbGwgeW91IHdoYXQgdGhlaXIgZGVjaXNpb24gd2FzIGluc3RlYWQgb2Yg anVzdCBkZWNhcGl0YXRpbmcgeW91Lg0KDQpUaGlzIGlzIHRoZSBoZWFydCBvZiBteSBvYmplY3Rp b24uIFRoaXMgZnV6emluZXNzIGlzIGlzIGdvaW5nIHRvIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMu DQoNClRoZXJlIGlzIG5vIGZ1enppbmVzcyB0aGF0IEkgY2FuIHNlZSBoZXJlLiBJdCdzIHBhcmFs bGVsaXNtIGJldHdlZW4gd2hhdCBnb2VzIGluIHRvIHRoZSBlbmRwb2ludCBhbmQgd2hhdCBjb21l cyBvdXQgb2YgaXQuIFRoZSBzZW1hbnRpY3MgZm9yIHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9u c2UgYXJlIGRpZmZlcmVudCwgYW5kIGRpZmZlcmVudGlhYmxlIGJ5IHRoZSBmYWN0IHRoYXQgb25l IGlzIGEgcmVxdWVzdCBhbmQgdGhlIG90aGVyIGlzIGEgcmVzcG9uc2UuDQoNCg0KDQoqIFRoZXJl IGlzIG5vIGF1dGhuIG1ldGhvZCBmb3IgImNsaWVudF9zZWNyZXRfc2FtbCIgb3IgInByaXZhdGVf a2V5X3NhbWwiLg0KDQpOb2JvZHkgaGFzIHJlYWxseSBhc2tlZCB0aGF0IHRoZXNlIHR3byBiZSBp bmNsdWRlZCBvciBzcGVjaWZpZWQuIFRoZSBleHRlbnNpb24gbWVjaGFuaXNtICh1c2luZyBhbiBh YnNvbHV0ZSBVUkkpIHdvdWxkIGFsbG93IHNvbWVvbmUgZWxzZSB0byBkZWZpbmUgdGhlc2UuIElz IHRoZSBkZWZpbml0aW9uIGluIHRoZSBTQU1MIEFzc2VydGlvbiBkcmFmdCBzdWZmaWNpZW50IGZv ciB0aGVpciB1c2U/DQoNCkkgdGhpbmsgdGhpcyBpcyBjb21pbmcgZnJvbSB0aGUgZmFjdCB0aGF0 IHRoZXJlIGlzIGEgSldUIGJlYXJlciBkcmFmdCBhbmQgYSBTQU1MIGJlYXJlciBkcmFmdC4gIFRo ZSB0cnV0aCBpcyB5b3UgYXJlIGRlZmluaW5nIGFuIGF1dGhlbnRpY2F0aW9uIHRoYXQgaXNuJ3Qg ZXZlbiBkZWZpbmVkLg0KDQoNCg0KVGhlcmUgYXJlIG5vIHByb2ZpbGVzIHJlZmVyZW5jZWQgb3Ig ZGVmaW5lZCBmb3IgImNsaWVudF9zZWNyZXRfand0IiBvciAicHJpdmF0ZV9rZXlfand0Ii4gTmVp dGhlciBvZiB0aGUgSldUIG9yIFNBTUwgQmVhcmVyIGRyYWZ0cyByZWZlcmVuY2VkIGNvdmVyIHRo ZXNlIHR5cGVzIG9mIGZsb3dzLiBUaGV5IG9ubHkgY292ZXIgYmVhcmVyIGZsb3dzLiAgImNsaWVu dF9zZWNyZXRfand0IiBhbmQgInByaXZhdGVfa2V5X2p3dCIgc2VlbSB0byBoYXZlIHNvbWUgbWVh bmluZyB3aXRoaW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJIG5vdGUgdGhhdCBPSURDIGRvZXMgbm90 IGZ1bGx5IGRlZmluZSB0aGVzZSBlaXRoZXIuDQoNClRoZSBKV1QgYXNzZXJ0aW9uIGRyYWZ0IGRv ZXMgc2F5IGhvdyB0byB1c2UgYSBKV1QgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiwgYW5kIHRo ZSBEeW5SZWcgdGV4dCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIGEgY2xpZW50IHNpZ25pbmcgc2Fp ZCBKV1Qgd2l0aCBpdHMgb3duIHNlY3JldCBzeW1tZXRyaWNhbGx5IHZzLiBhIGNsaWVudCB1c2lu ZyBpdHMgb3duIHByaXZhdGUga2V5LCBhc3ltbWV0cmljYWxseS4NCg0KQWN0dWFsbHkgbXkgaW50 ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1bWVzIHRoZSBKV1QgQmVhcmVyIGlzIGEg YmVhcmVyIHRva2VuLiAgVGhlIGFzc3VtcHRpb24gaXMgdGhhdCBpZiBhIGNsaWVudCBoYXMgdGhl IGFzc2VydGlvbiBpdCBoYXMgdGhlIHJpZ2h0IHRvIHByZXNlbnQgaXQuICBJT1cuIFRoZSBKV1Qg QmVhcmVyIERyYWZ0IGlzIG1vc3QgZGVmaW5pdGl2ZWx5IG5vdCBhIEpXVCBIb0sgRHJhZnQuICA6 LSkNCg0KUmVnYXJkbGVzcywgeW91IGFyZSBpbnRyb2R1Y2luZyBhIG5ldyBwcm9maWxlIHdoaWNo IGlzIHVuZGVmaW5lZC4NCg0KSSB0aGluayBJIHNlZSB0aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFr aW5nIG5vdywgbGV0IG1lIHRyeSB0byByZS1zdGF0ZSBpdDoNCg0KV2hpbGUgdGhlIGJhc2ljcyBv ZiAiaG93IHRvIHByZXNlbnQgYSBKV1QgYXMgYSBjbGllbnQgY3JlZGVudGlhbCIgaXMgZGVmaW5l ZCBoZXJlOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVh cmVyLTA1Lmh0bWwjcmZjLnNlY3Rpb24uMi4yICwgaXQncyBub3QgY29tcGxldGVseSBzcGVjaWZp ZWQgaW4gdGhhdCBpdCBkb2Vzbid0IGZ1bGx5IHJlc3RyaWN0IHRoZSBzaWduYXR1cmUgc2VjcmV0 IHNvdXJjZSwgdGhlIGF1ZGllbmNlIGNsYWltLCBhbmQgb3RoZXIgdGhpbmdzIHRoYXQgdGhlIEFT IHdvdWxkIG5lZWQgdG8gY2hlY2sgYW5kIHZhbGlkYXRlLiBSaWdodD8gVGhlIGR5bmFtaWMgcmVn aXN0cmF0aW9uIGRyYWZ0IGNhbiBkZWZpbmUgdGhvc2UgY2FzZXMgaW4gZ3JlYXRlciBkZXRhaWwg aWYgbmVlZGVkICh0aG91Z2ggSSB0aGluayBpdCBkb2VzIHNvIHN1ZmZpY2llbnRseSBhcy1pcywg SSB3ZWxjb21lIG1vcmUgY2xhcml0eSkuDQoNCkknZCBiZSBPSyB3aXRoIGFkZGluZyB0aGUgU0FN TCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwgb24gdGhlIEpXVCBiaXRzLCBvciBkcm9w cGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50cyB0byBkbyBhbnkgb2YgdGhvc2UgYWN0 aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpXVCBzdHVmZiBpcyBhbHJlYWR5IGluIHVz ZSBhbmQgZnVuY3Rpb25pbmcgYW5kIGl0J2QgYmUgYSBzaGFtZSB0byBsZWF2ZSBpdCBvdXQuDQoN Cg0KDQpUaGVyZSBpcyBubyBhdXRoZW50aWNhdGlvbiBtZXRob2QgZGVmaW5lZCBmb3IgImNsaWVu dF9iZWFyZXJfc2FtbCIgb3IgImNsaWVudF9iZWFyZXJfand0IiBvciAiY2xpZW50X2JlYXJlcl9y ZWYiLiAgU2luY2UgdGhlIGJlYXJlciBzcGVjcyBzYXkgdGhpcyBpcyBhY2NlcHRhYmxlLCAgdGhl IGR5bmFtaWMgcmVnaXN0cmF0aW9uIHNwZWMgc2hvdWxkIGFjY2VwdCB0aGVzZS4NCg0KSSBkb24n dCB1bmRlcnN0YW5kIHRoaXMgYml0IC0tIHdoZXJlIGFyZSB0aGVzZSBkZWZpbmVkIGluIFJGQzY3 NTA/IEkgZG9uJ3QgZXZlbiBrbm93IHdoYXQgY2xpZW50X2JlYXJlcl9yZWYgd291bGQgcmVmZXIg dG8uDQoNCjY3NTAgc2F5cyB5b3UgY2FuIHVzZSBhIGJlYXJlciBhc3NlcnRpb24gKGUuZy4gb2J0 YWluZWQgZnJvbSBhbiBJRFApIGFuZCB3aWVsZCBpdCBhcyBhbiBhdXRoZW50aWNhdGlvbiBhc3Nl cnRpb24uICBUaGUgY2xpZW50IGlzIE5PVCBjcmVhdGluZyBvciBtb2RpZnlpbmcgdGhlIGFzc2Vy dGlvbi4gVGhlIGNsaWVudCBpcyBzaW1wbHkgcGFzc2luZyBvbmUgaXQgcHJldmlvdXNseSBvYnRh aW5lZC4NCg0KV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgbm90IGJlYXJlci4gSXQgaXMgaG9s ZGVyIG9mIGtleS4gVmVyeSB2ZXJ5IGRpZmZlcmVudC4NCg0KDQpBIHBvc3NpYmxlIHN1Z2dlc3Rp b24gaXMgdG8gcmVtb3ZlIGNsaWVudF9zZWNyZXRfand0IGFuZCBwcml2YXRlX2tleV9qd3QgYW5k IGRlZmluZSB0aG9zZSBhcyByZWdpc3RlciBleHRlbnNpb25zIHNpbmNlIHRoZXNlIHByb2ZpbGVz IGFyZSBub3QgZGVmaW5lZC4NCg0KVGhhdCdzIHBvc3NpYmxlLCBidXQgdGhleSBhcmUgaW4gYWN0 aXZlIHVzZSBhbHJlYWR5Lg0KDQpUaGF0IG1heSBiZSB0cnVlLiBCdXQgdGhlbiB5b3UgbmVlZCB0 byB3cml0ZSBhbm90aGVyIGRyYWZ0IHNvIHRoZSByZXN0IG9mIHVzIGNhbiBpbXBsZW1lbnQgaXQg aW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuICBNZSBJIHByZWZlciBub3QgdG8gZ3Vlc3Mgd2hhdCB5 b3UgYXJlIGRvaW5nLg0KDQpUaGlzIG11Y2ggSSBhZ3JlZSB3aXRoLg0KDQoNCg0KDQpBYm91dCAi dG9zX3VyaSIgYW5kICJwb2xpY3lfdXJpIg0KDQpUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0b3Nf dXJpIGFuZCBwb2xpY3lfdXJpIGlzIHVuY2xlYXIuICBDYW4gd2UgY2xhcmlmeSBvciBjb21iaW5l IHRoZW0/DQoNClRlcm1zIG9mIHNlcnZpY2UgYW5kIHBvbGljeSBhcmUgdHdvIGRpZmZlcmVudCBk b2N1bWVudHMuIE9uZSBpcyBzb21ldGhpbmcgdGhhdCBhIHVzZXIgYWNjZXB0cyAoZ2VuZXJhbGx5 IGRlc2NyaWJpbmcgd2hhdCB0aGUgdXNlciB3aWxsIGRvKSwgb25lIGlzIGEgc3RhdGVtZW50IG9m IHdoYXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIgKGluIHRoaXMgY2FzZSwgdGhlIGNsaWVudCkgd2ls bCBkby4gTW9yZSBpbXBvcnRhbnRseSwgd2UgdXNlZCB0byBoYXZlIG9ubHkgb25lLCBhbmQgc2V2 ZXJhbCBwZW9wbGUgYXNrZWQgZm9yIHRoZW0gdG8gYmUgc3BsaXQuDQoNClNldmVyYWwgZGV2ZWxv cGVycyB3ZXJlIGNvbmZ1c2VkIGJ5IHRoaXMuIEluIHBhcnRpY3VsYXIgdGhleSBjb3VsZG4ndCBm aWd1cmUgb3V0IHdoaWNoIHdhcyB1c2VkIGZvciB3aGF0LiAgSnVzdCBwYXNzaW5nIGFsb25nIHRo ZSBmZWVkYmFjay4NCg0KT0ssIHRoZSBkaXN0aW5jdGlvbiB0aGF0IEkgc2VlIGlzIHRoYXQgdGhl IFRPUyBpcyBjb250cmFjdHVhbCwgdGhlIFBvbGljeSBpcyBhIHN0YXRlbWVudC4gUmUtcmVhZGlu ZyB0aGUgZGVmaW5pdGlvbnMgaW4gdGhlcmUgcmlnaHQgbm93LCB0aGF0IGNhbiBiZSBtYWRlIG11 Y2ggY2xlYXJlci4gKEl0IGV2ZW4gbG9va3MgbGlrZSBzb21lIE9JREMgdGV4dCBsZWFrZWQgaW50 byB0aGUgZGVmaW5pdGlvbiBvZiBwb2xpY3lfdXJpIGFuZCB0aGF0IGhhZG4ndCBiZWVuIGNhdWdo dCB5ZXQuKQ0KDQoNCg0KQWxzbywgYXJlbid0IHRoZXNlIHJlYWxseSBVUklzIG9yIGFyZSB0aGV5 IG1lYW50IHRvIGJlIFVSTHM/DQoNClRoZXJlIHdhcyBhbHJlYWR5IGRpc2N1c3Npb24gYWJvdXQg dGhpcyBvbiB0aGUgbGlzdDogVGhlIElFVEYgaXMgYXBwYXJlbnRseSB0cnlpbmcgdG8gZGVwcmVj YXRlIFVSTCBpbiBmYXZvciBvZiBVUkkgaW4gbmV3IHNwZWNzLiBTbyBpbiBwcmFjdGljZSB0aGV5 J2xsIG5lYXJseSBhbHdheXMgYmUgVVJMcywgYnV0IHNpbmNlIGFsbCBVUkxzIGFyZSBVUklzIHdl J3JlIG5vdCB0ZWNobmljYWxseSBpbmNvcnJlY3QgaW4gZm9sbG93aW5nIHRoZSBuZXcgcG9saWN5 LiBBbmQgaXQgbWFrZXMgdGhlIElFU0cgbGVzcyBtYWQgYXQgdXMsIHdoaWNoIGlzIGEgcGx1cy4N Cg0KQXJnLiBOaWNlLiAgVGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5IHRoZSB2YWx1ZSBwYXNzZWQg bXVzdCByZXNvbHZlIHRvIGEgdmFsaWQgd2ViIHBhZ2UsIGRvY3VtZW50LCB3aGF0ZXZlci4NCg0K VGhhdCdzIGZhaXIsIGFuZCBpdCdzIHNvbWV0aGluZyB0aGF0IHRoZSBBUyBjYW4gZXZlbiBjaGVj ayBpZiBpdCB3YW50cyB0by4NCg0KDQoNCkFib3V0ICJqd2tzX3VyaSINCg0KQSBub3JtYXRpdmUg cmVmZXJlbmNlIGZvciBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWIta2V5LTA5IGlzIG5lZWRlZC4NCg0KWWVzLCB5b3UncmUgY29ycmVjdCwgSSdsbCBh ZGQgdGhhdC4NCg0KDQpTaG91bGQgYmUgVVJMIGluc3RlYWQgb2YgVVJJPw0KDQpTZWUgYWJvdmUu IDopDQoNCg0KU2VjdGlvbiAyLjENCg0KSW4gdGhlIHRhYmxlIHVybjppZXRmOnBhcmFtczpvYXV0 aDpncmFudC10eXBlOmp3dC1iZWFyZXIgaXMgbWlzc2luZy4NCg0KSXQncyB0aGVyZSBpbiB0aGUg Y29weSBvZiAtMTAgSSdtIHJlYWRpbmcgb2ZmIG9mIGlldGYub3JnPGh0dHA6Ly9pZXRmLm9yZy8+ IHJpZ2h0IG5vdyDigKYgPw0KJw0KU29ycnkgSSBtZWFudDogdXJuOmlldGY6cGFyYW1zOm9hdXRo OmdyYW50LXR5cGU6c2FtbC1iZWFyZXINCg0KQWgsIHRoYXQgbWFrZXMgbW9yZSBzZW5zZS4gSWYg dGhlIFdHIHdhbnRzIHRvIGFkZCBpbiBTQU1MIHN1cHBvcnQgdG8gcGFyYWxsZWwgdGhlIEpXVCBz dXBwb3J0LCBJJ2QgYmUgT0sgd2l0aCB0aGF0Lg0KDQoNCg0K4oCcQXMgc3VjaCwgYSBzZXJ2ZXIg c3VwcG9ydGluZyB0aGVzZSBmaWVsZHMgU0hPVUxEIHRha2Ugc3RlcHMgdG8gZW5zdXJlIHRoYXQg YSBjbGllbnQgY2Fubm90IHJlZ2lzdGVyIGl0c2VsZiBpbnRvIGFuIGluY29uc2lzdGVudCBzdGF0 ZS7igJ0NCg0KV2UgbWF5IHdhbnQgdG8gZGVmaW5lIG1vcmUgZGV0YWlsZWQgSFRUUCBlcnJvciBy ZXNwb25zZS4gRS5nLiA0MDAgc3RhdHVzIGNvZGUgKyBkZWZpbmVkIGVycm9yIGNvZGUgKOKAnGlu dmFsaWRfY2xpZW50X21ldGFkYXRh4oCdKT8NCg0KSSdkIGJlIGZpbmUgd2l0aCBkZWZpbmluZyBh IG1vcmUgZXhwbGljaXQgZXJyb3Igc3RhdGUgaW4gdGhpcyBjYXNlLiBJIHRoaW5rIGl0IHdvdWxk IGhlbHAgaW50ZXJvcCBmb3IgdGhlIHNlcnZlcnMgdGhhdCB3YW50IHRvIGVuZm9yY2UgZ3JhbnQt dHlwZSBhbmQgcmVzcG9uc2UtdHlwZSByZXN0cmljdGlvbnMsIGJ1dCBzZXJ2ZXJzIHRoYXQgY2Fu J3Qgb3IgZG9uJ3QgY2FyZSBhYm91dCByZXN0cmljdGluZyBncmFudHMgdHlwZXMgYW5kIHdoYXRu b3QgZG9uJ3QgaGF2ZSB0byBkbyBhbnl0aGluZyBzcGVjaWFsLg0KDQoNClNlY3Rpb24gMi4yDQoN Ck1heSB3YW50IHRvIGFkZDoNCg0KV2hlbiDigJwj4oCdIGxhbmd1YWdlIHRhZyBpcyBtaXNzaW5n LCAoZS5nLiDigJwjZW7igJ0gaXMgbWlzc2luZyBpbiDigJxjbGllbnRfbmFtZeKAnSwgaW5zdGVh ZCBvZiDigJxjbGllbnRfbmFtZSNlbuKAnSkgdGhlIE9BdXRoIHNlcnZlciBtYXkgdXNlIGludGVy cHJldCB0aGUgbGFuZ3VhZ2UgdXNlZCBiYXNlZCBvbiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBvciBo ZXVyaXN0aWNzLg0KDQpUaGF0IHNlZW1zIGluY29uc2lzdGVudCB3aXRoIHdoYXQgd2UgYWxyZWFk eSBoYXZlOg0KDQpJZiBhbnkgaHVtYW4tcmVhZGFibGUgZmllbGQgaXMgc2VudCB3aXRob3V0IGEg bGFuZ3VhZ2UgdGFnLCBwYXJ0aWVzIHVzaW5nIGl0IE1VU1QgTk9UIG1ha2UgYW55IGFzc3VtcHRp b25zIGFib3V0IHRoZSBsYW5ndWFnZSwgY2hhcmFjdGVyIHNldCwgb3Igc2NyaXB0IG9mIHRoZSBz dHJpbmcgdmFsdWUsIGFuZCB0aGUgc3RyaW5nIHZhbHVlIE1VU1QgYmUgdXNlZCBhcy1pcyB3aGVy ZXZlciBpdCBpcyBwcmVzZW50ZWQgaW4gYSB1c2VyIGludGVyZmFjZS4NCg0KV2hpY2ggaXMgdG8g c2F5LCB0cmVhdCBpdCBhcyBhIHJhdyBieXRlLXZhbHVlLXN0cmluZyBhbmQgZG9uJ3QgdHJ5IHRv IGdldCBmYW5jeS4NCg0KSSB3aWxsIGRpc2N1c3Mgd2l0aCBvdXIgZGV2ZWxvcGVycy4gSSdtIG5v dCBzdXJlIHRoZSBhcy1pcyB3b3Jrcy4NCg0KSXMgaXQgdGhlIGludGVudCB0aGF0IHdoZW4gdGhl IGNsaWVudCBoYXMgbG9jYWxpemVkICJjbGllbnRfbmFtZSIgZm9yIGV4YW1wbGUsIGl0IHNob3Vs ZCBwYXNzIGFsbCBsYW5ndWFnZSB2YXJpYXRpb25zIGluIGEgSlNPTiBhcnJheT8NCg0KT3IsIHNo b3VsZCBwYXJ0IG9mIHRoZSByZWdpc3RyYXRpb24gYmUgdG8gaW5kaWNhdGUgd2hpY2ggaW50ZXJm YWNlIGxhbmd1YWdlIHRoZSBjbGllbnQgd2lzaGVzIHRvIHVzZT8gIFRoZW4gaXQgb25seSBwYXNz ZXMgYSBzaW5nbGUgdmFsdWUgZm9yIHRoYXQgcmVnaXN0cmF0aW9uPw0KDQoNCk5vLCB0aGUgY2xp ZW50IHNob3VsZCBwYXNzIHBhcmFtZXRlcnMgYXMgbXVsdGlwbGUgc2VwYXJhdGUgdmFsdWVzLiBD b25uZWN0IGhhcyB0aGlzIGluIGl0cyBleGFtcGxlOg0KDQoNCiAgICJjbGllbnRfbmFtZSI6ICJN eSBFeGFtcGxlIiwNCiAgICJjbGllbnRfbmFtZSNqYS1KcGFuLUpQIjoNCiAgICAgIuOCr+ODqeOC pOOCouODs+ODiOWQjSIsDQoNClNob3VsZCB3ZSBhZGQgdGhhdCB0byBhdCBsZWFzdCBvbmUgb2Yg dGhlIGV4YW1wbGVzIGluIER5blJlZz8gKFRoZSBsYW5ndWFnZSB0YWdzIGFyZSBhIGxhdGUgYWRk aXRpb24sIHNvIHRoZSBleGFtcGxlcyBkb24ndCByZWZsZWN0IGl0LikNCg0KSWYgdGhlIGNsaWVu dCBwYXNzZXMgb25seSBhIHNpbmdsZSB1bmFkb3JuZWQgZmllbGQsIHRoZSBBUyBjYW4ndCBtYWtl IGFueSBhc3N1bXB0aW9uIGFib3V0IHdoYXQgbGFuZ3VhZ2UgaXQgaXMuIFRoaW5rIG9mIHRoaXMg YXMgdGhlIGludGVybmF0aW9uYWxpemVkIHZhbHVlIG9mIHRoZSBmaWVsZCB3aGlsZSB0aGUgbGFu Z3VhZ2UgdGFncyBhcmUgdGhlIGxvY2FsaXplZCB2ZXJzaW9ucyBvZiB0aGUgZmllbGQuIFRoaXMg aXMgd2h5IHdlIHJlY29tbWVuZCB0aGF0IHRoZSBiYXJlLXZhbHVlIGFsd2F5cyBiZSBzZW50IGJ5 IHRoZSBjbGllbnQsIHNvIHRoYXQgaW4gdGhlIGxhY2sgb2YgYW55dGhpbmcgbW9yZSBzcGVjaWZp YywgdGhlIEFTIGNhbiBhdCBsZWFzdCBkbyAqc29tZXRoaW5nKiB3aXRoIGl0Lg0KDQpQYXNzaW5n IGluIGEgImRlZmF1bHQiIGxhbmd1YWdlIGZpZWxkIChsaWtlIGRlZmF1bHRfbG9jYWxlIG9yIHRo ZSBsaWtlKSBpcyBvbmx5IGdvaW5nIHRvIGxlYWQgdG8gcGFpbiBmb3IgaW1wbGVtZW50b3JzIG9m IGJvdGggY2xpZW50cyBhbmQgc2VydmVycywgYW5kIGl0J3MgZ29pbmcgdG8gaHVydCB0aGUgaW50 ZXJvcGVyYWJpbGl0eSBvZiB0aGUgaHVtYW4tcmVhZGFibGUgZmllbGRzLg0KDQoNCg0KU2VjdGlv biAzDQoNCkV4aXN0aW5nIHRleHQ6DQoNCuKAnEluIG9yZGVyIHRvIHN1cHBvcnQgb3BlbiByZWdp c3RyYXRpb24gYW5kIGZhY2lsaXRhdGUgd2lkZXIgaW50ZXJvcGVyYWJpbGl0eSwgdGhlIENsaWVu dCBSZWdpc3RyYXRpb24gRW5kcG9pbnQgU0hPVUxEIGFsbG93IGluaXRpYWwgcmVnaXN0cmF0aW9u IHJlcXVlc3RzIHdpdGggbm8gYXV0aGVudGljYXRpb24uICBUaGVzZSByZXF1ZXN0cyBNQVkgYmUg cmF0ZS1saW1pdGVkIG9yIG90aGVyd2lzZSBsaW1pdGVkIHRvIHByZXZlbnQgYSBkZW5pYWwtb2Yt c2VydmljZSBhdHRhY2sgb24gdGhlIENsaWVudCBSZWdpc3RyYXRpb24gRW5kcG9pbnQu4oCdDQoN Ckkgd291bGQgc3VnZ2VzdCB0byBjaGFuZ2UgdGhlIGZpcnN0IOKAnFNIT1VMROKAnSB0byDigJxN QVnigJ0uICAgSW4gbW9zdCBjbG91ZCBzZXJ2aWNlcywgdGhlIGZpcnN0IGNsaWVudCBpcyByZWdp c3RlcmVkIGJ5IGEgaHVtYW4gdXNlci4gVGhlbiwgb3RoZXIgY2xpZW50cyBjYW4gYmUgZnVydGhl ciB1c2VkIHRvIGF1dG9tYXRlIG90aGVyIGNsaWVudCByZWdpc3RyYXRpb24uICBTbywgdGhlIGZp cnN0IHJlcXVlc3Qgd291bGQgdHlwaWNhbGx5IGNvbWUgd2l0aCBhbiBhdXRoZW50aWNhdGVkIHVz ZXIgaWRlbnRpdHkuDQoNCkkgdGhpbmsgdGhlIHdlaWdodCBvZiAiU0hPVUxEIiBpcyBhcHByb3By aWF0ZSBoZXJlLCBiZWNhdXNlIEkgYmVsaWV2ZSB0aGF0IHR1cm5pbmcgb2ZmIG9wZW4gcmVnaXN0 cmF0aW9uIGF0IHRoZSBBUyAod2hpY2ggaXMgd2hhdCB0aGlzIGlzIHRhbGtpbmcgYWJvdXQpIHJl YWxseSBvdWdodCB0byBiZSB0aGUgZXhjZXB0aW9uIHJhdGhlciB0aGFuIHRoZSBydWxlLg0KDQpJ IHRoaW5rIHlvdSBhcmUgcmVhZGluZyBpdCB3cm9uZyAtLSBhIGRvdWJsZS1uZWdhdGl2ZSBpc3N1 ZS4gVGhlIGVuZCBvZiB0aGUgc2VudGVuY2UgaXMgIm5vIGF1dGhlbnRpY2F0aW9uIi4gIFlvdSBh cmUgaW1wbHlpbmcgdGhhdCBOTyBBdXRoZW50aWNhdGlvbiB1cyB3aGF0IHNob3VsZCBub3JtYWxs eSBiZSBkb25lLiBJIHRoaW5rIHlvdSBpbnRlbmQgYW5vbnltb3VzIGF1dGhlbnRpY2F0aW9uIHRv IGJlIHRoZSBleGNlcHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUgZG9uJ3QgeW91Pw0KDQpObywg SSB0aGluayB0aGF0IGFub255bW91cyBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdGhlIHJ1bGUu IE9wZW4gcmVnaXN0cmF0aW9uIHNob3VsZCBiZSBkZWZhdWx0Lg0KDQoNCg0KT24gdGhlIGZsaXAg c2lkZSwgdGhlIGVhcmxpZXIgcGFyYWdyYXBoOg0KDQrigJxUaGUgQ2xpZW50IFJlZ2lzdHJhdGlv biBFbmRwb2ludCBNQVkgYWNjZXB0IGFuIGluaXRpYWwgYXV0aG9yaXphdGlvbiBjcmVkZW50aWFs IGluIHRoZSBmb3JtIG9mIGFuIE9BdXRoIDIuMCBbUkZDNjc0OV0gYWNjZXNzIHRva2VuIGluIG9y ZGVyIHRvIGxpbWl0IHJlZ2lzdHJhdGlvbiB0byBvbmx5IHByZXZpb3VzbHkgYXV0aG9yaXplZCBw YXJ0aWVzLiBUaGUgbWV0aG9kIGJ5IHdoaWNoIHRoaXMgYWNjZXNzIHRva2VuIGlzIG9idGFpbmVk IGJ5IHRoZSByZWdpc3RyYW50IGlzIGdlbmVyYWxseSBvdXQtb2YtYmFuZCBhbmQgaXMgb3V0IG9m IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi7igJ0NCg0KSSB0ZW5kIHRvIHRoaW5rIGl0IHdv dWxkIGJlIGJldHRlciB0byBjaGFuZ2UgdGhpcyDigJxNQVnigJ0gdG8g4oCcU0hPVUxE4oCdLg0K DQpUaGF0IGFjY2VzcyB0b2tlbiB3b3VsZCBjYXJyeSBhIGh1bWFuIHVzZXIgYXV0aGVudGljYXRl ZCBpZGVudGl0eSBzb21laG93LiBJbiBzb21lIGNhc2VzLCBpdCBjYW4gYmUgYSBwdXJlIGF1dGhl bnRpY2F0ZWQgdXNlciBhc3NlcnRpb24gdG9rZW4uDQoNCkFnYWluLCBkaXNhZ3JlZSwgZm9yIHRo ZSBzYW1lIHJlYXNvbmluZyBhcyBhYm92ZS4NCg0KU2FtZSByZWFzb25pbmcuDQoNCg0KQWJvdXQg c2VjdGlvbiA0LjM6DQoNCg0KSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHNl cnZlciwgdGhlIHNlcnZlciBNVVNUIHJlc3BvbmQNCiAgIHdpdGggSFRUUCA0MDEgVW5hdXRob3Jp emVkLCBhbmQgdGhlIFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gdXNlZCB0bw0KICAgbWFrZSB0 aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQuDQoNCklmIHRoZSBDbGll bnQgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzZXJ2ZXIsIHNob3VsZG4ndCBpdCByZXR1cm4gYSAi NDA0IE5vdCBGb3VuZCI/DQoNCklmIHJldm9raW5nIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2VuLCBpcyBpdCBib3VuZCB0byBhIHNpbmdsZSBjbGllbnQgcmVnaXN0cmF0aW9uPyAgVGhpcyBp cyBub3QgY2xlYXIuICBXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJlZ2lzdHJhdGlvbiBh Y2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJlc3Bv bnNlIGluIHNlY3Rpb24gNS4xLg0KDQpUaGUgbGFuZ3VhZ2UgYWJvdXQgdGhlIDQwMSBoZXJlIChh bmQgaW4gb3RoZXIgbmVhcmJ5IHNlY3Rpb25zKSBpcyBzcGVjaWZpY2FsbHkgc28gdGhhdCB5b3Ug dHJlYXQgYSBtaXNzaW5nIGNsaWVudCBhbmQgYSBiYWQgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biB0aGUgc2FtZSB3YXkuIFlvdSBzZWUsIHJldHVybmluZyBhIDQwNCBoZXJlIGFjdHVhbGx5IGlu ZGljYXRlcyB0aGluZ3Mgd2VyZSBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGUuIE5hbWVseSwgdGhh dCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgc3RpbGwgdmFsaWQgYnV0IHRoZSBj bGllbnQgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgYXR0YWNoZWQgdG8g ZG9lc24ndCBleGlzdCBhbnltb3JlLiBUaGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbiBt ZWFudCB0byBiZSB0aWVkIHRvIGEgY2xpZW50J3MgaW5zdGFuY2UgKG9yIHJlZ2lzdHJhdGlvbiks IHNvIGl0J3MgYWN0dWFsbHkgbW9yZSBzZW5zaWJsZSB0byBhY3QgYXMgdGhvdWdoIHRoZSByZWdp c3RyYXRpb24gYWNjZXNzIHRva2VuIGlzbid0IHZhbGlkIGFueW1vcmUuIEluIGF0IGxlYXN0IHNv bWUgaW1wbGVtZW50YXRpb25zIChzcGVjaWZpY2FsbHkgb3VycyBhdCBNSVRSRSB0aGF0J3MgYnVp bHQgb24gU0VDT0FVVEggaW4gSmF2YSksIHlvdSdkIG5ldmVyIGJlIGFibGUgdG8gcmVhY2ggdGhl IDQwNCBzdGF0ZSBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0aGUgaW5ib3VuZCB0 b2tlbi4NCg0KU2luY2UgdGhlIGludGVudCBvZiB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biBpcyB0aGF0IGl0J3MgYm91bmQgdG8gYSBzaW5nbGUgaW5zdGFuY2UsIGl0cyBsaWZlY3ljbGUg aXMgZ2VuZXJhbGx5IHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBiZWdpbnMgYXQgdGhlIGlzc3VhbmNl IG9mIGEgbmV3IGNsaWVudF9pZCB3aXRoIHRoYXQgaW5zdGFuY2UuIFRoYXQgdG9rZW4gbWlnaHQg YmUgcmV2b2tlZCBhbmQgYSBuZXcgb25lIGlzc3VlZCBvbiBSZWFkIGFuZCBVcGRhdGUgcmVxdWVz dHMgdG8gdGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50IChhbmQgdGhlIGNsaWVudCBu ZWVkcyB0byBiZSBwcmVwYXJlZCBmb3IgdGhhdCAtLSBzYW1lIGFzIHRoZSBjbGllbnRfc2VjcmV0 KSwgYW5kIGl0IHdpbGwgYmUgcmV2b2tlZCB3aGVuIHRoZSBjbGllbnQgaXMgZGVsZXRlZCBlaXRo ZXIgd2l0aCBhIERlbGV0ZSBjYWxsIHRvIHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2lu dCBvciBzb21ldGhpbmcgaGFwcGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwgdGhlIGNsaWVudC4N Cg0KU2hvdWxkIHdlIGFkZCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgdG8gdGhlIGRlZmluaXRpb24g aW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdtIHZlcnkgb3BlbiB0byBj b25jcmV0ZSBzdWdnZXN0aW9ucyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9uJ3QgdGhpbmsgaXQncyBh cyBjbGVhciBhcyB3ZSdkIGxpa2UuDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGxvb2sgYXQgaXQuDQoN Cg0KQWJvdXQgc2VjdGlvbiA1LjE6DQoNCklzIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gdW5p cXVlPyAgT3IgaXMgaXQgc2hhcmVkIGJ5IG11bHRpcGxlIGluc3RhbmNlcz8gICBJZiBzaGFyZWQs IHRoZW4gcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBjYW4ndCBiZSByZXZva2VkIG9uIGRlbGV0 ZSBvZiBjbGllbnQuDQoNClN1Z2dlc3QgcmVuYW1lIOKAnGV4cGlyZXNfYXTigJ0gdG8g4oCcY2xp ZW50X3NlY3JldF9leHBpcmVzX2F04oCdLA0KDQpTdWdnZXN0IHRvIHJlbmFtZSDigJxpc3N1ZWRf YXTigJ0gdG8g4oCcaWRfaXNzdWVkX2F04oCdDQoNCldoaWxlIEkgZG8gbGlrZSB0aGUgc3VnZ2Vz dGlvbiBvZiBjaGFuZ2luZyB0aGVzZSB0byBjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXQgYW5kIGNs aWVudF9pZF9pc3N1ZWRfYXQsIGFuZCBJIHRoaW5rIHRoZXNlIGFyZSBtb3JlIGNsZWFyIGFuZCBy ZWFkYWJsZSwNCg0KSSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUgc3ludGF4IGR1cmluZyBsYXN0 IGNhbGwgdW5sZXNzIHRoZXJlIGlzIGEgY2xlYXIgbmVlZCBhbmQgYSBjbGVhciBjb25zZW5zdXMg Zm9yIGRvaW5nIHNvLg0KDQpUaGF0J3Mgd2h5IHdlIGFyZSBoYXZpbmcgbGFzdCBjYWxsLiBUbyBj b25maXJtIGNvbnNlbnN1cyBvbiB0aGUgZHJhZnQuDQoNClNhbWUgcmVhc29uaW5nIGFzIGVhcmxp ZXIuIFlvdSBub3cgaGF2ZSBtdWx0aXBsZSB0b2tlbnMgKHJlZ2lzdHJhdGlvbiBhY2Nlc3MgYW5k IGNsaWVudCkgaW4gcGxheS4gVGhlIHNwZWMgbmVlZHMgdG8gYmUgY2xlYXIgd2hpY2ggb25lIGl0 IGlzIHRhbGtpbmcgYWJvdXQuDQoNCkknbSBmaW5lIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2Ug YnV0IEkgd291bGQgbGlrZSBtb3JlIGZlZWRiYWNrIGZyb20gb3RoZXIgcGVvcGxlIGJlZm9yZSBt b3ZpbmcgZm9yd2FyZCB3aXRoIGl0LiBUaGVyZSdzIGEgbG90IG9mIHZhbHVlIGluICJqdXN0IHBp Y2sgYSBuYW1lIGFuZCBzaGlwIGl0IiBhcyB3ZWxsIHRob3VnaCwgYW5kIEkgZG9uJ3Qgd2FudCB0 byBkZXZvbHZlIGludG8gYmlrZSBzaGVkZGluZy4gKEknbSBub3QgYWNjdXNpbmcgeW91IG9mIGJp a2Ugc2hlZGRpbmcgcXVpdGUgeWV0LCBidHcsIGp1c3QgYWZyYWlkIG9mIGdldHRpbmcgaW50byBh IGxvbmcgZGViYXRlIG9uIG5hbWVzLikNCg0KDQoNClNlY3Rpb24gNw0KDQpXaGVuIGEgY2xpZW50 X3NlY3JldCBleHBpcmVzIGlzIGl0IHRoZSBpbnRlbnQgdGhhdCBjbGllbnRzIGRvIGFuIHVwZGF0 ZSBvciByZWZyZXNoIHRvIGdldCBhIG5ldyBjbGllbnQgc2VjcmV0Pw0KDQpZZXMsIHRoZSBjbGll bnQgaXMgc3VwcG9zZWQgdG8gZWl0aGVyIGNhbGwgdGhlIHJlYWQgb3IgdXBkYXRlIG1ldGhvZHMg b24gdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGVuZHBvaW50IHRvIGdldCBpdHMgbmV3IHNlY3Jl dC4gQXMgZGlzY3Vzc2VkIGFib3ZlLCBJJ20gbm90IHN1cmUgdGhhdCdzIGFzIGNsZWFyIGFzIGl0 IG5lZWRzIHRvIGJlLCBhbmQgSSB3ZWxjb21lIHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBjbGFyaWZ5 IHRoaXMuDQoNCg0KDQpBZ2FpbiwgdGhhbmtzIGZvciB0aGUgdmVyeSB0aG9yb3VnaCByZWFkIHRo cm91Z2guIEhhdmUgeW91IGltcGxlbWVudGVkIGFueSBvZiB0aGUgc3BlYyB5ZXQsIGVpdGhlciBh cy1pcyBvciB3aXRoIGFueSBvZiB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2VzPw0KDQpZZXMuIE11Y2gg b2YgdGhlIGZlZWRiYWNrIGlzIGNvbWluZyBmcm9tIG91ciBkZXZlbG9wbWVudCBjb21tdW5pdHku DQoNCkFoLCB2ZXJ5IGNvb2wuIERldmVsb3BlciBleHBlcmllbmNlIGlzIHRoZSBtb3N0IHZhbHVh YmxlIGZlZWRiYWNrLCBpbiBteSBvcGluaW9uLiBJZiB5b3UgY2FuJ3QgYWN0dWFsbHkgYnVpbGQg dGhlIGJsYXN0ZWQgdGhpbmcsIHdoYXQgZ29vZCBpcyBpdD8gOikNCg0KDQogLS0gSnVzdGluDQo= --_000_8EFC75650E8146889AEB459E7503F609mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE1heSAxNSwg MjAxMywgYXQgMTA6MzAgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZu YnNwO3dyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+T24gMjAxMy0wNS0xNSwgYXQgNTo1 MyBQTSwgUmljaGVyLCBKdXN0aW4gUC4gd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NClBoaWwsIG1hbnkgdGhhbmtzIGZv ciB0aGUgZXh0cmVtZWx5IHRob3JvdWdoIHJldmlldyEgSXQgaXMgdmVyeSB1c2VmdWwgaW5kZWVk LiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgY29tbWVudHMgYW5kIHJlc3BvbnNl cyB0byBlYWNoIHBvaW50IGFyZSBpbmxpbmUuJm5ic3A7DQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2 Pk9uIE1heSAxNSwgMjAxMywgYXQgNDozMCBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj4NCjxkaXY+DQo8ZGl2Pkl0IHNlZW1zIHVuZm9ydHVuYXRlIHRoYXQgSSBoYXZlIG5v dCBnb3R0ZW4gYSBjaGFuY2UgdG8gZ2V0IGludG8gdGhpcyBsZXZlbCBvZiBkZXRhaWwgbXVjaCBl YXJsaWVyLiBCdXQgdGhlbiwgSSBndWVzcyB0aGF0J3Mgd2hhdCBMQyByZXZpZXcgaXMgZm9yISBN eSBhcG9sb2dpZXMgZm9yIG5vdCBnZXR0aW5nIG1hbnkgb2YgdGhlc2UgY29uY2VybnMgdG8gdGhl IFdHIG11Y2ggZWFybGllci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ PGI+PGk+T3ZlcmFsbCAmbmJzcDs8L2k+PC9iPjwvZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLTwvZGl2 Pg0KPGRpdj5JIHRoaW5rIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGlzIGEgY3JpdGljYWwgcGFydCBv ZiB0aGUgT0F1dGggZnJhbWV3b3JrIG5vdyB0aGF0IHdlIGFyZSBzdGFydGluZyB0byBjb25zaWRl ciBob3cgaW5kaXZpZHVhbCBjbGllbnQgYXBwbGljYXRpb25zIHNob3VsZCBvcGVyYXRlIHdoZW4g dGhlcmUgaXMgb25lIG9yIG1vcmUgZGVwbG95bWVudHMgb2YgYSBwYXJ0aWN1bGFyIHJlc291cmNl IEFQSS4gV2UndmUgbW92ZWQgZnJvbSB0aGUgc2ltcGxlDQogdXNlIGNhc2Ugb2YgYSBzaW5nbGUg QVBJIHByb3ZpZGVyIGxpa2UgRmFjZWJvb2sgb3IgRmxpY2tyIGFuZCBtb3ZlZCBvbiB0byBzdGFu ZGFyZHMgYmFzZWQsIG9wZW4gc291cmNlIGJhc2VkLCBhbmQgY29tbWVyY2lhbCBiYXNlZCBkZXBs b3ltZW50cyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgc2VydmljZSBlbmRwb2ludHMgYW5kIG1h bnkgY2xpZW50cyB0byBtYW5hZ2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUg ZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBpcyBhY3R1YWxseSBkZWFsaW5nIHdpdGggYSBjb3Vw bGUgb2YgaXNzdWVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBtYWRlIG1vcmUgY2xlYXIgaW4g ZWFybHkgcGFydCBvZiB0aGUgc3BlYzo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjEu ICZuYnNwO0hvdyBpcyBhIG5ldyBjbGllbnQgYXBwbGljYXRpb24gcmVjb2duaXplZCBmb3IgdGhl IGZpcnN0IHRpbWUgd2hlbiBkZXBsb3llZCBhZ2FpbnN0IGEgcGFydGljdWxhciBTUCBlbmRwb2lu dD8gJm5ic3A7U2hvdWxkIGNsaWVudHMgYWN0dWFsbHkgYXNzZXJ0IGFuIGFwcGxpY2F0aW9uX2lk IFVVSUQgdGhhdCBuZXZlciBjaGFuZ2VzIGFuZCBwb3NzaWJseSBhIHZlcnNpb24gaWQgdGhhdCBk b2VzIGNoYW5nZSB3aXRoIHZlcnNpb25zPzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiB0aGUgZ2VuZXJhbCBjYXNlLCB3aHkgaXMgYW55IHJl Y29nbml0aW9uIHJlcXVpcmVkPyBJZiB5b3UncmUgZG9pbmcgdGhpbmdzIGFzIHBhcnQgb2YgYSBs YXJnZXIgcHJvdG9jb2wgZWNvc3lzdGVtLCBsaWtlIEJsdWUgQnV0dG9uJiM0Mzsgb3IgYSBwYXJ0 aWN1bGFyIE9wZW5JRCBDb25uZWN0IHByb3ZpZGVyLCB0aGVuIHlvdSBjYW4gZGVmaW5lIHNlbWFu dGljcyBmb3IgdHlpbmcgdG9nZXRoZXIgY2xhc3NlcyBvZiBjbGllbnRzIChzZWUgYmVsb3cNCiBm b3IgbW9yZSBkaXNjdXNzaW9uIG9uIHRoaXMgdmVyeSBwb2ludCkuIEJ1dCBpbiBnZW5lcmFsLCBh IGNsaWVudCBpcyBqdXN0IGdvaW5nIHRvIHNob3cgdXAgYXMgYSBuZXcgaW5zdGFuY2UgdG8gdGhl IEFTIGFuZCBnZXQgaXNzdWVkIGEgbmV3LCB1bmlxdWUgY2xpZW50X2lkLCBhbmQgdGhhdCdzIHRo YXQuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpJIHRoaW5rIHdlIGhhdmUgdG8gZGVmaW5lIG1vcmUg Y2xlYXJseSB3aGF0IGFuICZxdW90O2luc3RhbmNlJnF1b3Q7IGlzLiBGb3IgbWUsIHRoZXJlIGFy ZSBhcHBsaWNhdGlvbnMgYW5kIHRoZXJlIGFyZSBpbnN0YW5jZXMgb2YgdGhhdCBhcHBsaWNhdGlv bi4gJm5ic3A7SXQgaXMgdXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhhdCBhIGNsaWVudCBhcHBsaWNh dGlvbiByZXByZXNlbnRzIGEgc2V0IG9mIGNvZGUgdGhhdCBzaG91bGQgYmVoYXZlIGluIGEgY29u c2lzdGVudCB3YXkuDQogJm5ic3A7SXQgc2VlbXMgdG8gbWUgdGhlIGZpcnN0IHRpbWUgYSBuZXcg YXBwbGljYXRpb24gc2hvd3MgdXAgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSB0aGUgc3Vic2VxdWVu dCBpbnN0YW5jZXMgdGhhdCByZWdpc3Rlci4gRm9yIGV4YW1wbGUsIGFmdGVyIHRoZSBmaXJzdCBy ZWdpc3RyYXRpb24sIHN1YnNlcXVlbnQgaW5zdGFuY2VzIGRvbid0IG5lZWQgc3BlY2lhbCByZXZp ZXcgb3IgYXBwcm92YWwgdG8gdGhlIHNhbWUgZGVncmVlLjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJ1dCB3aXRob3V0 IG90aGVyIG1lY2hhbmlzbXMgdG8gdGllIHRoaW5ncyB0b2dldGhlciwgdGhlcmUncyBubyB3YXkg Zm9yIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGtub3cgaWYgYW55IGNsaWVudCBpbnN0YW5j ZSBpcyB0aWVkIHRvIGFueSBvdGhlciBjbGllbnQgaW5zdGFuY2UuIFRoZXJlZm9yZSwgZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgYW4gQVMsIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiBhbiBhcHBsaWNh dGlvbiAoaS5lLiwgcGFydGljdWxhcg0KIGNvbmZpZ3VyYXRpb24gb2YgYSBzZXQgb2YgY29kZSkg dG8gcmVnaXN0ZXIgaXMgbm8gZGlmZmVyZW50IHRvIHN1YnNlcXVlbnQgaW5zdGFuY2VzIG9mIHRo YXQgc2FtZSBhcHBsaWNhdGlvbi4gSG93IHdlcmUgeW91IGVudmlzaW9uaW5nIGFuIEFTIGtub3dp bmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZmlyc3QgYW5kIHN1YnNlcXVlbnQgaW5zdGFu Y2VzIG9mIGFuIGFwcGxpY2F0aW9uLCBzcGVjaWZpY2FsbHk/IElmIHRoZXJlJ3MgYW4gJnF1b3Q7 YXBwbGljYXRpb25faWQmcXVvdDsNCiBsaWtlIHlvdSBtZW50aW9uIGFib3ZlLCBJIHRoaW5rIGl0 IHJhaXNlcyBtb3JlIHF1ZXN0aW9ucyB0aGFuIGl0IHJlc29sdmVzOiBXaG8gaXNzdWVzIHRoZSBh cHBsaWNhdGlvbl9pZCwgc29tZSBzZXJ2ZXIgb3IgdGhlIGFwcGxpY2F0aW9uIGl0c2VsZj8gSXMg aXQgdmFsaWRhdGVkIGF0IGFsbD8gU2hvdWxkIGl0IGJlIGNvbnNpZGVyZWQgc2VjcmV0PyBXaGF0 IGhhcHBlbnMgd2hlbiBzb21lb25lIHNpbXBseSBzdGVhbHMgYW4gYXBwbGljYXRpb25faWQ/DQog RG9lcyBhbiBBUyBoYXZlIHRvIGRvIGFueXRoaW5nIHRvIGNoZWNrIHdpdGggYW55IG90aGVyIEFT IHRvIHNlZSBpZiB0aGUgYXBwbGljYXRpb25faWQgaGFzIGFscmVhZHkgYmVlbiB1c2VkIGVsc2V3 aGVyZT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG8gYWdyZWUgdGhhdCBhIGRp c2N1c3Npb24gb2YgJnF1b3Q7aW5zdGFuY2UgdnMuIGFwcGxpY2F0aW9uJnF1b3Q7IHdvdWxkIGJl IGhlbHBmdWwgaW4gY2xlYXJpbmcgdGhpcyB1cCwgSSdsbCBtYWtlIGEgbm90ZSB0byBhZGQgdGV4 dCB0byB0aGF0IGVmZmVjdC4gKFdlIGhhZCB0byBkbyBzb21ldGhpbmcgc2ltaWxhciBmb3IgQkIm IzQzOyk8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7ICI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Mi4g Jm5ic3A7SG93IGFyZSBjbGllbnQgY3JlZGVudGlhbHMgbWFuYWdlZC4gQXJlIHdlIGFzc3VtaW5n IGNsaWVudCBjcmVkZW50aWFscyBoYXZlIGEgbGltaXRlZCBsaWZldGltZSBvciByb3RhdGlvbiBw b2xpY3k/PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpU aGUgaW50ZW50IHdhcyB0aGF0IGNsaWVudF9zZWNyZXQgY291bGQgYmUgcm90YXRlZCwgYXMgaW5k aWNhdGVkIGJ5IHRoZSBleHBpcmVzX2F0IG1lbWJlciBvZiB0aGUgcmVzcG9uc2UuIElmIGEgY2xp ZW50J3Mgc2VjcmV0IGV4cGlyZXMsIGl0IGNhbGxzIHRoZSByZWFkIG9wZXJhdGlvbiBvbiB0aGUg Q2xpZW50IENvbmZpZ3VyYXRpb24gRW5kcG9pbnQgKMKnNC4yKSB0byBnZXQgaXRzIG5ldyBjbGll bnRfc2VjcmV0LiBJZiB0aGlzIGlzIHVuY2xlYXINCiBpbiB0aGUgY3VycmVudCB0ZXh0ICh3aGlj aCBJIHN1c3BlY3QgaXQgbWF5IGJlIGFmdGVyIG11bHRpcGxlIHJlZmFjdG9yaW5ncyksIHRoZW4g SSB3ZWxjb21lIHN1Z2dlc3Rpb25zIGFuZCBzcGVjaWZpYyB0ZXh0IGFzIHRvIGhvdyB0byBtYWtl IHRoYXQgY2xlYXIuJm5ic3A7PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQpTb21ldGhpbmcgbGlrZSB0 aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2hvdWxkIHRoaXMgYmUgdXAg aW4gdGhlIGludHJvZHVjdG9yeSB0ZXh0LCBzb21ld2hlcmUgZWxzZSwgb3IgaGF2ZSBpdHMgb3du IHNlY3Rpb24/PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyAiPg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4mbmJzcDsgSG93IGRv ZXMgYSBjbGllbnQgYXV0aGVudGljYXRlIHRoZSBmaXJzdCB0aW1lIGFuZCBzdWJzZXF1ZW50IHRp bWVzIHRvIHRoZSByZWdpc3RyYXRpb24gc2VydmljZT88L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyBhIHNlcGFyYXRlIHF1ZXN0aW9u IGFsbCB0b2dldGhlciwgYXMgaXQgZG9lcyBub3QgaW52b2x2ZSB0aGUgY2xpZW50X3NlY3JldCBv ciBjbGllbnRfaWQgYXQgYWxsLiBSYXRoZXIsIHRoZSBmaXJzdCB0aW1lIHRoZSBjbGllbnQgc2hv d3MgdXAgdG8gdGhlIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlLCBpdCBtYXkgZWl0aGVyOjwvZGl2Pg0K PGRpdj4mbmJzcDsgLSBOb3QgYXV0aGVudGljYXRlIGF0IGFsbCAodGhpcyBpcyB0aGUgdHJ1ZSBw dWJsaWMsIG9wZW4gcmVnaXN0cmF0aW9uLCBhbmQgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCBzZXJ2 ZXJzIGRvIHRoaXMpPC9kaXY+DQo8ZGl2PiZuYnNwOy0gQXV0aGVudGljYXRlIHVzaW5nIGFuIE9B dXRoIDIuMCB0b2tlbiAod2hpY2ggQVRNIG1lYW5zIGEgYmVhcmVyIHRva2VuKS4gSG93IHRoZSBj bGllbnQgZ2V0cyB0aGF0IGJlYXJlciB0b2tlbiBhbmQgd2hhdCB0aGUgYmVhcmVyIHRva2VuIG1l YW5zIHRvIHRoZSBBUyBiZXlvbmQgJnF1b3Q7dGhpcyBjbGllbnQgaXMgYXV0aG9yaXplZCB0byBy ZWdpc3RlciZxdW90OyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBzcGVjLCBieSBkZXNpZ24uPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TdWJzZXF1ZW50IHRpbWVzIHRoYXQgdGhlIHNh bWUgcmVnaXN0ZXJlZCBjbGllbnQgKGJ5IHdoaWNoIHdlIG1lYW4gdGhlIHNhbWUgaW5zdGFuY2Ug b2YgYSBjbGllbnQgd2l0aCBhIHBhcnRpY3VsYXIgY2xpZW50X2lkKSBzaG93cyB1cCBhdCB0aGUg cmVnaXN0cmF0aW9uIGVuZHBvaW50IChhY3R1YWxseSwgdGhlIENsaWVudCBDb25maWd1cmF0aW9u IEVuZHBvaW50KSwgaXQgdXNlcyBpdHMgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiB0aGF0DQog aXQgd2FzIGlzc3VlZCBvbiBpbml0aWFsIHJlZ2lzdHJhdGlvbi4gVGhpcyBpcyBhbiBPQXV0aCAy LjAgQmVhcmVyIHRva2VuIHRoYXQgaXMgdW5pcXVlIHRvIHRoZSBjbGllbnQgaW5zdGFuY2UuPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NClNv bWV0aGluZyBsaWtlIHRoaXMgc2hvdWxkIGJlIGluIHRoZSBkcmFmdC48YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PSywg dGhlIGRlZmluaXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gY2FuIGJlIGV4 cGFuZGVkLCBidXQgSSB0aGluayB0aGF0IHRoZSByZXN0IG9mIGl0IGlzIGFscmVhZHkgaW4gdGhl cmUgaW4gwqczLiBJJ2Qgd2VsY29tZSBzdWdnZXN0aW9ucyBvbiB3aGljaCBiaXRzIG9mIHRoaXMg Y291bGQgYmUgbWFkZSBjbGVhcmVyLiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyAiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+My4gJm5ic3A7SG93IGlzIHZlcnNpb25p bmcgb2YgY2xpZW50cyBtYW5hZ2VkPyBTaG91bGQgZWFjaCBuZXcgdmVyc2lvbiBvZiBhIGNsaWVu dCByZXF1aXJlIGEgY2hhbmdlIGluIGNsaWVudCByZWdpc3RyYXRpb24gaW5jbHVkaW5nIHBvc3Np Ymx5IGNoYW5naW5nIGNsaWVudF9pZCBhbmQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbD8gSSBk b24ndCBoYXZlIGEgc3Ryb25nIGZlZWxpbmcsIGJ1dCBpdCBpcyBzb21ldGhpbmcgdGhhdCBpbXBs ZW1lbnRvcnMNCiBzaG91bGQgY29uc2lkZXIuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgdXAgdG8gdGhlIEFTLCByZWFsbHksIGFu ZCBJIGRvbid0IHRoaW5rIHRoYXQgYW55IGdsb2JhbCBwb2xpY3kgd291bGQgZXZlciBmbHkgaGVy ZS4gRXNwZWNpYWxseSBpZiB5b3UgY29uc2lkZXIgdGhhdCB0aGUgZW50aXJlIG5vdGlvbiBvZiAm cXVvdDt2ZXJzaW9uJnF1b3Q7IGlzIG1vcmUgZmx1aWQgdGhlc2UgZGF5cyB0aGFuIGl0IGV2ZXIg aGFzIGJlZW4uIEkgd291bGRuJ3QgbWluZCBhZGRpbmcgYSBkaXNjdXNzaW9uIGluIHRoZSBzZWN1 cml0eQ0KIGNvbnNpZGVyYXRpb25zIGlmIGl0IG1lcml0cyBtZW50aW9uaW5nIHRob3VnaCwgc28g dGhhdCB3ZSBjYW4gaGVscCBib3RoIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBzZXJ2ZXIgZGV2ZWxv cGVycyBpbnN0aXR1dGUgcmVhc29uYWJseSBnb29kIHBvbGljeS48L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCkkgZ3Vlc3MgdGhlIGlzc3VlIGlzIHRoYXQg d2hlbiBhIGNsaWVudCB1cGdyYWRlcyBpdCBtYXkgaGF2ZSBhY2Nlc3MgdG8gdGhlIG9sZCBjcmVk ZW50aWFscy4gV2hhdCBpcyB0aGUgaW50ZW50IHRoZW4gb2YgcmVnaXN0cmF0aW9uLiAmbmJzcDtT aW5jZSB5b3UgaGF2ZSBhbiB1cGRhdGUgYXJlIGNsaWVudHMgZXhwZWN0ZWQgdG8gdXBkYXRlIC9y ZS1yZWdpc3RlciBvciBub3Q/ICZuYnNwO0knbSBub3Qgc3VyZSB0aGlzIGlzIGEgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbg0KIGJ1dCBtb3JlIHBhcnQgb2YgdGhlIHdob2xlIGNoYW5nZSBtYW5hZ2Vt ZW50IGZ1bmN0aW9uIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHN1cHBvcnRzLjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pklm IHlvdXIgdXBncmFkZWQgdmVyc2lvbiBvZiB0aGUgY2xpZW50IHN0aWxsIGhhcyBhY2Nlc3MgdG8g aXRzIG9sZCBjcmVkZW50aWFscywgd2h5IHdvdWxkbid0IGl0IGp1c3QgdXNlIHRob3NlPyBJIGRv bid0IHNlZSBhIHJlYXNvbiBmb3IgZm9yY2luZyBhIHJlLXJlZ2lzdHJhdGlvbi4gTm9yIGRvIEkg c2VlIGFueSB3YXkgdGhhdCBhbiBBUyB3b3VsZCBldmVuIGJlIGFibGUgdG8gdGVsbCB0aGF0IGEg Y2xpZW50IGhhZCBiZWVuIHVwZ3JhZGVkLg0KIEFuIHVwZ3JhZGVkIGNsaWVudCBhbHdheXMgaGFz IHRoZSAqb3B0aW9uKiBvZiByZS1yZWdpc3RlcmluZyBpdHNlbGYgYW5kIGdldHRpbmcgYSBuZXcg Y2xpZW50X2lkLiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj40LiAmbmJzcDtXaGF0IGlzIHRoZSByZWdpc3RyYXRpb24gYWNj ZXNzIHRva2VuPyBXaHkgaXMgaXMgdXNlZD8gV2hhdCBpcyBpdHMgbGlmZS1jeWNsZT8gJm5ic3A7 V2hlbiBpcyBpdCBpc3N1ZWQsIHdoZW4gaXMgaXQgY2hhbmdlZD8gV2hlbiBpcyBpdCBkZWxldGVk PzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5T ZWUgdGhlIHJlc3BvbnNlIGFib3ZlIGFib3ZlIGFuZCB0aGUgZGVmaW5pdGlvbiBpbiDCpzEuMjom bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5SZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuOiBBbiBPQXV0 aCAyLjAgQmVhcmVyIFRva2VuIGlzc3VlZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhy b3VnaCB0aGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludCB3aGljaCBpcyB1c2VkIGJ5IHRo ZSBDbGllbnQgdG8gYXV0aGVudGljYXRlIGl0c2VsZiBkdXJpbmcgcmVhZCwgdXBkYXRlLCBhbmQg ZGVsZXRlIG9wZXJhdGlvbnMuIFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoDQogYSBwYXJ0 aWN1bGFyIENsaWVudC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIHRoaXMgY2FuIGJlIGNsYXJpZmll ZCwgSSB3ZWxjb21lIHRleHQgc3VnZ2VzdGlvbnMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KVGhlIGxhdHRlciBwYXJ0IG9m IDEuMiBkaWRuJ3Qgc2VlbSBsaWtlIHRlcm1pbm9sb2d5IGJ1dCByYXRoZXIgYXJjaGl0ZWN0dXJl IG9yIHBhcnQgb2YgdGhlIGludHJvZHVjdGlvbiB0aGF0IGRlc2NyaWJlcyB3aGF0IHRoZSBzcGVj IGRvZXMuIFRoZSB0aGlyZCBwb2ludCBkb2Vzbid0IHNlZW0gdG8gZml0IHdpdGggdGhlIG90aGVy IHR3byBleGNlcHQgdG8gc2F5IHRoYXQgdGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGVuZHBvaW50 cyB1c2UgdGhlaXINCiBvd24gYWNjZXNzIHRva2VucyBjYWxsZWQgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9Im5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IC13 ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93 czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyAiPkNsaWVudCBSZWdpc3RyYXRpb24gRW5k cG9pbnQ6IFRoZSBPQXV0aCAyLjAgRW5kcG9pbnQgdGhyb3VnaCB3aGljaA0KICAgICAgYSBDbGll bnQgY2FuIHJlcXVlc3QgbmV3IHJlZ2lzdHJhdGlvbi4gIFRoZSBtZWFucyBvZiB0aGUgQ2xpZW50 DQogICAgICBvYnRhaW5pbmcgdGhlIFVSTCBmb3IgdGhpcyBlbmRwb2ludCBhcmUgb3V0IG9mIHNj b3BlIGZvciB0aGlzDQogICAgICBzcGVjaWZpY2F0aW9uLg0KDQogICBvICBDbGllbnQgQ29uZmln dXJhdGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIuMCBFbmRwb2ludCB0aHJvdWdoDQogICAgICB3 aGljaCBhIHNwZWNpZmljIENsaWVudCBjYW4gbWFuYWdlIGl0cyByZWdpc3RyYXRpb24gaW5mb3Jt YXRpb24sDQogICAgICBwcm92aWRlZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gdGhl IENsaWVudC4gIFRoaXMgVVJMIGZvcg0KICAgICAgdGhpcyBlbmRwb2ludCBpcyBjb21tdW5pY2F0 ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbg0KICAgICAgU2VydmVyIGluIHRo ZSBDbGllbnQgSW5mb3JtYXRpb24gUmVzcG9uc2UuDQoNCiAgIG8gIFJlZ2lzdHJhdGlvbiBBY2Nl c3MgVG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVkIGJ5IHRoZQ0KICAgICAg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhyb3VnaCB0aGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRw b2ludA0KICAgICAgd2hpY2ggaXMgdXNlZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0ZSBp dHNlbGYgZHVyaW5nIHJlYWQsDQogICAgICB1cGRhdGUsIGFuZCBkZWxldGUgb3BlcmF0aW9ucy4g IFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoIGENCiAgICAgIHBhcnRpY3VsYXIgQ2xpZW50 LjwvcHJlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgc2VjdGlvbiBpcyBtZWFudCB0 byBqdXN0IGludHJvZHVjZSB0aGUgbmV3IHRlcm1zIHRoYXQgYXJlIHRoZW4gZXhwbGFpbmVkIGlu IGdyZWF0ZXIgZGV0YWlsIHRocm91Z2hvdXQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBZZXMs IGl0J3MgYSBiaXQgYXJjaGl0ZWN0dXJlLCBidXQgb25seSBpbiB0aGUgc2Vuc2UgdGhhdCB5b3Ug bmVlZCB0byBkZWZpbmUgdGhlIHRlcm1zIHRoYXQgbWFrZSB1cCB5b3VyIGFyY2hpdGVjdHVyZS4g SG93DQogd291bGQgeW91IHN1Z2dlc3QgdGhhdCBpdCBjaGFuZ2U/PC9kaXY+DQo8YnI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsg Ij4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB3ZSBk aXN0aW5ndWlzaCBiZXR3ZWVuIGZpcnN0IHRpbWUgcmVnaXN0cmF0aW9uIG9mIGEgcGFydGljdWxh ciBjbGllbnQgc29mdHdhcmUgcGFja2FnZSwgaXQgaXMgcG9zc2libGUgdGhhdCBzb21ldGhpbmdz IGxpa2UgYXV0aGVudGljYXRpb24gbWV0aG9kIGNhbiBiZSBuZWdvdGlhdGUgaW4gb3Igb3V0LW9m LWJhbmQgYXQgdGhhdCB0aW1lLiBTdWJzZXF1ZW50IHJlZ2lzdHJhdGlvbnMgc2hvdWxkIG9ubHkg aGF2ZSBwYXJhbWV0ZXJzIGZvcg0KIGl0ZW1zIHRoYXQgY291bGQgY2hhbmdlIHBlciBkZXBsb3lt ZW50IChsaWtlIHRvc191cmkpLiAmbmJzcDtJIHRoaW5rIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0 aG9kIGlzIG9uZSB0aGluZyB0aGF0IHNob3VsZCBub3QgYmUgbmVnb3RpYXRlZCBwZXIgaW5zdGFu Y2UuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQpXaGVuIHN1YnNlcXVlbnQgaW5zdGFuY2VzIHJlZ2lz dGVyLCBJIGhhdmUgdG8gYXNrIHRoZSBxdWVzdGlvbiwgZm9yIGV4YW1wbGUgd2hlbiB3b3VsZCB0 aGluZ3MgbGlrZSAmcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCZxdW90OyBiZSBuZWdv dGlhdGVkIG9yIGJlIGRpZmZlcmVudCBmb3IgdGhlIHNhbWUgY2xpZW50IHNvZnR3YXJlPyBTaG91 bGQgbm90IGFsbCBpbnN0YW5jZXMgdXNlIHRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC48 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj5JJ20gY29uZnVzZWQgYnkgdGhpcyAtLSBhcyBmYXIgYXMgdGhlIGR5bmFtaWMgcmVnaXN0 cmF0aW9uIHNwZWMgaXMgY29uY2VybmVkLCBhbGwgaW5zdGFuY2VzIGFyZSBzZXBhcmF0ZSBmcm9t IGVhY2ggb3RoZXIuIEFsbCBwYXJhbWV0ZXJzIGNoYW5nZSBwZXIgaW5zdGFuY2UuIEFuZCBpbnN0 YW5jZSwgeW91IHNob3VsZCBrZWVwIGluIG1pbmQsIGlzIGRlZmluZWQgYXMgYW55IG9uZSBjb3B5 IG9mIHRoZSBjbGllbnQgY29kZSBjb25uZWN0aW5nDQogdG8gYW55IG5ldyBhdXRob3JpemF0aW9u IHNlcnZlci4gVGhhdCBwYWlyaW5nIGNyZWF0ZXMgdGhlIGNsaWVudF9pZCwgYW5kIHRoZXJlZm9y ZSB0aGUgaW5zdGFuY2UsIGFuZCB0aGVyZWZvcmUgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9r ZW4sIGFuZCB0aGVyZWZvcmUgdGhlIHJlZ2lzdHJhdGlvbiBpdHNlbGYgYXQgYSBjb25jZXB0dWFs IGxldmVsLiBTbyB0aGVyZSBpcyBubyB3YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9yIGEg Y2xpZW50DQogdG8gYXNrIGZvciBhIHBhcnRpY3VsYXIgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRo b2QuIFdoZXJlIGVsc2Ugd291bGQgdGhlIEFTIGZpbmQgb3V0IGFib3V0IGl0Pw0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIHN0aWxsIGRp c2FncmVlIG9uIHRoaXMuIEl0IGlzIG15IGFzc2VydGlvbiB0aGF0IGNsaWVudHMgc2hvdWxkIE5F VkVSIGFzayBmb3IgYSBwYXJ0aWN1bGFyIHRva2VuIGF1dGggbWV0aG9kLiBTaW5jZSBpdCBpcyB0 aGUgQVMgdGhhdCBpcyBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LCB0aGVuIGl0IGlzIHRoZSBB UydzIHJpZ2h0IHRvIHNldCB0aGUgYXV0aGVudGljYXRpb24gcG9saWN5LiAmbmJzcDtUaGUgcm9s ZSBvZiBkeW5hbWljIHJlZyBlbmRwb2ludA0KIGlzIHRvIGluZm9ybSB0aGUgY2xpZW50IHdoYXQg aXQgbXVzdCBkby4gJm5ic3A7TXkgYXNzdW1wdGlvbiBpcyB0aGF0IGR1cmluZyB0aGUgZmlyc3Qg dGltZSBhIHBpZWNlIG9mIHNvZnR3YXJlIGlzIHJlZ2lzdGVyZWQgKHRoZSBmaXJzdCBpbnN0YW5j ZSksIHRoZXJlIGNvdWxkIGJlIHNvbWUgT09CIGRpc2N1c3Npb24gYnkgYW4gYWRtaW5pc3RyYXRv ciB0byBhcHByb3ZlIHRoZSBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0aW9uIHR5cGUgZm9yIHRoZSBB UyBpbg0KIHF1ZXN0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBoYXZlbid0 IGhlYXJkIGEgcmVhc29uIGp1c3RpZnlpbmcgdGhpcyBwYXJhbWV0ZXIgb3RoZXIgdGhlbiAmcXVv dDtpdCBpcyBuZWVkZWQmcXVvdDsuICZuYnNwO1doeT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSByb2xlIG9m IHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBwcm90b2NvbCBpcyB0d29mb2xkOiBoYWxmIG9mIHRo YXQgaXMgdGhlIHNlcnZlciBpbmZvcm1pbmcgdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgZG8uIEJ1 dCB0aGUgb3RoZXIgaGFsZiBpcyB0aGUgY2xpZW50IGluZm9ybWluZyB0aGUgc2VydmVyIHdoYXQg aXQgKmNhbiogZG8sIG9yIHdoYXQgaXQgKndhbnRzKiB0byBkby4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkFuZCBhZ2FpbiwgdGhlcmUncyBubyB3YXkgdG8gZGlzdGluZ3Vp c2ggYSBmaXJzdCBpbnN0YW5jZSBmcm9tIGEgc3Vic2VxdWVudCBpbnN0YW5jZSB1bmxlc3MgeW91 J3JlIGRvaW5nIHNvbWV0aGluZyBpbiBhZGRpdGlvbi4gTm90aGluZyBpcyBzdG9wcGluZyB0aGUg c2FtZSBhcHBsaWNhdGlvbiBmcm9tIHJlZ2lzdGVyaW5nIGEgbmV3IGluc3RhbmNlIG9mIGl0c2Vs ZiBmb3IgZXZlcnkgc2luZ2xlIHVzZXIgb3IgZXZlcnkgc2luZ2xlIHRva2VuDQogdGhhdCBpdCB3 YW50cyB0byBnZXQgYWNjZXNzIGZvci4gVGhhdCdzIGNvbXBsaWNhdGVkIGFuZCB3YXN0ZWZ1bCBh bmQgbm90IGEgZ3JlYXQgaWRlYSwgc3VyZSwgYnV0ICZuYnNwO3RoZXJlJ3Mgbm8gdXNlZnVsIHdh eSB0byBwcmV2ZW50IHRoYXQga2luZCBvZiBiZWhhdmlvciBpZiB5b3UgYWxzbyB3YW50IG9wZW4g cmVnaXN0cmF0aW9uIG9mIGNsaWVudHMuJm5ic3A7PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+ QW5kIHRoZXJlJ3Mgbm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNlIGZvciB0aGUgc2VydmVy IHRvIHRlbGwgdGhlIGNsaWVudCB3aGljaCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCB0byB1 c2UuIEFsbCBpbnN0YW5jZXMgd2lsbCBwcm9iYWJseSBhc2sgZm9yIHRoZSBzYW1lIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kIGZyb20gYWxsIGF1dGggc2VydmVycyB0aGV5IHRhbGsgdG8sIHJp Z2h0PyBBbmQgZWFjaCBBUyB3aWxsIHRlbGwNCiBlYWNoIGluc3RhbmNlIHRoYXQgcmVnaXN0ZXJz IHdpdGggaXQgdG8gdXNlIGEgcGFydGljdWxhciBhdXRoIG1ldGhvZC4gVGhlcmUgaXMgbm8gd2F5 IHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIGFjcm9zcyAob3Igd2l0aGluKSBh dXRoIHNlcnZlcnMgd2l0aG91dCBzcGVjaWZ5aW5nIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIG90 aGVyIG1hY2hpbmVyeS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoaWNoIGlzIG5v dCB0byBzYXkgdGhhdCBpdCdzIG5vdCB1c2VmdWwgaW4gc29tZSBjaXJjdW1zdGFuY2VzIHRvIHRp ZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIGNvZGUgYWNyb3NzIChv ciB3aXRoaW4pIGF1dGggc2VydmVycy4gVGhpcyBpcyB3aHksIHdpdGggQmx1ZSBCdXR0b24mIzQz Oywgd2Ugc3BlY2lmaWVkIGEgc3BlY2lmaWMgdG9rZW4gZm9ybWF0IGZvciB0aGUgaW5pdGlhbCBh Y2Nlc3MgdG9rZW4gdGhhdA0KIHRoZSBjbGllbnRzIHVzZSB0byBjYWxsIHRoZSByZWdpc3RyYXRp b24gZW5kcG9pbnQgdGhlIGZpcnN0IHRpbWUsICZuYnNwO2FzIHdlbGwgYXMgYSBkaXNjb3Zlcnkg cHJvdG9jb2wgYWdhaW5zdCBhIGNlbnRyYWxpemVkIHNlcnZlciB0aGF0IGhhbmRsZXMgcHJlLXJl Z2lzdHJhdGlvbi4gQWxsIG9mIHRoaXMgbWFjaGluZXJ5IGlzLCBpbiBteSBvcGluaW9uLCBhIHN0 dXBlbmRvdXMgb3ZlcmtpbGwgZm9yIHRoZSBnZW5lcmFsIGNhc2UsIHRob3VnaCBpZiBzb21lDQog Zm9sa3MgZmluZCB1c2UgZm9yIGl0IG91dHNpZGUgb2YgQkImIzQzOyB0aGVuIGl0J2QgYmUgYSBn b29kIHRoaW5nIHRvIGFic3RyYWN0IG91dCBhbmQgbWFrZSBpdHMgb3duIHNwZWMgdGhhdCBleHRl bmRzIHRoZSBEeW4gUmVnIHNwZWMgaW4gYSBmdWxseSBjb21wYXRpYmxlIHdheS4gRnVydGhlcm1v cmUsIGV2ZW4gaW4gQmx1ZSBCdXR0b24mIzQzOyB3ZSBzcGVjaWZ5IHRoYXQgYWxsIGF1dGggc2Vy dmVycyBNVVNUIGFsc28gYWNjZXB0IG9wZW4gcmVnaXN0cmF0aW9uLA0KIHdpdGhvdXQgYW4gaW5p dGlhbCBhY2Nlc3MgdG9rZW4sIHdoZXJlIHRoZSBjbGllbnQgc2ltcGx5IHNob3dzIHVwIGFuZCBz YXlzICZxdW90O2hleSwgaGVyZSBhcmUgbXkgcGFyYW1ldGVycy4mcXVvdDsgVGhlIGF1dGggc2Vy dmVyIGhhcyBubyB3YXkgdG8ga25vdyBpbiB0aGlzIGNhc2UgYW55IGtpbmQgb2Ygb3V0LW9mLWJh bmQgbmVnb3RpYXRpb24gZm9yIGRpZmZlcmVudCB0aGluZ3MuIEluIEJCJiM0Mzsgd2UgYXJlIHdy aXRpbmcgdmVyeSBzcGVjaWZpYyBwb2xpY3kgZ3VpZGVsaW5lcw0KIGFib3V0IGhvdyB0byBwcmVz ZW50IHRoZSBVWCBhbmQgdGhpbmdzIHRvIHRoZSBlbmQgdXNlciBmb3IgYWxsIG9mIHRoZXNlIGRp ZmZlcmVudCBjYXNlcy4gQnV0IGFnYWluLCBhbGwgb2YgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUg QkImIzQzOyB1c2UgY2FzZSwgYW5kIEkgZG9uJ3Qgc2VlIHZhbHVlIGluIGRyYWdnaW5nIGl0IGlu IHRvIHRoZSByZWdpc3RyYXRpb24gc3BlYyBvbiBpdHMgb3duLiBJIGJlbGlldmUgaXQgd291bGQg YmUgZmFyIHRvbyBsaW1pdGluZy48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+RmluYWxseSwgdGhlcmUgc2VlbXMgdG8gYmUgYW4gaW5jb25zaXN0 ZW50IHN0eWxlIGFwcHJvYWNoIHdpdGgmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTAwLnR4dCIgc3R5bGU9InRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBjb2xvcjogcmdiKDY4LCAwLCAxMzYpOyBib3JkZXIt Ym90dG9tLXdpZHRoOiAwcHg7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgdGltZXMs IHNlcmlmOyBmb250LXNpemU6IDE1cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7ICI+ZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVn PC9hPiZuYnNwO3doaWNoDQogdXNlcyBFVGFncy4gU2hvdWxkIHRoaXMgZHJhZnQgZG8gc28gYXMg d2VsbD88L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VGhhdCdzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiwgbm90IGEgd29ya2luZyBncm91cCBk cmFmdC4gTm9ib2R5IGhhcywgdW50aWwgbm93LCBldmVuIG1lbnRpb25lZCB0aGUgdXNlIG9mIEVU YWdzIGhlcmUuIFVNQSAod2hlcmUgdGhlIHJlc291cmNlIHJlZ2lzdHJhdGlvbiBkcmFmdCBjb21l cyBmcm9tKSB1c2VzIEVUYWdzLCBoZW5jZSB0aGVpciBpbmNsdXNpb24gdGhlcmUuIEkgcGVyc29u YWxseSBkb24ndCBzZWUgdGhlaXIgdXRpbGl0eQ0KIGhlcmUsIHRob3VnaCwgYW5kIEkgd291bGRu J3Qgd2FudCB0byBpbmNsdWRlIGEgd2hvbGx5IG5ldyBtZWNoYW5pc20gdGhpcyBsYXRlLjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KWWVzLiBUaG9tYXMn IGRyYWZ0IGlzIG5vdCBhIFdHIGRvY3VtZW50LiBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gaGUgZG9l c24ndCBoYXZlIGEgcG9pbnQuIEl0J3Mgd29ydGggZGlzY3Vzc2luZy4mbmJzcDs8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHRoZSBwb2ludCBvZiBh biBFVGFnIGlzIHRoYXQgaXQgaXMgdXNlZnVsIGZvciBjaGFuZ2UgZGV0ZWN0aW9uIHdoZW4gdGhl cmUgYXJlIG11bHRpcGxlIHdyaXRlcnMgdG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlLiAmbmJzcDtJ biB0aGUgZGVzaWduIG9mIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGVuZHBvaW50LCB0aGVyZSBzaG91 bGQgb25seSBiZSBvbmUgd3JpdGVyIC0tIHRoZSBjbGllbnQuIFRoaXMgaXMgYW4gaW1wb3J0YW50 DQogb2JzZXJ2YXRpb24uPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdGhh dCBoYW5kbGUgdGhpcyAtLSBuYW1lbHksIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGFu ZCB0aGUgY2xpZW50X2lkLiBNYW55IGluc3RhbmNlcyBpbmNsdWRlIHRoZSBjbGllbnRfaWQgaW4g c29tZSBmb3JtIGluIHRoZSBjbGllbnQgY29uZmlndXJhdGlvbiBlbmRwb2ludCdzIFVSTCBmb3Ig c2FuaXR5IGNoZWNraW5nLCBhcyBkZXNjcmliZWQgaW4gwqc0LjEuJm5ic3A7PC9kaXY+DQo8YnI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiPjxpPlNwZWNpZmljIGl0ZW1z OjwvaT48L2I+PC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj48 Yj4mcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCZxdW90OzwvYj48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGFzIHRvIHdoZXRoZXIg dGhpcyBhcHBsaWVzIHRvIHNlcnZlciBvciBjbGllbnQgYXV0aGVudGljYXRpb24uICZuYnNwO1N1 Z2dlc3QgcmVuYW1pbmcgcGFyYW1ldGVyIHRvICZxdW90O3Rva2VuX2VuZHBvaW50X2NsaWVudF9h dXRoX21ldGhvZCZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGlzIGlzIHRoZSBmaXJzdCBJJ3ZlIGhlYXJkIG9mIHRoaXMgcGFydGlj dWxhciBjb25mdXNpb24uIEknbSBmaW5lIHdpdGggZWl0aGVyIG5hbWUgYnV0IGF0IHRoaXMgc3Rh Z2UgSSBkb24ndCB3YW50IHRvIG1ha2Ugc3ludGF4IGNoYW5nZXMgd2l0aG91dCB2ZXJ5LCB2ZXJ5 IGNvbXBlbGxpbmcgcmVhc29ucyB0byBkbyBzby48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHF1ZXN0aW9uIHdhcyByYWlzZWQgdG8gbWUg Ynkgc29tZSBuZXcgZGV2ZWxvcGVycy4gSXQgc2VlbXMgb2J2aW91cyB0byB1cyBhcyBleHBlcmll bmNlZCBPQXV0aCBwZXJzb25zLCBidXQgdG8gbmV3IGRldmVsb3BlcnMgaXQgc2VlbXMgdW5jbGVh ci4gJm5ic3A7QWxzbywgbm93IHRoYXQgeW91IGFyZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRpb24g YXV0aGVudGljYXRpb24sIHRoZSB3aG9sZSB0aGluZyBnZXRzIHZlcnkgY29uZnVzaW5nLiBTbw0K IGl0IGlzIHVzZWZ1bCBkaXNhbWJpZ3VhdGUgYWxsIHRoZSBwYXJhbWV0ZXJzIHdoZXJlIHBvc3Np YmxlLiAmbmJzcDtUaGF0IHNhaWQsIEkgd291bGRuJ3QgbWluZCBzaG9ydGVyIG5hbWVzIChtYXli ZSBub3QgcXVpdGUgYXMgc2hvcnQgYXMgdGhlIEpPU0Ugc3R1ZmYgOy0pPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5G YWlyIGVub3VnaCwgYnV0IGFnYWluLCBJIG9ubHkgd2FudCB0byBkbyBzeW50YXggY2hhbmdlcyBp ZiB0aGUgcmVzdCBvZiB0aGUgV0cgKnJlYWxseSogd2FudHMgdG8uJm5ic3A7PC9kaXY+DQo8YnI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiogQ3VycmVudGx5LCB0aGUgQVBJ IG9ubHkgc3VwcG9ydHMgYSBzaW5nbGUgdmFsdWUgaW5zdGVhZCBvZiBhbiBhcnJheS4gJm5ic3A7 SWYgdGhlIHB1cnBvc2UgaXMgdG8gYWxsb3cgdGhlIGNsaWVudCB0byBrbm93IHdoYXQgYXV0aCBt ZXRob2RzIGl0IHN1cHBvcnRzLCB0aGlzIHNob3VsZCBiZSBhbiBhcnJheSBpbmRpY2F0ZWQgd2hh dCBtZXRob2RzIHRoZSBjbGllbnQgc3VwcG9ydHMgLSBvciBpdCBzaG91bGQgbm90IGJlIHVzZWQu PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkg d291bGQgcmF0aGVyIGxpa2UgdGhpcyB0byBiZSBhbiBhcnJheSwgcGVyc29uYWxseSwgYW5kIGJy b3VnaHQgaXQgdXAgd2l0aCB0aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBhYm91dCBz aXggbW9udGhzIGFnby4gQnV0IHRoZXJlIGl0IHdhcyBkZWNpZGVkIHRoYXQgYSBzaW5nbGUgdmFs dWUgd2FzIHNpbXBsZXIgYW5kIHN1ZmZpY2llbnQgZm9yIHRoZSBwdXJwb3NlLiBUaGUgSUVURiBk cmFmdCBoYXMgaW5oZXJpdGVkIHRoaXMNCiBkZWNpc2lvbi4gSSAqYmVsaWV2ZSogKHRob3VnaCBh bSBub3QgMTAwJSBwb3NpdGl2ZSkgdGhhdCBJIGJyb3VnaHQgdXAgdGhpcyB2ZXJ5IGlzc3VlIGlu IHRoZSBXRyBoZXJlIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhbnkgdHJhY3Rpb24gb24gaXQsIHNvIHNp bmdsZSBpdCByZW1haW5zLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KSSBjYW4gZ2V0IGJlaGluZCBtdWx0aXBsZSB2YWx1ZXMuIEluIHRoaXMgY2FzZSwg aXQgY2hhbmdlcyB0aGUgbWVhbmluZyBvZiB0aGUgcGFyYW1ldGVyLiBJbnN0ZWFkIG9mIHRoZSBj bGllbnQgZm9yY2luZyB0aGUgc2VydmVyIHRvIHVzZSBhIHBhcnRpY3VsYXIgbWV0aG9kLCB0aGUg Y2xpZW50IGlzIGluZm9ybWluZyB0aGUgc2VydmVyIGFib3V0IHdoYXQgbWV0aG9kcyBpdCBjYW4g cGVyZm9ybS4gVGhpcyBhbGxvd3MgdGhlIHNlcnZlciB0byBhc3NpZ24NCiB0aGUgYXBwcm9wcmlh dGUgbWV0aG9kIGJhc2VkIG9uIGl0cyBvd24gcG9saWN5Ljxicj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbHNvIG5vdGUgdGhhdCB0aGlzIGZpZWxkLCBsaWtlIGFs bCBvdGhlcnMgaW4gwqcyLCByZXByZXNlbnRzIHR3byB0aGluZ3M6IHRoZSBjbGllbnQgdGVsbGlu ZyB0aGUgc2VydmVyICZxdW90O0kgd2FudCB0byB1c2UgdGhpcyB2YWx1ZSBmb3IgdGhpcyBmaWVs ZCZxdW90OywgYW5kIHRoZSBzZXJ2ZXIgdGVsbGluZyB0aGUgY2xpZW50ICZxdW90O3RoaXMgaXMg dGhlIHZhbHVlIHlvdSBoYXZlIGZvciB0aGlzIGZpZWxkJnF1b3Q7LiBJdCdzIG5vdCBleGFjdGx5 IGEgbmVnb3RpYXRpb24sDQogbW9yZSBsaWtlIG1ha2luZyBhIHBvbGl0ZSByZXF1ZXN0IHRvIGFu IGFic29sdXRlIGRpY3RhdG9yIHdobyBoYXMgdGhlIGxhc3Qgd29yZCBhbnl3YXkuIEJ1dCBhdCBs ZWFzdCB0aGlzIGRpY3RhdG9yIGlzIG5pY2UgZW5vdWdoIHRvIHRlbGwgeW91IHdoYXQgdGhlaXIg ZGVjaXNpb24gd2FzIGluc3RlYWQgb2YganVzdCBkZWNhcGl0YXRpbmcgeW91LjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KVGhpcyBpcyB0aGUgaGVhcnQg b2YgbXkgb2JqZWN0aW9uLiBUaGlzIGZ1enppbmVzcyBpcyBpcyBnb2luZyB0byBsZWFkIHRvIGlu dGVyb3AgaXNzdWVzLjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIG5vIGZ1enppbmVzcyB0aGF0IEkgY2Fu IHNlZSBoZXJlLiBJdCdzIHBhcmFsbGVsaXNtIGJldHdlZW4gd2hhdCBnb2VzIGluIHRvIHRoZSBl bmRwb2ludCBhbmQgd2hhdCBjb21lcyBvdXQgb2YgaXQuIFRoZSBzZW1hbnRpY3MgZm9yIHRoZSBy ZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UgYXJlIGRpZmZlcmVudCwgYW5kIGRpZmZlcmVudGlhYmxl IGJ5IHRoZSBmYWN0IHRoYXQgb25lIGlzIGEgcmVxdWVzdCBhbmQgdGhlIG90aGVyDQogaXMgYSBy ZXNwb25zZS4mbmJzcDs8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+KiBUaGVyZSBpcyBubyBhdXRobiBtZXRob2QgZm9yICZxdW90O2NsaWVudF9zZWNyZXRf c2FtbCZxdW90OyBvciAmcXVvdDtwcml2YXRlX2tleV9zYW1sJnF1b3Q7LjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ob2JvZHkgaGFzIHJlYWxs eSBhc2tlZCB0aGF0IHRoZXNlIHR3byBiZSBpbmNsdWRlZCBvciBzcGVjaWZpZWQuIFRoZSBleHRl bnNpb24gbWVjaGFuaXNtICh1c2luZyBhbiBhYnNvbHV0ZSBVUkkpIHdvdWxkIGFsbG93IHNvbWVv bmUgZWxzZSB0byBkZWZpbmUgdGhlc2UuIElzIHRoZSBkZWZpbml0aW9uIGluIHRoZSBTQU1MIEFz c2VydGlvbiBkcmFmdCBzdWZmaWNpZW50IGZvciB0aGVpciB1c2U/PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpJIHRoaW5rIHRoaXMgaXMgY29taW5nIGZy b20gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIEpXVCBiZWFyZXIgZHJhZnQgYW5kIGEgU0FNTCBi ZWFyZXIgZHJhZnQuICZuYnNwO1RoZSB0cnV0aCBpcyB5b3UgYXJlIGRlZmluaW5nIGFuIGF1dGhl bnRpY2F0aW9uIHRoYXQgaXNuJ3QgZXZlbiBkZWZpbmVkLjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PjxpPlRoZXJlIGFyZSBubyBwcm9maWxlcyByZWZlcmVuY2VkIG9y IGRlZmluZWQgZm9yICZxdW90O2NsaWVudF9zZWNyZXRfand0JnF1b3Q7IG9yICZxdW90O3ByaXZh dGVfa2V5X2p3dCZxdW90Oy4gTmVpdGhlciBvZiB0aGUgSldUIG9yIFNBTUwgQmVhcmVyIGRyYWZ0 cyByZWZlcmVuY2VkIGNvdmVyIHRoZXNlIHR5cGVzIG9mIGZsb3dzLiBUaGV5IG9ubHkgY292ZXIg YmVhcmVyIGZsb3dzLiAmbmJzcDsmcXVvdDtjbGllbnRfc2VjcmV0X2p3dCZxdW90OyBhbmQgJnF1 b3Q7cHJpdmF0ZV9rZXlfand0JnF1b3Q7IHNlZW0gdG8NCiBoYXZlIHNvbWUgbWVhbmluZyB3aXRo aW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJIG5vdGUgdGhhdCBPSURDIGRvZXMgbm90IGZ1bGx5IGRl ZmluZSB0aGVzZSBlaXRoZXIuPC9pPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgSldUIGFzc2VydGlvbiBkcmFmdCBkb2VzIHNheSBob3cg dG8gdXNlIGEgSldUIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgRHluUmVnIHRl eHQgZGlmZmVyZW50aWF0ZXMgYmV0d2VlbiBhIGNsaWVudCBzaWduaW5nIHNhaWQgSldUIHdpdGgg aXRzIG93biBzZWNyZXQgc3ltbWV0cmljYWxseSB2cy4gYSBjbGllbnQgdXNpbmcgaXRzIG93biBw cml2YXRlIGtleSwgYXN5bW1ldHJpY2FsbHkuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFjdHVhbGx5IG15IGludGVycHJldGF0aW9uIGlzIHRo ZSBKV1QgZHJhZnQgYXNzdW1lcyB0aGUgSldUIEJlYXJlciBpcyBhIGJlYXJlciB0b2tlbi4gJm5i c3A7VGhlIGFzc3VtcHRpb24gaXMgdGhhdCBpZiBhIGNsaWVudCBoYXMgdGhlIGFzc2VydGlvbiBp dCBoYXMgdGhlIHJpZ2h0IHRvIHByZXNlbnQgaXQuICZuYnNwO0lPVy4gVGhlIEpXVCBCZWFyZXIg RHJhZnQgaXMgbW9zdCBkZWZpbml0aXZlbHkgbm90IGEgSldUIEhvSyBEcmFmdC4gJm5ic3A7Oi0p PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRsZXNzLCB5b3UgYXJlIGludHJv ZHVjaW5nIGEgbmV3IHByb2ZpbGUgd2hpY2ggaXMgdW5kZWZpbmVkLjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0 aGluayBJIHNlZSB0aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFraW5nIG5vdywgbGV0IG1lIHRyeSB0 byByZS1zdGF0ZSBpdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoaWxlIHRoZSBi YXNpY3Mgb2YgJnF1b3Q7aG93IHRvIHByZXNlbnQgYSBKV1QgYXMgYSBjbGllbnQgY3JlZGVudGlh bCZxdW90OyBpcyBkZWZpbmVkIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wNS5odG1sI3JmYy5zZWN0aW9uLjIu MiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0w NS5odG1sI3JmYy5zZWN0aW9uLjIuMjwvYT4gLA0KIGl0J3Mgbm90IGNvbXBsZXRlbHkgc3BlY2lm aWVkIGluIHRoYXQgaXQgZG9lc24ndCBmdWxseSByZXN0cmljdCB0aGUgc2lnbmF0dXJlIHNlY3Jl dCBzb3VyY2UsIHRoZSBhdWRpZW5jZSBjbGFpbSwgYW5kIG90aGVyIHRoaW5ncyB0aGF0IHRoZSBB UyB3b3VsZCBuZWVkIHRvIGNoZWNrIGFuZCB2YWxpZGF0ZS4gUmlnaHQ/IFRoZSBkeW5hbWljIHJl Z2lzdHJhdGlvbiBkcmFmdCBjYW4gZGVmaW5lIHRob3NlIGNhc2VzIGluIGdyZWF0ZXIgZGV0YWls IGlmDQogbmVlZGVkICh0aG91Z2ggSSB0aGluayBpdCBkb2VzIHNvIHN1ZmZpY2llbnRseSBhcy1p cywgSSB3ZWxjb21lIG1vcmUgY2xhcml0eSkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JJ2QgYmUgT0sgd2l0aCBhZGRpbmcgdGhlIFNBTUwgYml0LCBnb2luZyBpbnRvIGdyZWF0ZXIg ZGV0YWlsIG9uIHRoZSBKV1QgYml0cywgb3IgZHJvcHBpbmcgdGhlIEpXVCBiaXRzLCBpZiB0aGUg V0cgd2FudHMgdG8gZG8gYW55IG9mIHRob3NlIGFjdGlvbnMuIE15IG9iamVjdGlvbiBpcyB0aGF0 IHRoZSBKV1Qgc3R1ZmYgaXMgYWxyZWFkeSBpbiB1c2UgYW5kIGZ1bmN0aW9uaW5nIGFuZCBpdCdk IGJlIGEgc2hhbWUgdG8gbGVhdmUgaXQgb3V0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyAiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgaXMgbm8gYXV0aGVudGljYXRp b24gbWV0aG9kIGRlZmluZWQgZm9yICZxdW90O2NsaWVudF9iZWFyZXJfc2FtbCZxdW90OyBvciAm cXVvdDtjbGllbnRfYmVhcmVyX2p3dCZxdW90OyBvciAmcXVvdDtjbGllbnRfYmVhcmVyX3JlZiZx dW90Oy4gJm5ic3A7U2luY2UgdGhlIGJlYXJlciBzcGVjcyBzYXkgdGhpcyBpcyBhY2NlcHRhYmxl LCAmbmJzcDt0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBzaG91bGQgYWNjZXB0IHRoZXNl LjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J IGRvbid0IHVuZGVyc3RhbmQgdGhpcyBiaXQgLS0gd2hlcmUgYXJlIHRoZXNlIGRlZmluZWQgaW4g UkZDNjc1MD8gSSBkb24ndCBldmVuIGtub3cgd2hhdCBjbGllbnRfYmVhcmVyX3JlZiB3b3VsZCBy ZWZlciB0by48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjY3NTAgc2F5cyB5b3UgY2FuIHVzZSBhIGJlYXJlciBhc3NlcnRpb24gKGUuZy4gb2J0YWluZWQg ZnJvbSBhbiBJRFApIGFuZCB3aWVsZCBpdCBhcyBhbiBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24u ICZuYnNwO1RoZSBjbGllbnQgaXMgTk9UIGNyZWF0aW5nIG9yIG1vZGlmeWluZyB0aGUgYXNzZXJ0 aW9uLiBUaGUgY2xpZW50IGlzIHNpbXBseSBwYXNzaW5nIG9uZSBpdCBwcmV2aW91c2x5IG9idGFp bmVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCB5b3UgYXJlIGRlc2NyaWJp bmcgaXMgbm90IGJlYXJlci4gSXQgaXMgaG9sZGVyIG9mIGtleS4gVmVyeSB2ZXJ5IGRpZmZlcmVu dC4mbmJzcDs8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkEgcG9zc2libGUgc3VnZ2VzdGlvbiBpcyB0byByZW1vdmUgY2xp ZW50X3NlY3JldF9qd3QgYW5kIHByaXZhdGVfa2V5X2p3dCBhbmQgZGVmaW5lIHRob3NlIGFzIHJl Z2lzdGVyIGV4dGVuc2lvbnMgc2luY2UgdGhlc2UgcHJvZmlsZXMgYXJlIG5vdCBkZWZpbmVkLjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0 J3MgcG9zc2libGUsIGJ1dCB0aGV5IGFyZSBpbiBhY3RpdmUgdXNlIGFscmVhZHkuJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpUaGF0IG1heSBi ZSB0cnVlLiBCdXQgdGhlbiB5b3UgbmVlZCB0byB3cml0ZSBhbm90aGVyIGRyYWZ0IHNvIHRoZSBy ZXN0IG9mIHVzIGNhbiBpbXBsZW1lbnQgaXQgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuICZuYnNw O01lIEkgcHJlZmVyIG5vdCB0byBndWVzcyB3aGF0IHlvdSBhcmUgZG9pbmcuPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhpcyBtdWNoIEkgYWdyZWUgd2l0aC48L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiPkFib3V0ICZxdW90O3Rvc191cmkm cXVvdDsgYW5kICZxdW90O3BvbGljeV91cmkmcXVvdDs8L2I+PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0b3NfdXJpIGFuZCBwb2xpY3lfdXJp IGlzIHVuY2xlYXIuICZuYnNwO0NhbiB3ZSBjbGFyaWZ5IG9yIGNvbWJpbmUgdGhlbT88L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGVybXMgb2Yg c2VydmljZSBhbmQgcG9saWN5IGFyZSB0d28gZGlmZmVyZW50IGRvY3VtZW50cy4gT25lIGlzIHNv bWV0aGluZyB0aGF0IGEgdXNlciBhY2NlcHRzIChnZW5lcmFsbHkgZGVzY3JpYmluZyB3aGF0IHRo ZSB1c2VyIHdpbGwgZG8pLCBvbmUgaXMgYSBzdGF0ZW1lbnQgb2Ygd2hhdCB0aGUgc2VydmljZSBw cm92aWRlciAoaW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50KSB3aWxsIGRvLiBNb3JlIGltcG9ydGFu dGx5LCB3ZSB1c2VkIHRvDQogaGF2ZSBvbmx5IG9uZSwgYW5kIHNldmVyYWwgcGVvcGxlIGFza2Vk IGZvciB0aGVtIHRvIGJlIHNwbGl0LjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KU2V2ZXJhbCBkZXZlbG9wZXJzIHdlcmUgY29uZnVzZWQgYnkgdGhpcy4g SW4gcGFydGljdWxhciB0aGV5IGNvdWxkbid0IGZpZ3VyZSBvdXQgd2hpY2ggd2FzIHVzZWQgZm9y IHdoYXQuICZuYnNwO0p1c3QgcGFzc2luZyBhbG9uZyB0aGUgZmVlZGJhY2suPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ T0ssIHRoZSBkaXN0aW5jdGlvbiB0aGF0IEkgc2VlIGlzIHRoYXQgdGhlIFRPUyBpcyBjb250cmFj dHVhbCwgdGhlIFBvbGljeSBpcyBhIHN0YXRlbWVudC4gUmUtcmVhZGluZyB0aGUgZGVmaW5pdGlv bnMgaW4gdGhlcmUgcmlnaHQgbm93LCB0aGF0IGNhbiBiZSBtYWRlIG11Y2ggY2xlYXJlci4gKEl0 IGV2ZW4gbG9va3MgbGlrZSBzb21lIE9JREMgdGV4dCBsZWFrZWQgaW50byB0aGUgZGVmaW5pdGlv biBvZiBwb2xpY3lfdXJpIGFuZCB0aGF0DQogaGFkbid0IGJlZW4gY2F1Z2h0IHlldC4pPC9kaXY+ DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KJm5i c3A7PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc28sIGFy ZW4ndCB0aGVzZSByZWFsbHkgVVJJcyBvciBhcmUgdGhleSBtZWFudCB0byBiZSBVUkxzPzwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGVyZSB3 YXMgYWxyZWFkeSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgb24gdGhlIGxpc3Q6IFRoZSBJRVRGIGlz IGFwcGFyZW50bHkgdHJ5aW5nIHRvIGRlcHJlY2F0ZSBVUkwgaW4gZmF2b3Igb2YgVVJJIGluIG5l dyBzcGVjcy4gU28gaW4gcHJhY3RpY2UgdGhleSdsbCBuZWFybHkgYWx3YXlzIGJlIFVSTHMsIGJ1 dCBzaW5jZSBhbGwgVVJMcyBhcmUgVVJJcyB3ZSdyZSBub3QgdGVjaG5pY2FsbHkgaW5jb3JyZWN0 IGluIGZvbGxvd2luZyB0aGUNCiBuZXcgcG9saWN5LiBBbmQgaXQgbWFrZXMgdGhlIElFU0cgbGVz cyBtYWQgYXQgdXMsIHdoaWNoIGlzIGEgcGx1cy48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCkFyZy4gTmljZS4gJm5ic3A7VGhlbiB0aGUgdGV4dCBzaG91 bGQgc2F5IHRoZSB2YWx1ZSBwYXNzZWQgbXVzdCByZXNvbHZlIHRvIGEgdmFsaWQgd2ViIHBhZ2Us IGRvY3VtZW50LCB3aGF0ZXZlci48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0J3MgZmFpciwgYW5kIGl0J3Mgc29t ZXRoaW5nIHRoYXQgdGhlIEFTIGNhbiBldmVuIGNoZWNrIGlmIGl0IHdhbnRzIHRvLjwvZGl2Pg0K PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxicj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48Yj5BYm91dCAmcXVvdDtq d2tzX3VyaSZxdW90OzwvYj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgbm9ybWF0 aXZlIHJlZmVyZW5jZSBmb3ImbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAx N3B4OyAiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1rZXktMDkiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1rZXktMDk8L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1o ZWlnaHQ6IDE3cHg7ICI+Jm5ic3A7aXMNCiBuZWVkZWQuPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTVw eDsgbGluZS1oZWlnaHQ6IDE3cHg7ICI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIHlvdSdyZSBjb3JyZWN0LCBJ J2xsIGFkZCB0aGF0LjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGxpbmUtaGVpZ2h0OiAxN3B4OyBmb250LWZhbWlseTogQ2FsaWJyaTsg Ij4mbmJzcDs8YnI+DQo8L3NwYW4+DQo8ZGl2PlNob3VsZCBiZSBVUkwgaW5zdGVhZCBvZiBVUkk/ PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNl ZSBhYm92ZS4gOik8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48Yj5TZWN0aW9uIDIuMTwvYj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkluIHRoZSB0YWJsZSZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0i Zm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMHB4OyB3aGl0ZS1zcGFjZTogcHJl OyAiPnVybjppZXRmOnBhcmFtczpvYXV0aDpncmFudC10eXBlOmp3dC1iZWFyZXINCjwvc3Bhbj5p cyBtaXNzaW5nLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JdCdzIHRoZXJlIGluIHRoZSBjb3B5IG9mIC0xMCBJJ20gcmVhZGluZyBvZmYgb2Yg PGEgaHJlZj0iaHR0cDovL2lldGYub3JnLyI+DQppZXRmLm9yZzwvYT4gcmlnaHQgbm93IOKApiA/ PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCic8L2Rpdj4NCjxkaXY+U29ycnkgSSBtZWFu dDombmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTBweDsgd2hpdGUtc3BhY2U6IHByZTsgIj51cm46aWV0 ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpzYW1sLWJlYXJlcjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BaCwgdGhh dCBtYWtlcyBtb3JlIHNlbnNlLiBJZiB0aGUgV0cgd2FudHMgdG8gYWRkIGluIFNBTUwgc3VwcG9y dCB0byBwYXJhbGxlbCB0aGUgSldUIHN1cHBvcnQsIEknZCBiZSBPSyB3aXRoIHRoYXQuPC9kaXY+ DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRp dj4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKA nEFzIHN1Y2gsIGEgc2VydmVyIHN1cHBvcnRpbmcgdGhlc2UgZmllbGRzIFNIT1VMRCB0YWtlIHN0 ZXBzJm5ic3A7dG8gZW5zdXJlIHRoYXQgYSBjbGllbnQgY2Fubm90IHJlZ2lzdGVyIGl0c2VsZiBp bnRvIGFuIGluY29uc2lzdGVudCBzdGF0ZS7igJ08YnI+DQo8YnI+DQpXZSBtYXkgd2FudCB0byBk ZWZpbmUgbW9yZSBkZXRhaWxlZCBIVFRQIGVycm9yIHJlc3BvbnNlLiZuYnNwO0UuZy4gNDAwIHN0 YXR1cyBjb2RlICYjNDM7IGRlZmluZWQgZXJyb3IgY29kZSAo4oCcaW52YWxpZF9jbGllbnRfbWV0 YWRhdGHigJ0pPzxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5JJ2QgYmUgZmluZSB3aXRoIGRlZmluaW5nIGEgbW9yZSBleHBsaWNpdCBl cnJvciBzdGF0ZSBpbiB0aGlzIGNhc2UuIEkgdGhpbmsgaXQgd291bGQgaGVscCBpbnRlcm9wIGZv ciB0aGUgc2VydmVycyB0aGF0IHdhbnQgdG8gZW5mb3JjZSBncmFudC10eXBlIGFuZCByZXNwb25z ZS10eXBlIHJlc3RyaWN0aW9ucywgYnV0IHNlcnZlcnMgdGhhdCBjYW4ndCBvciBkb24ndCBjYXJl IGFib3V0IHJlc3RyaWN0aW5nIGdyYW50cyB0eXBlcyBhbmQgd2hhdG5vdA0KIGRvbid0IGhhdmUg dG8gZG8gYW55dGhpbmcgc3BlY2lhbC48L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2 Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyAiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7ICI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPjxiPlNlY3Rpb24gMi4yPC9iPjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1zaXplOiAxMnB4OyAiPk1heSB3YW50IHRvIGFkZDo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZTogMTJweDsgIj48YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciPldoZW4mbmJzcDvigJwj4oCdIGxhbmd1 YWdlIHRhZyBpcyBtaXNzaW5nLCAoZS5nLiDigJwjZW7igJ0gaXMgbWlzc2luZyBpbiDigJxjbGll bnRfbmFtZeKAnSwgaW5zdGVhZCZuYnNwO29mIOKAnGNsaWVudF9uYW1lI2Vu4oCdKSB0aGUgT0F1 dGggc2VydmVyIG1heSB1c2UgaW50ZXJwcmV0IHRoZSZuYnNwO2xhbmd1YWdlIHVzZWQgYmFzZWQm bmJzcDtvbiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBvciBoZXVyaXN0aWNzLjwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhdCBzZWVtcyBpbmNvbnNp c3RlbnQgd2l0aCB3aGF0IHdlIGFscmVhZHkgaGF2ZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsg Ym9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5JZiBhbnkg aHVtYW4tcmVhZGFibGUgZmllbGQgaXMgc2VudCB3aXRob3V0IGEgbGFuZ3VhZ2UgdGFnLCBwYXJ0 aWVzIHVzaW5nIGl0IE1VU1QgTk9UIG1ha2UgYW55IGFzc3VtcHRpb25zIGFib3V0IHRoZSBsYW5n dWFnZSwgY2hhcmFjdGVyIHNldCwgb3Igc2NyaXB0IG9mIHRoZSBzdHJpbmcgdmFsdWUsIGFuZCB0 aGUgc3RyaW5nIHZhbHVlIE1VU1QgYmUgdXNlZCBhcy1pcyB3aGVyZXZlciBpdCBpcyBwcmVzZW50 ZWQgaW4gYSB1c2VyIGludGVyZmFjZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoaWNoIGlzIHRvIHNh eSwgdHJlYXQgaXQgYXMgYSByYXcgYnl0ZS12YWx1ZS1zdHJpbmcgYW5kIGRvbid0IHRyeSB0byBn ZXQgZmFuY3kuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KSSB3aWxsIGRpc2N1c3Mgd2l0aCBvdXIgZGV2ZWxvcGVycy4gSSdt IG5vdCBzdXJlIHRoZSBhcy1pcyB3b3Jrcy4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JcyBpdCB0aGUgaW50ZW50IHRoYXQgd2hlbiB0aGUgY2xpZW50IGhhcyBsb2NhbGl6 ZWQgJnF1b3Q7Y2xpZW50X25hbWUmcXVvdDsgZm9yIGV4YW1wbGUsIGl0IHNob3VsZCBwYXNzIGFs bCBsYW5ndWFnZSB2YXJpYXRpb25zIGluIGEgSlNPTiBhcnJheT88L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pk9yLCBzaG91bGQgcGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIGJlIHRvIGlu ZGljYXRlIHdoaWNoIGludGVyZmFjZSBsYW5ndWFnZSB0aGUgY2xpZW50IHdpc2hlcyB0byB1c2U/ ICZuYnNwO1RoZW4gaXQgb25seSBwYXNzZXMgYSBzaW5nbGUgdmFsdWUgZm9yIHRoYXQgcmVnaXN0 cmF0aW9uPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ObywgdGhlIGNsaWVudCBzaG91bGQgcGFz cyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNlcGFyYXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhp cyBpbiBpdHMgZXhhbXBsZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4g ICAmcXVvdDtjbGllbnRfbmFtZSZxdW90OzogJnF1b3Q7TXkgRXhhbXBsZSZxdW90OywNCiAgICZx dW90O2NsaWVudF9uYW1lI2phLUpwYW4tSlAmcXVvdDs6DQogICAgICZxdW90O+OCr+ODqeOCpOOC ouODs+ODiOWQjSZxdW90Oyw8L3ByZT4NCjxkaXY+U2hvdWxkIHdlIGFkZCB0aGF0IHRvIGF0IGxl YXN0IG9uZSBvZiB0aGUgZXhhbXBsZXMgaW4gRHluUmVnPyAoVGhlIGxhbmd1YWdlIHRhZ3MgYXJl IGEgbGF0ZSBhZGRpdGlvbiwgc28gdGhlIGV4YW1wbGVzIGRvbid0IHJlZmxlY3QgaXQuKTwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgdGhlIGNsaWVudCBwYXNzZXMgb25seSBhIHNp bmdsZSB1bmFkb3JuZWQgZmllbGQsIHRoZSBBUyBjYW4ndCBtYWtlIGFueSBhc3N1bXB0aW9uIGFi b3V0IHdoYXQgbGFuZ3VhZ2UgaXQgaXMuIFRoaW5rIG9mIHRoaXMgYXMgdGhlIGludGVybmF0aW9u YWxpemVkIHZhbHVlIG9mIHRoZSBmaWVsZCB3aGlsZSB0aGUgbGFuZ3VhZ2UgdGFncyBhcmUgdGhl IGxvY2FsaXplZCB2ZXJzaW9ucyBvZiB0aGUgZmllbGQuIFRoaXMgaXMgd2h5IHdlIHJlY29tbWVu ZA0KIHRoYXQgdGhlIGJhcmUtdmFsdWUgYWx3YXlzIGJlIHNlbnQgYnkgdGhlIGNsaWVudCwgc28g dGhhdCBpbiB0aGUgbGFjayBvZiBhbnl0aGluZyBtb3JlIHNwZWNpZmljLCB0aGUgQVMgY2FuIGF0 IGxlYXN0IGRvICpzb21ldGhpbmcqIHdpdGggaXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5QYXNzaW5nIGluIGEgJnF1b3Q7ZGVmYXVsdCZxdW90OyBsYW5ndWFnZSBmaWVsZCAobGlr ZSBkZWZhdWx0X2xvY2FsZSBvciB0aGUgbGlrZSkgaXMgb25seSBnb2luZyB0byBsZWFkIHRvIHBh aW4gZm9yIGltcGxlbWVudG9ycyBvZiBib3RoIGNsaWVudHMgYW5kIHNlcnZlcnMsIGFuZCBpdCdz IGdvaW5nIHRvIGh1cnQgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIGh1bWFuLXJlYWRhYmxl IGZpZWxkcy4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRp diBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyAiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+ DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGI+U2VjdGlvbiAzPC9iPjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RXhpc3RpbmcgdGV4dDo8YnI+DQo8YnI+DQo8Zm9udCBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyI+4oCcSW4gb3JkZXIg dG8gc3VwcG9ydCBvcGVuIHJlZ2lzdHJhdGlvbiBhbmQgZmFjaWxpdGF0ZSB3aWRlciZuYnNwO2lu dGVyb3BlcmFiaWxpdHksIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50Jm5ic3A7U0hP VUxEJm5ic3A7YWxsb3cgaW5pdGlhbCByZWdpc3RyYXRpb24mbmJzcDtyZXF1ZXN0cyB3aXRoIG5v Jm5ic3A7YXV0aGVudGljYXRpb24uJm5ic3A7Jm5ic3A7VGhlc2UgcmVxdWVzdHMgTUFZIGJlJm5i c3A7cmF0ZS1saW1pdGVkDQogb3Igb3RoZXJ3aXNlIGxpbWl0ZWQgdG8gcHJldmVudCBhIGRlbmlh bC1vZi1zZXJ2aWNlIGF0dGFjayBvbiB0aGUmbmJzcDtDbGllbnQmbmJzcDtSZWdpc3RyYXRpb24g RW5kcG9pbnQu4oCdPC9mb250Pjxicj4NCjxicj4NCkkgd291bGQgc3VnZ2VzdCB0byBjaGFuZ2Ug dGhlIGZpcnN0IOKAnFNIT1VMROKAnSB0byDigJxNQVnigJ0uJm5ic3A7ICZuYnNwO0luIG1vc3Qg Y2xvdWQgc2VydmljZXMsIHRoZSBmaXJzdCBjbGllbnQgaXMmbmJzcDtyZWdpc3RlcmVkIGJ5IGEg aHVtYW4gdXNlci4gVGhlbiwgb3RoZXImbmJzcDtjbGllbnRzIGNhbiBiZSBmdXJ0aGVyIHVzZWQg dG8gYXV0b21hdGUmbmJzcDtvdGhlciBjbGllbnQgcmVnaXN0cmF0aW9uLiZuYnNwOyZuYnNwO1Nv LCB0aGUgZmlyc3QmbmJzcDtyZXF1ZXN0IHdvdWxkIHR5cGljYWxseSBjb21lIHdpdGgNCiBhbiBh dXRoZW50aWNhdGVkIHVzZXIgaWRlbnRpdHkuJm5ic3A7PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsgdGhlIHdlaWdodCBvZiAmcXVvdDtT SE9VTEQmcXVvdDsgaXMgYXBwcm9wcmlhdGUgaGVyZSwgYmVjYXVzZSBJIGJlbGlldmUgdGhhdCB0 dXJuaW5nIG9mZiBvcGVuIHJlZ2lzdHJhdGlvbiBhdCB0aGUgQVMgKHdoaWNoIGlzIHdoYXQgdGhp cyBpcyB0YWxraW5nIGFib3V0KSByZWFsbHkgb3VnaHQgdG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRo ZXIgdGhhbiB0aGUgcnVsZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnI+DQo8L2Rpdj4NCkkgdGhpbmsgeW91IGFyZSByZWFkaW5nIGl0IHdyb25nIC0tIGEgZG91 YmxlLW5lZ2F0aXZlIGlzc3VlLiBUaGUgZW5kIG9mIHRoZSBzZW50ZW5jZSBpcyAmcXVvdDtubyBh dXRoZW50aWNhdGlvbiZxdW90Oy4gJm5ic3A7WW91IGFyZSBpbXBseWluZyB0aGF0IE5PIEF1dGhl bnRpY2F0aW9uIHVzIHdoYXQgc2hvdWxkIG5vcm1hbGx5IGJlIGRvbmUuIEkgdGhpbmsgeW91IGlu dGVuZCBhbm9ueW1vdXMgYXV0aGVudGljYXRpb24gdG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRoZXIg dGhhbg0KIHRoZSBydWxlIGRvbid0IHlvdT88YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ObywgSSB0aGluayB0aGF0IGFu b255bW91cyBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdGhlIHJ1bGUuIE9wZW4gcmVnaXN0cmF0 aW9uIHNob3VsZCBiZSBkZWZhdWx0LiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2 Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyAiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7ICI+DQo8ZGl2Pg0KPGRpdj48YnI+DQpPbiB0aGUgZmxpcCBzaWRlLCB0aGUgZWFybGllciBw YXJhZ3JhcGg6PGJyPg0KPGJyPg0KPGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9 IidDb3VyaWVyIE5ldyciPuKAnFRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50Jm5ic3A7 TUFZJm5ic3A7YWNjZXB0IGFuIGluaXRpYWwgYXV0aG9yaXphdGlvbiBjcmVkZW50aWFsIGluIHRo ZSBmb3JtIG9mIGFuIE9BdXRoIDIuMCZuYnNwO1tSRkM2NzQ5XSBhY2Nlc3MgdG9rZW4gaW4gb3Jk ZXIgdG8mbmJzcDtsaW1pdCByZWdpc3RyYXRpb24gdG8gb25seSBwcmV2aW91c2x5Jm5ic3A7YXV0 aG9yaXplZCBwYXJ0aWVzLiBUaGUNCiBtZXRob2QgYnkgd2hpY2ggdGhpcyBhY2Nlc3MgdG9rZW4g aXMgb2J0YWluZWQgYnkgdGhlJm5ic3A7cmVnaXN0cmFudCBpcyBnZW5lcmFsbHkgb3V0LW9mLWJh bmQgYW5kIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u4oCdPGJyPg0KPC9m b250Pjxicj4NCkkgdGVuZCB0byB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIHRo aXMg4oCcTUFZ4oCdIHRvIOKAnFNIT1VMROKAnS48YnI+DQo8YnI+DQpUaGF0IGFjY2VzcyB0b2tl biB3b3VsZCBjYXJyeSBhIGh1bWFuIHVzZXIgYXV0aGVudGljYXRlZCZuYnNwO2lkZW50aXR5IHNv bWVob3cuIEluIHNvbWUgY2FzZXMsIGl0IGNhbiBiZSBhIHB1cmUgYXV0aGVudGljYXRlZCB1c2Vy IGFzc2VydGlvbiZuYnNwO3Rva2VuLjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5BZ2FpbiwgZGlzYWdyZWUsIGZvciB0aGUgc2FtZSByZWFzb25pbmcg YXMgYWJvdmUuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+ DQpTYW1lIHJlYXNvbmluZy4mbmJzcDs8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGJyPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj4NCjxkaXY+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjxiPkFib3V0IHNlY3Rpb24g NC4zOjwvYj48L2Rpdj4NCjxkaXY+PGJyPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZv bnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1i cmVhay1iZWZvcmU6IGFsd2F5czsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7ICI+SWYgdGhlIGNsaWVudCBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHNl cnZlciwgdGhlIHNlcnZlciBNVVNUIHJlc3BvbmQNCiAgIHdpdGggSFRUUCA0MDEgVW5hdXRob3Jp emVkLCBhbmQgdGhlIFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gdXNlZCB0bw0KICAgbWFrZSB0 aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQuPC9wcmU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PklmIHRoZSBDbGllbnQgZG9lcyBub3QgZXhpc3Qgb24m bmJzcDt0aGlzIHNlcnZlciwgc2hvdWxkbid0IGl0IHJldHVybiBhICZxdW90OzQwNCBOb3QgRm91 bmQmcXVvdDs/PGJyPg0KPGJyPg0KSWYgcmV2b2tpbmcgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3Mg dG9rZW4sIGlzIGl0IGJvdW5kIHRvIGEgc2luZ2xlIGNsaWVudCByZWdpc3RyYXRpb24/ICZuYnNw O1RoaXMgaXMgbm90IGNsZWFyLiAmbmJzcDtXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9y bWF0aW9uIFJlc3BvbnNlIGluIHNlY3Rpb24gNS4xLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgbGFuZ3VhZ2UgYWJvdXQgdGhlIDQwMSBoZXJlIChhbmQg aW4gb3RoZXIgbmVhcmJ5IHNlY3Rpb25zKSBpcyBzcGVjaWZpY2FsbHkgc28gdGhhdCB5b3UgdHJl YXQgYSBtaXNzaW5nIGNsaWVudCBhbmQgYSBiYWQgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB0 aGUgc2FtZSB3YXkuIFlvdSBzZWUsJm5ic3A7cmV0dXJuaW5nIGEgNDA0IGhlcmUgYWN0dWFsbHkg aW5kaWNhdGVzIHRoaW5ncyB3ZXJlIGluIGFuIGluY29uc2lzdGVudCBzdGF0ZS4gTmFtZWx5LA0K IHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gd2FzIHN0aWxsIHZhbGlkIGJ1dCB0 aGUgY2xpZW50IHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gd2FzIGF0dGFjaGVk IHRvIGRvZXNuJ3QgZXhpc3QgYW55bW9yZS4gVGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4g aW4gbWVhbnQgdG8gYmUgdGllZCB0byBhIGNsaWVudCdzIGluc3RhbmNlIChvciByZWdpc3RyYXRp b24pLCBzbyBpdCdzIGFjdHVhbGx5IG1vcmUgc2Vuc2libGUNCiB0byBhY3QgYXMgdGhvdWdoIHRo ZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGlzbid0IHZhbGlkIGFueW1vcmUuIEluIGF0IGxl YXN0IHNvbWUgaW1wbGVtZW50YXRpb25zIChzcGVjaWZpY2FsbHkgb3VycyBhdCBNSVRSRSB0aGF0 J3MgYnVpbHQgb24gU0VDT0FVVEggaW4gSmF2YSksIHlvdSdkIG5ldmVyIGJlIGFibGUgdG8gcmVh Y2ggdGhlIDQwNCBzdGF0ZSBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0aGUgaW5i b3VuZCB0b2tlbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNpbmNlIHRoZSBpbnRl bnQgb2YgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gaXMgdGhhdCBpdCdzIGJvdW5kIHRv IGEgc2luZ2xlIGluc3RhbmNlLCBpdHMgbGlmZWN5Y2xlIGlzIGdlbmVyYWxseSB0aWVkIHRvIHRo ZSBsaWZlY3ljbGUgYmVnaW5zIGF0IHRoZSBpc3N1YW5jZSBvZiBhIG5ldyBjbGllbnRfaWQgd2l0 aCB0aGF0IGluc3RhbmNlLiBUaGF0IHRva2VuIG1pZ2h0IGJlIHJldm9rZWQgYW5kIGEgbmV3IG9u ZSBpc3N1ZWQgb24NCiBSZWFkIGFuZCBVcGRhdGUgcmVxdWVzdHMgdG8gdGhlIENsaWVudCBDb25m aWd1cmF0aW9uIEVuZHBvaW50IChhbmQgdGhlIGNsaWVudCBuZWVkcyB0byBiZSBwcmVwYXJlZCBm b3IgdGhhdCAtLSBzYW1lIGFzIHRoZSBjbGllbnRfc2VjcmV0KSwgYW5kIGl0IHdpbGwgYmUgcmV2 b2tlZCB3aGVuIHRoZSBjbGllbnQgaXMgZGVsZXRlZCBlaXRoZXIgd2l0aCBhIERlbGV0ZSBjYWxs IHRvIHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludCBvciBzb21ldGhpbmcNCiBoYXBw ZW5pbmcgb3V0LW9mLWJhbmQgdG8ga2lsbCB0aGUgY2xpZW50LiZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+U2hvdWxkIHdlIGFkZCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgdG8g dGhlIGRlZmluaXRpb24gaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdt IHZlcnkgb3BlbiB0byBjb25jcmV0ZSBzdWdnZXN0aW9ucyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9u J3QgdGhpbmsgaXQncyBhcyBjbGVhciBhcyB3ZSdkIGxpa2UuPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpJIHRoaW5rIHdlIHNob3VsZCBsb29rIGF0IGl0 Ljxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj4NCjxkaXYg YXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0K PGRpdj4NCjxkaXY+Jm5ic3A7PGJyPg0KPGI+QWJvdXQgc2VjdGlvbiA1LjE6PGJyPg0KPC9iPjxi cj4NCjwvZGl2Pg0KPGRpdj5JcyByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIHVuaXF1ZT8gJm5i c3A7T3IgaXMgaXQgc2hhcmVkIGJ5IG11bHRpcGxlIGluc3RhbmNlcz8gJm5ic3A7IElmIHNoYXJl ZCwgdGhlbiByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGNhbid0IGJlIHJldm9rZWQgb24gZGVs ZXRlIG9mIGNsaWVudC48L2Rpdj4NCjxkaXY+PGJyPg0KU3VnZ2VzdCByZW5hbWUg4oCcZXhwaXJl c19hdOKAnSB0byDigJxjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXTigJ0sJm5ic3A7PGJyPg0KPGJy Pg0KU3VnZ2VzdCB0byByZW5hbWUg4oCcaXNzdWVkX2F04oCdIHRvIOKAnGlkX2lzc3VlZF9hdOKA nTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGls ZSBJIGRvIGxpa2UgdGhlIHN1Z2dlc3Rpb24gb2YgY2hhbmdpbmcgdGhlc2UgdG8gY2xpZW50X3Nl Y3JldF9leHBpcmVzX2F0IGFuZCBjbGllbnRfaWRfaXNzdWVkX2F0LCBhbmQgSSB0aGluayB0aGVz ZSBhcmUgbW9yZSBjbGVhciBhbmQgcmVhZGFibGUsDQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkkgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlIHN5 bnRheCBkdXJpbmcgbGFzdCBjYWxsIHVubGVzcyB0aGVyZSBpcyBhIGNsZWFyIG5lZWQgYW5kIGEg Y2xlYXIgY29uc2Vuc3VzIGZvciBkb2luZyBzby48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyPg0KPC9kaXY+DQpUaGF0J3Mgd2h5IHdlIGFyZSBoYXZpbmcgbGFzdCBjYWxsLiBUbyBjb25m aXJtIGNvbnNlbnN1cyBvbiB0aGUgZHJhZnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5TYW1lIHJlYXNvbmluZyBhcyBlYXJsaWVyLiBZb3Ugbm93IGhhdmUgbXVsdGlwbGUg dG9rZW5zIChyZWdpc3RyYXRpb24gYWNjZXNzIGFuZCBjbGllbnQpIGluIHBsYXkuIFRoZSBzcGVj IG5lZWRzIHRvIGJlIGNsZWFyIHdoaWNoIG9uZSBpdCBpcyB0YWxraW5nIGFib3V0Ljxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkknbSBmaW5lIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgYnV0IEkgd291bGQgbGlrZSBt b3JlIGZlZWRiYWNrIGZyb20gb3RoZXIgcGVvcGxlIGJlZm9yZSBtb3ZpbmcgZm9yd2FyZCB3aXRo IGl0LiBUaGVyZSdzIGEgbG90IG9mIHZhbHVlIGluICZxdW90O2p1c3QgcGljayBhIG5hbWUgYW5k IHNoaXAgaXQmcXVvdDsgYXMgd2VsbCB0aG91Z2gsIGFuZCBJIGRvbid0IHdhbnQgdG8gZGV2b2x2 ZSBpbnRvIGJpa2Ugc2hlZGRpbmcuIChJJ20gbm90IGFjY3VzaW5nDQogeW91IG9mIGJpa2Ugc2hl ZGRpbmcgcXVpdGUgeWV0LCBidHcsIGp1c3QgYWZyYWlkIG9mIGdldHRpbmcgaW50byBhIGxvbmcg ZGViYXRlIG9uIG5hbWVzLik8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsg Ij4NCjxkaXY+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsgIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48Yj5TZWN0aW9u IDc8L2I+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGVuIGEgY2xpZW50X3NlY3Jl dCBleHBpcmVzIGlzIGl0IHRoZSBpbnRlbnQgdGhhdCBjbGllbnRzIGRvIGFuIHVwZGF0ZSBvciBy ZWZyZXNoIHRvIGdldCBhIG5ldyBjbGllbnQgc2VjcmV0PzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gZWl0 aGVyIGNhbGwgdGhlIHJlYWQgb3IgdXBkYXRlIG1ldGhvZHMgb24gdGhlIGNsaWVudCBjb25maWd1 cmF0aW9uIGVuZHBvaW50IHRvIGdldCBpdHMgbmV3IHNlY3JldC4gQXMgZGlzY3Vzc2VkIGFib3Zl LCBJJ20gbm90IHN1cmUgdGhhdCdzIGFzIGNsZWFyIGFzIGl0IG5lZWRzIHRvIGJlLCBhbmQgSSB3 ZWxjb21lIHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBjbGFyaWZ5IHRoaXMuPC9kaXY+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+QWdhaW4sIHRoYW5rcyBmb3IgdGhlIHZlcnkgdGhvcm91Z2ggcmVhZCB0aHJvdWdo LiBIYXZlIHlvdSBpbXBsZW1lbnRlZCBhbnkgb2YgdGhlIHNwZWMgeWV0LCBlaXRoZXIgYXMtaXMg b3Igd2l0aCBhbnkgb2YgeW91ciBzdWdnZXN0ZWQgY2hhbmdlcz88L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NClllcy4gTXVjaCBvZiB0aGUgZmVlZGJhY2sg aXMgY29taW5nIGZyb20gb3VyIGRldmVsb3BtZW50IGNvbW11bml0eS4mbmJzcDs8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5BaCwgdmVyeSBjb29sLiBEZXZlbG9wZXIgZXhwZXJpZW5jZSBpcyB0aGUgbW9zdCB2YWx1YWJs ZSBmZWVkYmFjaywgaW4gbXkgb3Bpbmlvbi4gSWYgeW91IGNhbid0IGFjdHVhbGx5IGJ1aWxkIHRo ZSBibGFzdGVkIHRoaW5nLCB3aGF0IGdvb2QgaXMgaXQ/IDopPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7LS0gSnVzdGluPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8EFC75650E8146889AEB459E7503F609mitreorg_-- From phil.hunt@oracle.com Thu May 16 12:54:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8211E80AE for ; Thu, 16 May 2013 12:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.121 X-Spam-Level: X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuiafmF0pryy for ; Thu, 16 May 2013 12:54:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7411E80A5 for ; Thu, 16 May 2013 12:54:11 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4GJrxut025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 19:53:59 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4GJrwsb005772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2013 19:53:58 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4GJrwYU004893; Thu, 16 May 2013 19:53:58 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 May 2013 12:53:57 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F966AA3-238B-4396-BFC4-3EB37BB54F0E" From: Phil Hunt In-Reply-To: <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> Date: Thu, 16 May 2013 12:53:56 -0700 Message-Id: <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 19:54:17 -0000 --Apple-Mail=_9F966AA3-238B-4396-BFC4-3EB37BB54F0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin, Thanks for the discussion. More comments below... BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >=20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: >=20 >> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>=20 >>> Phil, many thanks for the extremely thorough review! It is very = useful indeed.=20 >>>=20 >>> My comments and responses to each point are inline.=20 >>>=20 >>> On May 15, 2013, at 4:30 PM, Phil Hunt wrote: >>>=20 >>>> It seems unfortunate that I have not gotten a chance to get into = this level of detail much earlier. But then, I guess that's what LC = review is for! My apologies for not getting many of these concerns to = the WG much earlier. >>>>=20 >>>> Overall =20 >>>> ----------- >>>> I think dynamic registration is a critical part of the OAuth = framework now that we are starting to consider how individual client = applications should operate when there is one or more deployments of a = particular resource API. We've moved from the simple use case of a = single API provider like Facebook or Flickr and moved on to standards = based, open source based, and commercial based deployments where there = are multiple service endpoints and many clients to manage. >>>>=20 >>>> The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: >>>>=20 >>>> 1. How is a new client application recognized for the first time = when deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? >>>=20 >>> In the general case, why is any recognition required? If you're = doing things as part of a larger protocol ecosystem, like Blue Button+ = or a particular OpenID Connect provider, then you can define semantics = for tying together classes of clients (see below for more discussion on = this very point). But in general, a client is just going to show up as a = new instance to the AS and get issued a new, unique client_id, and = that's that.=20 >>=20 >> I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. >=20 > But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? >=20 > I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. What the UUID does is link multiple instances of a client app together = as the same "thing" that should have similar heuristics/behaviours. = This is very useful if you want to be able to revoke access to a set of = clients identified by application id (or a version of that app). >=20 >>>=20 >>>>=20 >>>> 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? >>>=20 >>> The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 >> Something like this should be in the draft. >=20 > Should this be up in the introductory text, somewhere else, or have = its own section? I'm starting to think credential management is a key part of the draft. = It may be worth introducing a specific section outling the registration = life-cycle, registration access token usage, and client token usage and = bootstrapping. >=20 >>>=20 >>>> How does a client authenticate the first time and subsequent = times to the registration service? >>>=20 >>> This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: >>> - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) >>> - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. >>>=20 >>> Subsequent times that the same registered client (by which we mean = the same instance of a client with a particular client_id) shows up at = the registration endpoint (actually, the Client Configuration Endpoint), = it uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. >>=20 >> Something like this should be in the draft. >=20 > OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer.=20 >=20 >>>=20 >>>>=20 >>>> 3. How is versioning of clients managed? Should each new version = of a client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. >>>=20 >>> This is up to the AS, really, and I don't think that any global = policy would ever fly here. Especially if you consider that the entire = notion of "version" is more fluid these days than it ever has been. I = wouldn't mind adding a discussion in the security considerations if it = merits mentioning though, so that we can help both client developers and = server developers institute reasonably good policy. >>=20 >> I guess the issue is that when a client upgrades it may have access = to the old credentials. What is the intent then of registration. Since = you have an update are clients expected to update /re-register or not? = I'm not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. >=20 > If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. I think this may be just a case of letting people exchange credentials = for whatever reason they feel is appropriate. The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register". Depending on the policy of the server, it may = (or may not) receive a new client_id and/or new credential. =20 One of the best benefits I can think of is if you discover a version of = a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ >=20 >>>=20 >>>>=20 >>>> 4. What is the registration access token? Why is is used? What is = its life-cycle? When is it issued, when is it changed? When is it = deleted? >>>=20 >>> See the response above above and the definition in =C2=A71.2:=20 >>>=20 >>> Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. >>>=20 >>> If this can be clarified, I welcome text suggestions. >>=20 >> The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. >>=20 >> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >> a Client can request new registration. The means of the Client >> obtaining the URL for this endpoint are out of scope for this >> specification. >>=20 >> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >> which a specific Client can manage its registration = information, >> provided by the Authorization Server to the Client. This URL = for >> this endpoint is communicated to the client by the = Authorization >> Server in the Client Information Response. >>=20 >> o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the >> Authorization Server through the Client Registration Endpoint >> which is used by the Client to authenticate itself during read, >> update, and delete operations. This token is associated with a >> particular Client. >>=20 >=20 > This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? Probably this is more a matter of style. But, what happened for me is I = naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? >=20 >>=20 >>>=20 >>>>=20 >>>> If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. >>>=20 >>>> When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. >>>=20 >>>=20 >>> I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? >>=20 >> We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. >>=20 >> I haven't heard a reason justifying this parameter other then "it is = needed". Why? >=20 > The role of the dynamic registration protocol is twofold: half of that = is the server informing the client what it must do. But the other half = is the client informing the server what it *can* do, or what it *wants* = to do.=20 >=20 > And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 I think we've discussed how recognizing subsequent instances is easily = done. As I mentioned in the other thread, if a developer chooses to limit the = capabilities of the client it must do so by looking to the developer or = standard behind the API. Otherwise they are taking the chance. There's = no way a developer can query all the potential deployers to ask what = authn types will you use. As I said, the net effect in the absence of an = API standard dictating what should be supported, the developer will have = to implement all methods. My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? >=20 >>=20 >>> And there's no way other than per-instance for the server to tell = the client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. >>>=20 >>> Which is not to say that it's not useful in some circumstances to = tie together different instances of the same code across (or within) = auth servers. This is why, with Blue Button+, we specified a specific = token format for the initial access token that the clients use to call = the registration endpoint the first time, as well as a discovery = protocol against a centralized server that handles pre-registration. All = of this machinery is, in my opinion, a stupendous overkill for the = general case, though if some folks find use for it outside of BB+ then = it'd be a good thing to abstract out and make its own spec that extends = the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue = Button+ we specify that all auth servers MUST also accept open = registration, without an initial access token, where the client simply = shows up and says "hey, here are my parameters." The auth server has no = way to know in this case any kind of out-of-band negotiation for = different things. In BB+ we are writing very specific policy guidelines = about how to present the UX and things to the end user for all of these = different cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its = own. I believe it would be far too limiting. >>=20 >>>=20 >>>>=20 >>>> Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? >>>=20 >>> That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. >>=20 >> Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 >>=20 >> One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. >=20 > There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. >=20 >>>=20 >>>>=20 >>>> Specific items: >>>> --------------------- >>>> "token_endpoint_auth_method" >>>>=20 >>>> There is some confusion as to whether this applies to server or = client authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" >>>=20 >>> This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. >>=20 >> The question was raised to me by some new developers. It seems = obvious to us as experienced OAuth persons, but to new developers it = seems unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) >=20 > Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to.=20 >=20 >>>=20 >>>>=20 >>>> * Currently, the API only supports a single value instead of an = array. If the purpose is to allow the client to know what auth methods = it supports, this should be an array indicated what methods the client = supports - or it should not be used. >>>=20 >>> I would rather like this to be an array, personally, and brought it = up with the OpenID Connect working group about six months ago. But there = it was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. >>=20 >> I can get behind multiple values. In this case, it changes the = meaning of the parameter. Instead of the client forcing the server to = use a particular method, the client is informing the server about what = methods it can perform. This allows the server to assign the appropriate = method based on its own policy. >>>=20 >>> Also note that this field, like all others in =C2=A72, represents = two things: the client telling the server "I want to use this value for = this field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. >>=20 >> This is the heart of my objection. This fuzziness is is going to lead = to interop issues. >=20 > There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 The inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. = If an implementer assumes singular and clients assume multiple, we have = issues. >=20 >>>=20 >>>>=20 >>>> * There is no authn method for "client_secret_saml" or = "private_key_saml". >>>=20 >>> Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? >>=20 >> I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. >=20 >>>=20 >>>>=20 >>>> There are no profiles referenced or defined for "client_secret_jwt" = or "private_key_jwt". Neither of the JWT or SAML Bearer drafts = referenced cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. >>>=20 >>> The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. >>=20 >> Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) >>=20 >> Regardless, you are introducing a new profile which is undefined. >=20 > I think I see the point that you're making now, let me try to re-state = it: >=20 > While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). >=20 > I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. I guess then the mistake the JWT Bearer and SAML Bearer drafts authors = made is they assumed everyone had the same definition of bearer token. = To me a bearer token opaque to the client. It therefore cannot do any = signature work with regards to the token itself. Now, that's not to say = a proof didn't occur between the client and the token issuer, but when = the client wields the token, it is handling an opaque string. The concept of client_secret_jwt suggests an HoK profile. Therefore of = course the bearer drafts are a little underspecified when it comes to = HoK profiles. So for example, you need a draft like the MAC draft for this.=20 I'm having trouble overall here. It seems the authn types suggest ONLY = strong authentication for clients, yet during the registration process = the current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way). If you haven't authenticated = the software at all, why have strong client auth? >=20 >>>=20 >>>>=20 >>>> There is no authentication method defined for "client_bearer_saml" = or "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs = say this is acceptable, the dynamic registration spec should accept = these. >>>=20 >>> I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. >>=20 >> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. >>=20 >> What you are describing is not bearer. It is holder of key. Very very = different.=20 >>>=20 >>>>=20 >>>> A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. >>>=20 >>> That's possible, but they are in active use already.=20 >>=20 >> That may be true. But then you need to write another draft so the = rest of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. >=20 > This much I agree with. >=20 >>>=20 >>>>=20 >>>>=20 >>>> About "tos_uri" and "policy_uri" >>>>=20 >>>> The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? >>>=20 >>> Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. >>=20 >> Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. >=20 > OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) >=20 >>> =20 >>>>=20 >>>> Also, aren't these really URIs or are they meant to be URLs? >>>=20 >>> There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. >>=20 >> Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. >=20 > That's fair, and it's something that the AS can even check if it wants = to. >=20 >>>=20 >>>>=20 >>>> About "jwks_uri" >>>>=20 >>>> A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 >>>=20 >>> Yes, you're correct, I'll add that. >>>=20 >>>> =20 >>>> Should be URL instead of URI? >>>=20 >>> See above. :) >>>=20 >>>>=20 >>>> Section 2.1 >>>>=20 >>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>> is missing. >>>=20 >>> It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? >> ' >> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >=20 > Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. >=20 >>>=20 >>>>=20 >>>> =E2=80=9CAs such, a server supporting these fields SHOULD take = steps to ensure that a client cannot register itself into an = inconsistent state.=E2=80=9D >>>>=20 >>>> We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? >>>=20 >>> I'd be fine with defining a more explicit error state in this case. = I think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. >>>=20 >>>>=20 >>>> Section 2.2 >>>>=20 >>>> May want to add: >>>>=20 >>>> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2= =80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. >>>=20 >>> That seems inconsistent with what we already have: >>>=20 >>> If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. >>>=20 >>> Which is to say, treat it as a raw byte-value-string and don't try = to get fancy. >>=20 >> I will discuss with our developers. I'm not sure the as-is works. =20 >>=20 >> Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? >>=20 >> Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? >=20 >=20 > No, the client should pass parameters as multiple separate values. = Connect has this in its example: >=20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) An example would definitely help. > If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. >=20 > Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 I think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text. Is the reason you are passing multiple localizations is so that you can = use the preferred language of the resource owner rather then the client = user? I wonder if that is correct. If the language preferences are in = fact different, what would the user of the client app expect? ----> any multi-lingual people have any opinions here? >=20 >>>=20 >>>>=20 >>>> Section 3 >>>>=20 >>>> Existing text: >>>>=20 >>>> =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >>>>=20 >>>> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 >>>=20 >>> I think the weight of "SHOULD" is appropriate here, because I = believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the rule.=20= >>=20 >> I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? >=20 > No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >=20 >>>=20 >>>>=20 >>>> On the flip side, the earlier paragraph: >>>>=20 >>>> =E2=80=9CThe 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.=E2=80=9D >>>>=20 >>>> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D= to =E2=80=9CSHOULD=E2=80=9D. >>>>=20 >>>> That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. >>>=20 >>> Again, disagree, for the same reasoning as above. >>=20 >> Same reasoning.=20 >>>=20 >>>>=20 >>>> About section 4.3: >>>>=20 >>>> If the client does not exist on this server, the server MUST = respond >>>> with HTTP 401 Unauthorized, and the Registration Access Token = used to >>>> make this request SHOULD be immediately revoked. >>>>=20 >>>> If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >>>>=20 >>>> If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. >>>=20 >>> The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. >>>=20 >>> Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 >>>=20 >>> Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. >>=20 >> I think we should look at it. >>>=20 >>>> =20 >>>> About section 5.1: >>>>=20 >>>> Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. >>>>=20 >>>> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >>>>=20 >>>> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_a= t=E2=80=9D >>>=20 >>> While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >>=20 >>> I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. >>=20 >> That's why we are having last call. To confirm consensus on the = draft.=20 >>=20 >> Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. >=20 > I'm fine with the suggested change but I would like more feedback from = other people before moving forward with it. There's a lot of value in = "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >=20 >>>=20 >>>>=20 >>>> Section 7 >>>>=20 >>>> When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? >>>=20 >>> Yes, the client is supposed to either call the read or update = methods on the client configuration endpoint to get its new secret. As = discussed above, I'm not sure that's as clear as it needs to be, and I = welcome suggestions on how to clarify this. >>>=20 >>>=20 >>>=20 >>> Again, thanks for the very thorough read through. Have you = implemented any of the spec yet, either as-is or with any of your = suggested changes? >>=20 >> Yes. Much of the feedback is coming from our development community.=20= >=20 > Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) >=20 >=20 > -- Justin --Apple-Mail=_9F966AA3-238B-4396-BFC4-3EB37BB54F0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Phil

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





On 2013-05-16, at 5:16 AM, Richer, Justin P. = wrote:


On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:

Phil, many thanks for the extremely thorough review! It is very useful = indeed. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

It seems unfortunate that I have not gotten a chance to get into = this level of detail much earlier. But then, I guess that's what LC = review is for! My apologies for not getting many of these concerns to = the WG much earlier.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth = framework now that we are starting to consider how individual client = applications should operate when there is one or more deployments of a = particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on = to standards based, open source based, and commercial based deployments = where there are multiple service endpoints and many clients to = manage.

The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec:

1.  How is a new client application recognized for the first = time when deployed against a particular SP endpoint?  Should = clients actually assert an application_id UUID that never changes and = possibly a version id that does change with versions?

In the general case, why is any recognition required? If you're = doing things as part of a larger protocol ecosystem, like Blue Button+ = or a particular OpenID Connect provider, then you can define semantics = for tying together classes of clients (see below for more discussion on this very point). But in general, a client is = just going to show up as a new instance to the AS and get issued a new, = unique client_id, and that's that. 

I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. =  It is useful to understand that a client application represents a = set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very = different from the subsequent instances that register. For example, = after the first registration, subsequent instances don't need special = review or approval to the same degree.

But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a set of code) to register is no different to = subsequent instances of that same application. How were you envisioning = an AS knowing the difference between the first and subsequent instances = of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it = resolves: Who issues the application_id, some server or the application = itself? Is it validated at all? Should it be considered secret? What = happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the = application_id has already been used elsewhere?

I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for = BB+)

I think it is = simple enough to at least add a self generated UUID for the application = ID.  Though I would allow for cases where the application ID is = assigned when the client developer and the APIs owner do a formal = assignment of application IDs.

In a sense this = is just a lower tech way of doing it than what you described as the = initial client credential in Blue Button+ where you encoded extra claims = into the initial app credential.

What the UUID = does is link multiple instances of a client app together as the same = "thing" that should have similar heuristics/behaviours.  This is = very useful if you want to be able to revoke access to a set of clients = identified by application id (or a version of that = app).




2.  How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the = expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple = refactorings), then I welcome suggestions and specific text as to how to = make that clear. 
Something like this should be in the draft.

Should this be up in the introductory text, somewhere else, or have = its own section?

I'm = starting to think credential management is a key part of the draft. It = may be worth introducing a specific section outling the registration = life-cycle, registration access token usage, and client token usage and = bootstrapping.


  How does a client authenticate the first time and subsequent = times to the registration service?

This is a separate question all together, as it does not involve = the client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a = bearer token). How the client gets that bearer token and what the bearer = token means to the AS beyond "this client is authorized to register" is = out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean = the same instance of a client with a particular client_id) shows up at = the registration endpoint (actually, the Client Configuration Endpoint), = it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer = token that is unique to the client instance.

Something like this should be in the draft.

OK, the definition of the registration access token can be = expanded, but I think that the rest of it is already in there in =C2=A73. = I'd welcome suggestions on which bits of this could be made = clearer. 



3.  How is versioning of clients managed? Should each new = version of a client require a change in client registration including = possibly changing client_id and authentication credential? I don't have = a strong feeling, but it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global = policy would ever fly here. Especially if you consider that the entire = notion of "version" is more fluid these days than it ever has been. I = wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both = client developers and server developers institute reasonably good = policy.

I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. =  Since you have an update are clients expected to update = /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic = registration supports.

If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and = getting a new client_id. 
I = think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it = solves.

I think this may be just a case of = letting people exchange credentials for whatever reason they feel is = appropriate.  The version upgrade thing suggests that when a client = is upgraded it should go to the registration server to "re-register". =  Depending on the policy of the server, it may (or may not) receive = a new client_id and/or new credential. =  

One of the best benefits I can think of = is if you discover a version of a client has a problem, being able to = select a group of clients by software and version is important. Thus if = client_id doesn't trace to a particular software and version, that makes = it hard to do.  I  think you talked about this as an issue for = Blue Button+




4.  What is the registration access token? Why is is used? = What is its life-cycle?  When is it issued, when is it changed? = When is it deleted?

See the response above above and the definition in = =C2=A71.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.

The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens called registration access tokens.

Client =
Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.

   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.

   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.


This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change?

Probably this is = more a matter of style.  But, what happened for me is I naturally = skipped the terminology section, as I wasn't expecting protocol = components to be there.  "terminology" is something I think people = tend to use as a dictionary rather than as protocol component = description.  Maybe the chairs can = advise?





If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance.

When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method.

I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, = and therefore the instance, and therefore the registration access token, = and therefore the registration itself at a conceptual level. So there is = no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would = the AS find out about it?

We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that = during the first time a piece of software is registered (the first = instance), there could be some OOB discussion by an administrator to = approve the particular authentication type for the AS in question.

I haven't heard a reason justifying this parameter other then "it = is needed".  Why?

The role of the dynamic registration protocol is twofold: half of = that is the server informing the client what it must do. But the other = half is the client informing the server what it *can* do, or what it = *wants* to do. 

And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and = not a great idea, sure, but  there's no useful way to prevent that = kind of behavior if you also want open registration of = clients. 

I think = we've discussed how recognizing subsequent instances is easily = done.

As I mentioned in the other thread, if a = developer chooses to limit the capabilities of the client it must do so = by looking to the developer or standard behind the API.  Otherwise = they are taking the chance.  There's no way a developer can query = all the potential deployers to ask what authn types will you use. As I = said, the net effect in the absence of an API standard dictating what = should be supported, the developer will have to implement all = methods.

My point here is that none of this is = helped by the client app saying what it supports. A developer who takes = the route of limiting implementation takes the chance that the server = will not accept.  So why negotiate within = registration?



And there's no way other than per-instance for the server to tell = the client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. = There is no way to tie together different instances across (or within) = auth servers without specifying a significant amount of other = machinery.

Which is not to say that it's not useful in some circumstances to = tie together different instances of the same code across (or within) = auth servers. This is why, with Blue Button+, we specified a specific = token format for the initial access token that the clients use to call the registration endpoint the first time, =  as well as a discovery protocol against a centralized server that = handles pre-registration. All of this machinery is, in my opinion, a = stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to = abstract out and make its own spec that extends the Dyn Reg spec in a = fully compatible way. Furthermore, even in Blue Button+ we specify that = all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these = different cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its = own. I believe it would be far too limiting.



Finally, there seems to be an inconsistent style approach = with 



Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or = client authentication.  Suggest renaming parameter to = "token_endpoint_client_auth_method"

This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so.

The question was raised to me by some new developers. It seems = obvious to us as experienced OAuth persons, but to new developers it = seems unclear.  Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That = said, I wouldn't mind shorter names (maybe not quite as short as the = JOSE stuff ;-)

Fair enough, but again, I only want to do syntax changes if the = rest of the WG *really* wants to. 



* Currently, the API only supports a single value instead of an = array.  If the purpose is to allow the client to know what auth = methods it supports, this should be an array indicated what methods the = client supports - or it should not be used.

I would rather like this to be an array, personally, and brought it = up with the OpenID Connect working group about six months ago. But there = it was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up = this very issue in the WG here but didn't receive any traction on it, so = single it remains.

I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =C2=A72, represents = two things: the client telling the server "I want to use this value for = this field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the = last word anyway. But at least this dictator is nice enough to tell you = what their decision was instead of just decapitating you.

This is the heart of my objection. This fuzziness is is going to lead to = interop issues.

There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response. 

The = inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. =  If an implementer assumes singular and clients assume multiple, we = have issues.



* There is no authn method for "client_secret_saml" or = "private_key_saml".

Nobody has really asked that these two be included or specified. = The extension mechanism (using an absolute URI) would allow someone else = to define these. Is the definition in the SAML Assertion draft = sufficient for their use?

I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft.  The truth is you are defining an = authentication that isn't even defined.



There are no profiles referenced or defined for = "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML = Bearer drafts referenced cover these types of flows. They only cover = bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not = fully define these either.

The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically.

Actually my interpretation is the JWT draft assumes the JWT Bearer = is a bearer token.  The assumption is that if a client has the = assertion it has the right to present it.  IOW. The JWT Bearer = Draft is most definitively not a JWT HoK Draft.  :-)

Regardless, you are introducing a new profile which is = undefined.

I think I see the point that you're making now, let me try to = re-state it:

While the basics of "how to present a JWT as a client credential" = is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#r= fc.section.2.2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more = clarity).

I'd be OK with adding the SAML bit, going into greater detail on = the JWT bits, or dropping the JWT bits, if the WG wants to do any of = those actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it = out.

I guess then the = mistake the JWT Bearer and SAML Bearer drafts authors made is they = assumed everyone had the same definition of bearer token.  To me a = bearer token opaque to the client. It therefore cannot do any signature = work with regards to the token itself.  Now, that's not to say a = proof didn't occur between the client and the token issuer, but when the = client wields the token, it is handling an opaque = string.

The concept of client_secret_jwt = suggests an HoK profile.  Therefore of course the bearer drafts are = a little underspecified when it comes to HoK = profiles.

So for example, you need a draft like = the MAC draft for this. 

I'm having = trouble overall here. It seems the authn types suggest ONLY strong = authentication for clients, yet during the registration process the = current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way).  If you haven't = authenticated the software at all, why have strong client = auth?




There is no authentication method defined for "client_bearer_saml" = or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer = specs say this is acceptable,  the dynamic registration spec should = accept these.

I don't understand this bit -- where are these defined in RFC6750? = I don't even know what client_bearer_ref would refer to.

6750 says you can use a bearer assertion (e.g. obtained from an IDP) and = wield it as an authentication assertion.  The client is NOT = creating or modifying the assertion. The client is simply passing one it = previously obtained.

What you are describing is not bearer. It is holder of key. Very = very different. 


A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined.

That's possible, but they are in active use already. 

That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way.  Me I prefer not to = guess what you are doing.

This much I agree with.




About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear. =  Can we clarify or combine them?

Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several people asked for them to be split.

Several developers were confused by this. In particular they couldn't = figure out which was used for what.  Just passing along the = feedback.

OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.)

 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a = plus.

Arg. Nice.  Then the text should say the value passed must resolve = to a valid web page, document, whatever.

That's fair, and it's something that the AS can even check if it = wants to.



About "jwks_uri"

A normative reference for http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 

Yes, you're correct, I'll add that.


Section 2.1

In the table  ietf.org right now =E2=80=A6 ?
'
Sorry I meant: 


=E2=80=9CAs such, a server supporting these fields SHOULD take = steps to ensure that a client cannot register itself into an = inconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )?

I'd be fine with defining a more explicit error state in this case. = I think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. = =E2=80=9C#en=E2=80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, = instead of =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may = use interpret the language used based on server configuration = or heuristics.

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try = to get fancy.

I will discuss with our developers. I'm not sure the as-is works. =  

Is it the intent that when the client has localized "client_name" = for example, it should pass all language variations in a JSON = array?

Or, should part of the registration be to indicate which interface = language the client wishes to use?  Then it only passes a single = value for that registration?


No, the client should pass parameters as multiple separate values. = Connect has this in its example:

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D",

Should we add that to at least one of the examples in DynReg? (The =
language tags are a late addition, so the examples don't reflect =
it.)

An example would definitely = help.
If the client = passes only a single unadorned field, the AS can't make any assumption = about what language it is. Think of this as the internationalized value = of the field while the language tags are the localized versions of the = field. This is why we recommend that the bare-value always be sent by the client, so that in the lack = of anything more specific, the AS can at least do *something* with = it.

Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable = fields. 

I = think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text.

Is the reason = you are passing multiple localizations is so that you can use the = preferred language of the resource owner rather then the client user? I = wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app = expect?

----> any multi-lingual people have = any opinions here?



Section 3

Existing text:

=E2=80=9CIn = order to support open registration and facilitate = wider interoperability, the Client Registration = Endpoint SHOULD allow initial registration requests with = no authentication.  These requests MAY = be rate-limited or otherwise limited to prevent a denial-of-service attack on = the Client Registration Endpoint.=E2=80=9D

I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D.   In most cloud services, the first = client is registered by a human user. Then, other clients can = be further used to automate other client = registration.  So, the first request would typically come = with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because I = believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the = rule. 

I think you are reading it wrong -- a double-negative issue. The end of = the sentence is "no authentication".  You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't you?

No, I think that anonymous authentication should be the rule. Open = registration should be = default. 

I disagree. =  Again,  the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. =  Yes you gain uniqueness, but that's about it.



On the flip side, the earlier paragraph:

=E2=80=9CThe = 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.=E2=80=9D<= br>
I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D = to =E2=80=9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.

Again, disagree, for the same reasoning as above.

Same reasoning. 


About section 4.3:

If the =
client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it = return a "404 Not Found"?

If revoking the registration access token, is it bound to a single = client registration?  This is not clear.  What is the = lifecycle around registration access token? Only hint is in the Client = Information Response in section 5.1.

The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that = the registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In = at least some implementations (specifically ours at MITRE that's built = on SECOAUTH in Java), you'd never be able to reach the 404 state due to = consistency checking with the inbound token.

Since the intent of the registration access token is that it's = bound to a single instance, its lifecycle is generally tied to the = lifecycle begins at the issuance of a new client_id with that instance. = That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the = client needs to be prepared for that -- same as the client_secret), and = it will be revoked when the client is deleted either with a Delete call = to the Client Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like.

I think we should look at it.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by = multiple instances?   If shared, then registration_access_token = can't be revoked on delete of client.

Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2=80= =9D

While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable,

I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so.

That's why we are having last call. To confirm consensus on the = draft. 

Same reasoning as earlier. You now have multiple tokens = (registration access and client) in play. The spec needs to be clear = which one it is talking about.

I'm fine with the suggested change but I would like more feedback = from other people before moving forward with it. There's a lot of value = in "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long = debate on names.)

Again, = this was a problem raised by people new to the specification. They found = it confusing. I tend to agree. We're not talking about what colour to = paint the shed. We're talking about whether the bike shed is a = house.  :-) 

I'm not too fussed = about whether you call it "cl_sec_expiry" or = "client_secret_expires_at". 



Section 7

When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update = methods on the client configuration endpoint to get its new secret. As = discussed above, I'm not sure that's as clear as it needs to be, and I = welcome suggestions on how to clarify this.



Again, thanks for the very thorough read through. Have you = implemented any of the spec yet, either as-is or with any of your = suggested changes?

Yes. Much of the feedback is coming from our development = community. 

Ah, very cool. Developer experience is the most valuable feedback, = in my opinion. If you can't actually build the blasted thing, what good = is it? :)


 -- Justin

= --Apple-Mail=_9F966AA3-238B-4396-BFC4-3EB37BB54F0E-- From phil.hunt@oracle.com Thu May 16 14:35:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F112311E80A2 for ; Thu, 16 May 2013 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkm6wzU2b0UM for ; Thu, 16 May 2013 14:35:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 253FD11E80A3 for ; Thu, 16 May 2013 14:35:24 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4GLZKqj030113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 May 2013 21:35:23 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4GLZJlN025903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 May 2013 21:35:20 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4GLZJF5028756 for ; Thu, 16 May 2013 21:35:19 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 May 2013 14:35:19 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 May 2013 14:35:18 -0700 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 21:35:30 -0000 All, In the dynamic registration draft, a new token type is defined called = the "registration access token". Its use is intended to facilitate = clients being able to update their registration and obtain new client = credentials over time. The client credential is issued on completion of = the initial registration request by a particular client instance. It appears the need for the registration access token arises from the = implied assertion that client credentials should expire.=20 --> Is anyone expiring client credentials? To date, we haven't had much discussion about client credential expiry. = It leads me to the following questions: 1. Is there technical value with client credential/token expiry? Keep = in mind that client credential is only used with the token endpoint over = TLS connection. It is NOT used to access resources directly. 2. If yes, on what basis should client credential/token expire? a. Time? b. A change to the client software (e.g. version update)? c. Some other reason? 3. Is it worth the complication to create a new token type (registration = access token) just to allow clients to obtain new client tokens? Keep = in mind that client tokens are only usable with the AS token endpoint. = Why not instead use a client token for dyn reg and token endpoint with = the rule that once a client token has expired (if they expire), an = expired token may still be used at the registration end-point. 4. Are there other reasons for the registration token? Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com From Michael.Jones@microsoft.com Thu May 16 15:27:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9582F11E8112 for ; Thu, 16 May 2013 15:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLTLFT8R-hMD for ; Thu, 16 May 2013 15:27:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 5682D11E80CC for ; Thu, 16 May 2013 15:27:06 -0700 (PDT) Received: from BY2FFO11FD003.protection.gbl (10.1.15.204) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.687.1; Thu, 16 May 2013 22:27:05 +0000 Received: from TK5EX14HUBC106.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.687.1 via Frontend Transport; Thu, 16 May 2013 22:27:05 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Thu, 16 May 2013 22:27:00 +0000 From: Mike Jones To: Phil Hunt , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUn1hpZLqFiRnMkSI5G863Tdy5JkIY0Gw Date: Thu, 16 May 2013 22:26:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(13464003)(189002)(377454002)(164054003)(74502001)(49866001)(51856001)(69226001)(50466002)(74706001)(54356001)(23726002)(50986001)(63696002)(20776003)(55846006)(47976001)(46406003)(74876001)(56816002)(15974865001)(47736001)(74662001)(44976003)(33656001)(47776003)(79102001)(77982001)(53806001)(46102001)(74366001)(6806003)(56776001)(66066001)(54316002)(81342001)(4396001)(65816001)(80022001)(31966008)(16406001)(81542001)(59766001)(76482001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0848C1A6AA Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 22:27:34 -0000 This is nothing more than an RFC 6750 bearer token. These can expire, as e= xplained in that draft. (The can also be issued an a manner that they don'= t expire.) Nothing new is being invented in this regard. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Thursday, May 16, 2013 2:35 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access To= ken - draft-ietf-oauth-dyn-reg-10 All, In the dynamic registration draft, a new token type is defined called the "= registration access token". Its use is intended to facilitate clients being= able to update their registration and obtain new client credentials over t= ime. The client credential is issued on completion of the initial registra= tion request by a particular client instance. It appears the need for the registration access token arises from the impli= ed assertion that client credentials should expire.=20 --> Is anyone expiring client credentials? To date, we haven't had much discussion about client credential expiry. It = leads me to the following questions: 1. Is there technical value with client credential/token expiry? Keep in = mind that client credential is only used with the token endpoint over TLS c= onnection. It is NOT used to access resources directly. 2. If yes, on what basis should client credential/token expire? a. Time? b. A change to the client software (e.g. version update)? c. Some other reason? 3. Is it worth the complication to create a new token type (registration ac= cess token) just to allow clients to obtain new client tokens? Keep in min= d that client tokens are only usable with the AS token endpoint. Why not i= nstead use a client token for dyn reg and token endpoint with the rule that= once a client token has expired (if they expire), an expired token may sti= ll be used at the registration end-point. 4. Are there other reasons for the registration token? Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From aselapathberiya@gmail.com Thu May 16 15:54:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862911E8122 for ; Thu, 16 May 2013 15:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDCQyhKAQVkD for ; Thu, 16 May 2013 15:54:55 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E3F2411E811F for ; Thu, 16 May 2013 15:54:54 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hq7so77514wib.10 for ; Thu, 16 May 2013 15:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=I+8E1UG0asKUAK22bZ+rVbB5m1tWcKrFnCDn6es0Z8Q=; b=D7GvJzZnqGsm2+lRlpf7Lx6xn0+6LVke3sgYYkDQlFrY3PUYxmD12c+pj5nBRVw1EO oQcp6k/xOWYNw3A5x/+7xnbiGRjBLwaJ/Od3VPTFXl0jTxB/4n6NLqfDro7LRoet+MMR g2xi2YS8FiWca12d04OFHiJNdPHZ2USKNI0J1mXCQofsUiIFnDYTiL6kPrYdFcg4GKV9 rYmoT6sQsVojfT46FLfceDGq4J1ktoyCAXY1yebdisPVMDCHEa6ICZ5IGgMv/7haClJn uABkK9LdtX9XvWdADved1aM6I+Tg81v4zsoRgs1cOok4F8eXefMBY4GqR909ewKV3Icb ZphQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr28776295wix.14.1368744894027; Thu, 16 May 2013 15:54:54 -0700 (PDT) Received: by 10.194.104.5 with HTTP; Thu, 16 May 2013 15:54:53 -0700 (PDT) Date: Fri, 17 May 2013 04:24:53 +0530 Message-ID: From: Asela Pathberiya To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d043c062e325ba004dcddc1a5 Subject: [OAUTH-WG] Access token must be differ based on the scope? X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 23:39:45 -0000 --f46d043c062e325ba004dcddc1a5 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I want to know, what is the correct way that authorization server must act when same client with same resource owner is asking for an access token for different scopes? Let say. 1. Got an access token for scope "foo1, bar1" 2. Then , if same client with same resource owner asks for an access token for different scope "foo2" Here, Should authorization server must issue an new access token for "foo2" scope or else authorization server must update the scope for current access token in its own entries ("foo1", "bar1", "foo2") and return same access token? Basically is access token issued per client, resource owner and scope or else only per client and resource owner? I could not found much details on this in the specification. sorry if this is already discussed. Thanks, Asela --f46d043c062e325ba004dcddc1a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

I want to know, what is t= he correct way that authorization server must act when same client with sam= e resource owner is asking for an access token for different scopes? =A0
Let say.=A0

1. Got an acces= s token for =A0scope =A0"foo1, bar1"=A0

2. Then , if same client with same resource owner asks for an a= ccess token for different scope "foo2"

Here, Should authorization server must issu= e an new access token for "foo2" scope or else authorization serv= er must update =A0the scope for current access token in its own entries (&q= uot;foo1", "bar1", "foo2") and return same access = token?=A0

Basically is access token issued per client= , resource owner and scope or else only per client and resource owner?=A0

I could not found much details on this = in the=A0specification. sorry if this is already=A0discussed.

Thanks,
Asela
--f46d043c062e325ba004dcddc1a5-- From aselapathberiya@gmail.com Thu May 16 16:43:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA17011E80CC for ; Thu, 16 May 2013 16:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcWtIYCyxlSJ for ; Thu, 16 May 2013 16:43:29 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80F11E80A3 for ; Thu, 16 May 2013 16:43:28 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mz10so1228150bkb.39 for ; Thu, 16 May 2013 16:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=WUWA9QulTv498YdQhDwXbxzQOgLN5CrLUnDTDfaKe1Y=; b=XWzLhKUvayEbl72kSFDz4QuVuhnSjcu87jUCAIlnyDPYc2yZTD9ckCBqgyzonxR/Wi hEgEvqd4giYHOF9H/xl684tG4/eGgPDKorCtbNnqfJJa+ii6EQpCuxtAb9lDzyXCGUjz +Aws4OsN/zg/twlz7rO4C2bpOL6nzpusMU2cXPNi90tMh58l+fyEBT0Xu4ie8zV2+7vF CzC7w7F2JO2vWqHhiRzQMp5C2N8N4gEUCK+nBx6HJbmeAD+14wgxYhFoSE45P/5g4HN8 UCgKDBZpAZfwyGxk8oF+5RHZEY7phJLMPqAVbiyDWGVFq0Tw8nStIAVJKrlXv8lUzweB 5xKg== MIME-Version: 1.0 X-Received: by 10.204.200.71 with SMTP id ev7mr3236241bkb.27.1368747807899; Thu, 16 May 2013 16:43:27 -0700 (PDT) Received: by 10.204.9.154 with HTTP; Thu, 16 May 2013 16:43:27 -0700 (PDT) Date: Fri, 17 May 2013 05:13:27 +0530 Message-ID: From: Asela Pathberiya To: oauth@ietf.org Content-Type: multipart/alternative; boundary=485b3970cecae0b24904dcde6e60 Subject: [OAUTH-WG] Access token must be differ based on the scope? X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2013 23:43:29 -0000 --485b3970cecae0b24904dcde6e60 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I want to know, what is the correct way that authorization server must act when same client with same resource owner is asking for an access token for different scopes? Let say. 1. Got an access token for scope "foo1, bar1" 2. Then , if same client with same resource owner asks for an access token for different scope "foo2" Here, Should authorization server must issue an new access token for "foo2" scope or else authorization server must update the scope for current access token in its own entries ("foo1", "bar1", "foo2") and return same access token? Basically is access token issued per client, resource owner and scope or else only per client and resource owner? I could not found much details on this in the specification. sorry if this is already discussed. Thanks, Asela --485b3970cecae0b24904dcde6e60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=
I want= to know, what is the correct way that authorization server must act when s= ame client with same resource owner is asking for an access token for diffe= rent scopes? =A0
Let say.=A0

1. Got an access toke= n for =A0scope =A0"foo1, bar1"=A0

2. Then , if same clie= nt with same resource owner asks for an access token for different scope &q= uot;foo2"

Here, Should authoriza= tion server must issue an new access token for "foo2" scope or el= se authorization server must update =A0the scope for current access token i= n its own entries ("foo1", "bar1", "foo2") an= d return same access token?=A0

Basically is access to= ken issued per client, resource owner and scope or else only per client and= resource owner?=A0

I could not found much= details on this in the=A0specification. sorry if this is already=A0discuss= ed.

Thanks,
Asela
--485b3970cecae0b24904dcde6e60-- From phil.hunt@oracle.com Thu May 16 17:43:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8CB11E8137 for ; Thu, 16 May 2013 17:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJP29giN6MDy for ; Thu, 16 May 2013 17:43:47 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AD4B421F882A for ; Thu, 16 May 2013 17:43:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4H0hhvB014148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 00:43:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4H0hiFD014048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 00:43:44 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4H0hiID014040; Fri, 17 May 2013 00:43:44 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 May 2013 17:43:44 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: Date: Thu, 16 May 2013 17:43:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Asela Pathberiya X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Access token must be differ based on the scope? X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 00:43:52 -0000 My understanding is this is ok if during authorization, the client = requested at least "foo1 bar1 foo2" or "foo1 bar1 foo2 bar2" for = example. The effect of asking for a separate token is the client has = two tokens with different scopes. "foo1 bar1" and "foo2". This is = actually nice because each token has minimal rights. Of course nothing saying an AS can't invalidate a previous token, but = nothing saying it needs to. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-16, at 3:54 PM, Asela Pathberiya wrote: > Hi All, >=20 > I want to know, what is the correct way that authorization server must = act when same client with same resource owner is asking for an access = token for different scopes? =20 > Let say.=20 >=20 > 1. Got an access token for scope "foo1, bar1"=20 >=20 > 2. Then , if same client with same resource owner asks for an access = token for different scope "foo2" >=20 > Here, Should authorization server must issue an new access token for = "foo2" scope or else authorization server must update the scope for = current access token in its own entries ("foo1", "bar1", "foo2") and = return same access token?=20 >=20 > Basically is access token issued per client, resource owner and scope = or else only per client and resource owner?=20 >=20 > I could not found much details on this in the specification. sorry if = this is already discussed. >=20 > Thanks, > Asela > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From prabath@wso2.com Thu May 16 18:21:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DFA11E80D9 for ; Thu, 16 May 2013 18:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEkTWO1tsdzd for ; Thu, 16 May 2013 18:21:42 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7A311E80D3 for ; Thu, 16 May 2013 18:21:41 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id f15so2095374eak.1 for ; Thu, 16 May 2013 18:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lEgZFBVEMAMWcJajO01YcEWsokUEA50SGZGzDuvV5nw=; b=QKzjSStCuu1XtkMbRCl4LiowegsfC78nMZE09yCBI6hvXCHUpJHctvI3l5K29MWicO 0CAwsoIEs+m4Uc8Hvys8D5BsMklXNPP4RIH6PNYzz8CEG3wZxyP60oI4jxA3fGOwHYev 1mGSeTz3TgzdTM4OKuw0uOr+a4G/Cn54h49l0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lEgZFBVEMAMWcJajO01YcEWsokUEA50SGZGzDuvV5nw=; b=RKF1zSYCKRotFjN+YMZeqMUFhGvx65d+89X+qPKOdzV9xRY6EPbBgZL1TBC62fobna 24RaZMCc47Cvthxa9qEqyV6mAATAa9uzBrR5tfaSt0ySv07aJDxJW9+VH6axVovsToZl x92fULnNG0V0VblhJq5+Aslk/5Yeu3KSRJNXEMSJ0iBCYhogAATxU4BWCXYnjbopSCk4 YuXOjKoowaMz52Jr/Ym30yIXITvx424N759tW/g15rnYiRemb61whtq4YYm0nQxeDuFq Mx0YwqYiW9zoEnKUN0eMQyY4lbmQsy1J0sq7BWhHZam0WLYkSJuUSeBHpEMY94dUfWAA /BWQ== MIME-Version: 1.0 X-Received: by 10.15.94.131 with SMTP id bb3mr71466832eeb.20.1368753700470; Thu, 16 May 2013 18:21:40 -0700 (PDT) Received: by 10.223.153.130 with HTTP; Thu, 16 May 2013 18:21:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 May 2013 06:51:40 +0530 Message-ID: From: Prabath Siriwardena To: Phil Hunt Content-Type: multipart/alternative; boundary=089e01634f761a378904dcdfcec1 X-Gm-Message-State: ALoCoQlSasOKA9gznEbG5Ealu+8XCfU4A0dIif0frMcEGH1JIjx53SqHecpQFEUQVujiLS5o76uP Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Access token must be differ based on the scope? X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 01:21:42 -0000 --089e01634f761a378904dcdfcec1 Content-Type: text/plain; charset=ISO-8859-1 Yes. If its a new grant asking an access token with a new scope - then we need to give a new acces token. Thanks & regards, -Prabath On Fri, May 17, 2013 at 6:13 AM, Phil Hunt wrote: > My understanding is this is ok if during authorization, the client > requested at least "foo1 bar1 foo2" or "foo1 bar1 foo2 bar2" for example. > The effect of asking for a separate token is the client has two tokens > with different scopes. "foo1 bar1" and "foo2". This is actually nice > because each token has minimal rights. > > Of course nothing saying an AS can't invalidate a previous token, but > nothing saying it needs to. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-16, at 3:54 PM, Asela Pathberiya wrote: > > > Hi All, > > > > I want to know, what is the correct way that authorization server must > act when same client with same resource owner is asking for an access token > for different scopes? > > Let say. > > > > 1. Got an access token for scope "foo1, bar1" > > > > 2. Then , if same client with same resource owner asks for an access > token for different scope "foo2" > > > > Here, Should authorization server must issue an new access token for > "foo2" scope or else authorization server must update the scope for > current access token in its own entries ("foo1", "bar1", "foo2") and return > same access token? > > > > Basically is access token issued per client, resource owner and scope or > else only per client and resource owner? > > > > I could not found much details on this in the specification. sorry if > this is already discussed. > > > > Thanks, > > Asela > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --089e01634f761a378904dcdfcec1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. If its a new grant asking an access token with a new scope - then we n= eed to give a new acces token.

Thanks & regards,
-Prabath

On Fri, May 17, 2013 at 6= :13 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
My understanding is this is ok if during aut= horization, the client requested at least "foo1 bar1 foo2" or &qu= ot;foo1 bar1 foo2 bar2" for example. =A0The effect of asking for a sep= arate token is the client has two tokens with different scopes. =A0"fo= o1 bar1" and "foo2". =A0This is actually nice because each t= oken has minimal rights.

Of course nothing saying an AS can't invalidate a previous token, but n= othing saying it needs to.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com





On 2013-05-16, at 3:54 PM, Asela Pathberiya wrote:

> Hi All,
>
> I want to know, what is the correct way that authorization server must= act when same client with same resource owner is asking for an access toke= n for different scopes?
> Let say.
>
> 1. Got an access token for =A0scope =A0"foo1, bar1"
>
> 2. Then , if same client with same resource owner asks for an access t= oken for different scope "foo2"
>
> Here, Should authorization server must issue an new access token for &= quot;foo2" scope or else authorization server must update =A0the scope= for current access token in its own entries ("foo1", "bar1&= quot;, "foo2") and return same access token?
>
> Basically is access token issued per client, resource owner and scope = or else only per client and resource owner?
>
> I could not found much details on this in the specification. sorry if = this is already discussed.
>
> Thanks,
> Asela
> _______________________________________________
> 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



--
Thanks &= Regards,
Prabath

--089e01634f761a378904dcdfcec1-- From prabath@wso2.com Thu May 16 18:28:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC01721F87D2 for ; Thu, 16 May 2013 18:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB5L2lzan0C9 for ; Thu, 16 May 2013 18:28:18 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4511E80D3 for ; Thu, 16 May 2013 18:28:13 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d4so2136905eek.14 for ; Thu, 16 May 2013 18:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2i3lTV1UMAOUJlEqOGOyXhGnSuAxQ2LayZdJnXRBU1U=; b=JJcCypn1gpu9YtSmdqW4wRH/qawvaW1+jdERc4DgRDdU67XMN3p39YJBcRBdNfr9G0 UkySEJTlSsCFSr3tFom9xzQEYPTHYxFOUIQPrW7gkrwnXg+/L4NlL+XZyfzkmqnM0U5/ xU1g4c8Ci9QlPcUeTZMD6Cc4tjz9lapMcKtUM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2i3lTV1UMAOUJlEqOGOyXhGnSuAxQ2LayZdJnXRBU1U=; b=QgDgLsxfPWUTC5aB1dTtGXrT7lT3+kdhzP1+7Rzvv0u8QTqZ4BfccEscSTTm33X5Pf NP6/IffeUzXDV9GYJ5ayB+GwcY3hER459izOqJ3o4uUrWN7ydz0eFmjtSOuUnUKL4Pcm HAsNVqw7QU1YHqbhJPFNWwiphaZakHTeRl3vDUUaEMKRoZ1XT7IDUeFc0mIqMwr0jvnp 4GIpYSlNQCYG6E5ASIR9NySr2NeJLqpxVmlCKSemWOujx5F1wlHYpCYMYYmg0UWxBkqz +CVVTLsXMJzAWnNnSJy3NO2cgBpPn3XXU4v2RzwGXIFcHIV7oEnU+DJtiRj+TASGuh89 IVOg== MIME-Version: 1.0 X-Received: by 10.14.38.198 with SMTP id a46mr123303325eeb.11.1368754092840; Thu, 16 May 2013 18:28:12 -0700 (PDT) Received: by 10.223.153.130 with HTTP; Thu, 16 May 2013 18:28:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436772FB86@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 17 May 2013 06:58:12 +0530 Message-ID: From: Prabath Siriwardena To: Mike Jones Content-Type: multipart/alternative; boundary=089e0160d2a87d4a9a04dcdfe544 X-Gm-Message-State: ALoCoQmQ94VkvI24DZj3O+nTQXdnPlYxRFmBT4HmpFFX1QPbRkQYfnNNW42flrG0HLurqRqprNvo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 has won the 2013 European Identity Award X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 01:28:25 -0000 --089e0160d2a87d4a9a04dcdfe544 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Congrats..!!! Its been a great - highly extensible framework which can be leveraged to address many aspect in REST security... Thanks & regards, -Prabath On Wed, May 15, 2013 at 10:54 PM, Mike Jones w= rote: > I=92m pleased to report that OAuth 2.0 has won the 2013 European Identit= y > Award for Best Innovation/New Standard. I was honored to accept the awar= d > from Kuppinger Cole at the 2013 European Identity and Cloud Conferenceon behalf of all who contributed to cr= eating the OAuth 2.0 standards [RFC > 6749 , RFC 6750] > and building solutions with them.**** > > ** ** > > (I also posted this announcement at http://self-issued.info/?p=3D1026.)**= ** > > ** ** > > -- Mike**** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --089e0160d2a87d4a9a04dcdfe544 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Congrats..!!! Its been a great - highly extensible framework which can be l= everaged to address many aspect in REST security...

Than= ks & regards,
-Prabath

On W= ed, May 15, 2013 at 10:54 PM, Mike Jones <Michael.Jones@microsof= t.com> wrote:

I=92m pleased to report that OAuth 2.0 has won the 2= 013 European Identity Award for Best Innovation/New Standard.=A0 I was hono= red to accept the award from Kuppinger Cole at the 2013 E= uropean Identity and Cloud Conference on behalf of all who contributed = to creating the OAuth 2.0 standards [RFC 6749, RFC 6750] and building solutions with them.

=A0

(I also posted this announcement at http://self-issued.info/?p=3D1026.)

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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




--
Thanks &= amp; Regards,
Prabath

--089e0160d2a87d4a9a04dcdfe544-- From phil.hunt@oracle.com Fri May 17 02:57:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3057121F93E6 for ; Fri, 17 May 2013 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTGpDO+hKK3X for ; Fri, 17 May 2013 02:57:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DBBA921F92C2 for ; Fri, 17 May 2013 02:57:32 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4H9vTYG003548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 09:57:30 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4H9vU0n020231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 09:57:31 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4H9vUIM020225; Fri, 17 May 2013 09:57:30 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 02:57:30 -0700 References: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> <655FB525-6952-4517-BD4B-8ECD67F3087E@oracle.com> <4E1F6AAD24975D4BA5B168042967394367733A24@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367733D51@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367733D51@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-8CBB286B-262D-4257-A6B3-2F49FAAB3C21 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Fri, 17 May 2013 02:57:29 -0700 To: Mike Jones X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 09:57:38 -0000 --Apple-Mail-8CBB286B-262D-4257-A6B3-2F49FAAB3C21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Or, are you saying reg access token is a signed assertion echoing back the r= egistration? I have to think about that. Still don't see the value since there should be o= nly one registration per client cred.=20 To me the client token can also be the registration more easily with less co= mplexity.=20 Phil Ps. Apologies just noticed I didn't reply all to group earlier.=20 On 2013-05-17, at 1:16, Mike Jones wrote: > I think you must understand something here. The token in the registration= spec *is* the token issued to the client by the registration server to repr= esent the client's registration. >=20 > -- Mike >=20 > From: Phil Hunt > Sent: 5/17/2013 9:53 AM > To: Mike Jones > Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Acce= ss Token - draft-ietf-oauth-dyn-reg-10 >=20 > Well why not just use the client token? =20 >=20 > Phil >=20 > On 2013-05-17, at 0:19, Mike Jones wrote: >=20 >> Its not there for reasons related to expiration. It's there as an access t= oken so the client can access and possibly update its client registration in= formation. >>=20 >> -- Mike >>=20 >> From: Phil Hunt >> Sent: 5/17/2013 1:02 AM >> To: Mike Jones >> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Acc= ess Token - draft-ietf-oauth-dyn-reg-10 >>=20 >> Sure. It isn't a new token format. But it is yet another token with spec= ific usage and security considerations. >>=20 >> I'm concerned about whether it makes sense to create yetanuthertoken just= to handle expiry of a token whose expiry wasn't called for in the group or i= n the threat model (6749 or 6819). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-16, at 3:26 PM, Mike Jones wrote: >>=20 >> > This is nothing more than an RFC 6750 bearer token. These can expire, a= s explained in that draft. (The can also be issued an a manner that they do= n't expire.) Nothing new is being invented in this regard. >> >=20 >> > -- Mike >> >=20 >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Phil Hunt >> > Sent: Thursday, May 16, 2013 2:35 PM >> > To: oauth@ietf.org WG >> > Subject: [OAUTH-WG] Client Credential Expiry and new Registration Acces= s Token - draft-ietf-oauth-dyn-reg-10 >> >=20 >> > All, >> >=20 >> > In the dynamic registration draft, a new token type is defined called t= he "registration access token". Its use is intended to facilitate clients be= ing able to update their registration and obtain new client credentials over= time. The client credential is issued on completion of the initial registr= ation request by a particular client instance. >> >=20 >> > It appears the need for the registration access token arises from the i= mplied assertion that client credentials should expire.=20 >> > --> Is anyone expiring client credentials? >> >=20 >> > To date, we haven't had much discussion about client credential expiry.= It leads me to the following questions: >> >=20 >> > 1. Is there technical value with client credential/token expiry? Keep= in mind that client credential is only used with the token endpoint over TL= S connection. It is NOT used to access resources directly. >> >=20 >> > 2. If yes, on what basis should client credential/token expire? >> > a. Time? >> > b. A change to the client software (e.g. version update)? >> > c. Some other reason? >> >=20 >> > 3. Is it worth the complication to create a new token type (registratio= n access token) just to allow clients to obtain new client tokens? Keep in m= ind that client tokens are only usable with the AS token endpoint. Why not i= nstead use a client token for dyn reg and token endpoint with the rule that o= nce a client token has expired (if they expire), an expired token may still b= e used at the registration end-point. >> >=20 >> > 4. Are there other reasons for the registration token? >> >=20 >> > Thanks, >> >=20 >> > Phil >> >=20 >> > @independentid >> > www.independentid.com >> > phil.hunt@oracle.com >> >=20 >> >=20 >> >=20 >> >=20 >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8CBB286B-262D-4257-A6B3-2F49FAAB3C21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Or, are you saying reg access token is a signed assertion echoing back the registration?

I have to think about that. Still don't see the value since there should be only one registration per client cred. 

To me the client token can also be the registration more easily with less complexity. 

Phil

Ps. Apologies just noticed I didn't reply all to group earlier. 
I think you must understand something here.  The token in the registration spec *is* the token issued to the client by the registration server to represent the client's registration.

-- Mike

From: Phil Hunt
Sent: 5/17/2013 9:53 AM
To: Mike Jones
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Well why not just use the client token?  

Phil

On 2013-05-17, at 0:19, Mike Jones <Michael.Jones@microsoft.com> wrote:

Its not there for reasons related to expiration. It's there as an access token so the client can access and possibly update its client registration information.

-- Mike

From: Phil Hunt
Sent: 5/17/2013 1:02 AM
To: Mike Jones
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Sure. It isn't a new token format.  But it is yet another token with specific usage and security considerations.

I'm concerned about whether it makes sense to create yetanuthertoken just to handle expiry of a token whose expiry wasn't called for in the group or in the threat model (6749 or 6819).

Phil

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





On 2013-05-16, at 3:26 PM, Mike Jones wrote:

> This is nothing more than an RFC 6750 bearer token.  These can expire, as explained in that draft.  (The can also be issued an a manner that they don't expire.)  Nothing new is being invented in this regard.
>
>                                -- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, May 16, 2013 2:35 PM
> To: oauth@ietf.org WG
> Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
>
> All,
>
> In the dynamic registration draft, a new token type is defined called the "registration access token". Its use is intended to facilitate clients being able to update their registration and obtain new client credentials over time.  The client credential is issued on completion of the initial registration request by a particular client instance.
>
> It appears the need for the registration access token arises from the implied assertion that client credentials should expire.
> --> Is anyone expiring client credentials?
>
> To date, we haven't had much discussion about client credential expiry. It leads me to the following questions:
>
> 1.  Is there technical value with client credential/token expiry?  Keep in mind that client credential is only used with the token endpoint over TLS connection. It is NOT used to access resources directly.
>
> 2.  If yes, on what basis should client credential/token expire?
>  a.  Time?
>  b.  A change to the client software (e.g. version update)?
>  c.  Some other reason?
>
> 3. Is it worth the complication to create a new token type (registration access token) just to allow clients to obtain new client tokens?  Keep in mind that client tokens are only usable with the AS token endpoint.  Why not instead use a client token for dyn reg and token endpoint with the rule that once a client token has expired (if they expire), an expired token may still be used at the registration end-point.
>
> 4. Are there other reasons for the registration token?
>
> Thanks,
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-8CBB286B-262D-4257-A6B3-2F49FAAB3C21-- From Adam.Lewis@motorolasolutions.com Fri May 17 08:23:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B44121F96B2 for ; Fri, 17 May 2013 08:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.988 X-Spam-Level: ** X-Spam-Status: No, score=2.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j83KgyDMGd6B for ; Fri, 17 May 2013 08:23:16 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6213B21F969C for ; Fri, 17 May 2013 08:23:15 -0700 (PDT) Received: from mail24-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE007.bigfish.com (10.174.4.70) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 15:23:08 +0000 Received: from mail24-db8 (localhost [127.0.0.1]) by mail24-db8-R.bigfish.com (Postfix) with ESMTP id 8A0129402BF for ; Fri, 17 May 2013 15:23:08 +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: -25 X-BigFish: VPS-25(zz98dI9371I146fI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received-SPF: pass (mail24-db8: 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:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail24-db8 (localhost.localdomain [127.0.0.1]) by mail24-db8 (MessageSwitch) id 1368804186560117_11011; Fri, 17 May 2013 15:23:06 +0000 (UTC) Received: from DB8EHSMHS019.bigfish.com (unknown [10.174.8.247]) by mail24-db8.bigfish.com (Postfix) with ESMTP id 7B2555E0049 for ; Fri, 17 May 2013 15:23:06 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by DB8EHSMHS019.bigfish.com (10.174.4.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 15:23:01 +0000 Received: from il06msg01.mot-solutions.com (il06vts02.mot.com [129.188.137.142]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4HFMxFL020988 for ; Fri, 17 May 2013 10:22:59 -0500 (CDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4HFMxoh020984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 May 2013 10:22:59 -0500 (CDT) Received: from mail108-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 15:22:59 +0000 Received: from mail108-ch1 (localhost [127.0.0.1]) by mail108-ch1-R.bigfish.com (Postfix) with ESMTP id 660C1300742 for ; Fri, 17 May 2013 15:22:59 +0000 (UTC) Received: from mail108-ch1 (localhost.localdomain [127.0.0.1]) by mail108-ch1 (MessageSwitch) id 1368804177925973_16672; Fri, 17 May 2013 15:22:57 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail108-ch1.bigfish.com (Postfix) with ESMTP id D46A81600A9; Fri, 17 May 2013 15:22:57 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 15:22:54 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.94]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0311.000; Fri, 17 May 2013 15:22:48 +0000 From: Lewis Adam-CAL022 To: "Richer, Justin P." , Antonio Sanso Thread-Topic: [OAUTH-WG] Recap of two well known OAuth related attacks Thread-Index: Ac5P7Kgk2IO6JLdIQgSAEFhZyghq+gB3rYAAAFGUJ2A= Date: Fri, 17 May 2013 15:22:47 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A96599A278@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> In-Reply-To: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.156.38] 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%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%ADOBE.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] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 15:23:21 -0000 One wonders that - if in hindsight - the implicit flow was a mistake to inc= lude in the framework. Yes it saves a single round trip for use cases wher= e the tokens are exposed to the UA, but it's not clear that optimization is= worth the security headaches that are going to be caused down the road (or= are already going on for that matter) by people using it in scenarios wher= e it should not be (because as stated, it is easier). Probably would have = been better to let the subset of cases that didn't need the extra step of t= he code just go ahead and implement it anyway, and ensure that the majority= of native apps use cases would have been implemented with better security.= =20 adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R= icher, Justin P. Sent: Wednesday, May 15, 2013 3:22 PM To: Antonio Sanso Cc: "WG "@il06exr01.mot.com Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks The biggest problem with this attack is the passing of the access token to = a backend server (and its subsequent passing of that token to someone else)= and the assumption that the presentation of the access token means that th= e user is authenticated and present. It simply doesn't mean that, and this = is a bad assumption that unfortunately many people make thanks to providers= like Facebook using OAuth (or, mostly-OAuth since they're not actually RFC= compliant) in the authentication protocol. It's also a problem that so many people are using the implicit flow "becaus= e it's easy", missing the point of why it's there in the first place. The i= mplicit flow is really only intended for cases where you can't hide secrets= from the user agent, cases like an in-browser application. The flow diagra= ms that you have don't fit the implicit flow very well at all, since the ac= cess token is getting passed back to some other service.=20 -- Justin On May 13, 2013, at 11:14 AM, Antonio Sanso wrote: > Hi *, >=20 > I wrote a blog post showing two well known OAuth related attacks. I paste= here the link for your consideration: >=20 > http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-de= vil-wears.html >=20 > Any comment is more than appreciated. >=20 > Regards >=20 > Antonio > _______________________________________________ > OAuth mailing 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 Fri May 17 08:46:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2B721F96C3 for ; Fri, 17 May 2013 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dakvzHePE45P for ; Fri, 17 May 2013 08:46:01 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8132E21F968B for ; Fri, 17 May 2013 08:46:00 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e50so2686293eek.41 for ; Fri, 17 May 2013 08:45:59 -0700 (PDT) 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=9XsjNfwK0Ek+g3d3nfnkuNFpIYkcKDYWgidMYwYO/po=; b=BId8ubALMEtKpu0cUaRJbDLdHtjKLN4NPmNx5iooqiZGUnr6QV63dCPUAjwy7m5oMZ Aix7P1zUcpdnfPyvpVZLQ0YSh5ceDvSy6yOFFpr/L5CPtPaKZm6d+LFcsHuQj9wW9JKz X0OO1fmM/0uf9Q6YAI24X4G1IY6tDslqF7yL5coGUpSSVyw4B1hQKpGRRjpjDY1CCpwA AREN1p3yMojPDErPpLBU7AlQ+LYDUOVbaVtbaXfFVtThiApiJNe+NVuepLyHwY95o5kS 7jlC7atWrYCwbg6s/JZbHqXu+WYVfMXC8aQDXINtZnbAOayO5OC9ACux8aXumSYD4FLG F+5w== X-Received: by 10.14.87.9 with SMTP id x9mr115970710eee.3.1368805559255; Fri, 17 May 2013 08:45:59 -0700 (PDT) Received: from [10.121.233.103] ([195.50.165.102]) by mx.google.com with ESMTPSA id bj12sm19537456eeb.8.2013.05.17.08.45.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 08:45:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6059D5BB-2EFA-40A0-8213-D5083C2A2156"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A96599A278@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Fri, 17 May 2013 17:46:03 +0200 Message-Id: References: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> <59E470B10C4630419ED717AC79FCF9A96599A278@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlDkMo4iwUmmn/WnISKo4jUv1f6p2/xoaH99B1ImuuRhn5A7brbKwrpsVTu51BjdjW2f5Hy Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 15:46:05 -0000 --Apple-Mail=_6059D5BB-2EFA-40A0-8213-D5083C2A2156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The implicit flow is secure in Connect, but we added a number of things = to make it so. The reason to have it in OAuth 2 is for clients in the browser there are = use cases for that and it allows the browser to receive and extract the = token without passing it to a web server backend. Used as intended it is fine as the browser based JS App is receiving the = the token directly over TLS so there is no substitution attack possible. = =20 The problem is when the client is not in the browser the browser itself = is an attack surface, that an attacker can use to confuse a client. If people want to do SSO based on OAuth they need to follow the example = of Google, PayPal and others who are implementing Connect rather than = rolling there own protocol on top of OAuth 2. John B. On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 = wrote: > One wonders that - if in hindsight - the implicit flow was a mistake = to include in the framework. Yes it saves a single round trip for use = cases where the tokens are exposed to the UA, but it's not clear that = optimization is worth the security headaches that are going to be caused = down the road (or are already going on for that matter) by people using = it in scenarios where it should not be (because as stated, it is = easier). Probably would have been better to let the subset of cases = that didn't need the extra step of the code just go ahead and implement = it anyway, and ensure that the majority of native apps use cases would = have been implemented with better security.=20 >=20 > adam >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Richer, Justin P. > Sent: Wednesday, May 15, 2013 3:22 PM > To: Antonio Sanso > Cc: "WG "@il06exr01.mot.com > Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks >=20 > The biggest problem with this attack is the passing of the access = token to a backend server (and its subsequent passing of that token to = someone else) and the assumption that the presentation of the access = token means that the user is authenticated and present. It simply = doesn't mean that, and this is a bad assumption that unfortunately many = people make thanks to providers like Facebook using OAuth (or, = mostly-OAuth since they're not actually RFC compliant) in the = authentication protocol. >=20 > It's also a problem that so many people are using the implicit flow = "because it's easy", missing the point of why it's there in the first = place. The implicit flow is really only intended for cases where you = can't hide secrets from the user agent, cases like an in-browser = application. The flow diagrams that you have don't fit the implicit flow = very well at all, since the access token is getting passed back to some = other service.=20 >=20 > -- Justin >=20 > On May 13, 2013, at 11:14 AM, Antonio Sanso > wrote: >=20 >> Hi *, >>=20 >> I wrote a blog post showing two well known OAuth related attacks. I = paste here the link for your consideration: >>=20 >> = http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-dev= il-wears.html >>=20 >> Any comment is more than appreciated. >>=20 >> Regards >>=20 >> Antonio >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6059D5BB-2EFA-40A0-8213-D5083C2A2156 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE3MTU0NjAzWjAjBgkqhkiG9w0BCQQxFgQUhw9jS0e5 jI6VRW/CVgGdJkRv+6EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAghFecTMJNejh0rn59RB47AHrdNApxmEh8nBXAKnb IqeY+HoNiD3Ilgdyjx45ApQTuBTRtBQlT9CsbYUOP0pJg7/Bpt4NfzBG3pOALSFGp5fRK7eXTh3C azNzFbWwLyk/3LLUmvpFaRUHIHDBJ4eup2KFTps1yPamjObgJmXaM1r4o/SqdHGHtoaZEFuE5gYV Y/xZhhfMxxnIUn6V+I0uwLMRu5w6ZFokkoi+Fl1IsxE08g5+/Hdm+2nDICoH7Vt6wvmgx5RJbXMU SoZxSSM8XwZNcAKELG0QblJvT1InJeYbbS8R/syvZyit20degB9SEdvapgTrYfWa/e3zOl/siQAA AAAAAA== --Apple-Mail=_6059D5BB-2EFA-40A0-8213-D5083C2A2156-- From jricher@mitre.org Fri May 17 08:55:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6399421F971B for ; Fri, 17 May 2013 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.681 X-Spam-Level: X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFnezFd20Cug for ; Fri, 17 May 2013 08:55:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6064221F96B5 for ; Fri, 17 May 2013 08:55:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A91BA1F02D9; Fri, 17 May 2013 11:55:14 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8D4001F0266; Fri, 17 May 2013 11:55:14 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 17 May 2013 11:55:14 -0400 Message-ID: <519652C9.5010303@mitre.org> Date: Fri, 17 May 2013 11:54:49 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> In-Reply-To: <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> Content-Type: multipart/alternative; boundary="------------060405090400080706040308" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 15:55:31 -0000 --------------060405090400080706040308 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 05/16/2013 03:53 PM, Phil Hunt wrote: > Justin, > > Thanks for the discussion. More comments below... > > BTW. I'm happy to contribute text. Just want to get to some rough > agreement first. For example, I think we need to have a away to > recognize two pieces of software as being the same (even if > self-asserted). Once defined, I can put together some intro text, etc. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > >> >> On May 15, 2013, at 10:30 PM, Phil Hunt > > >> wrote: >> >>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>> >>>> Phil, many thanks for the extremely thorough review! It is very >>>> useful indeed. >>>> >>>> My comments and responses to each point are inline. >>>> >>>> On May 15, 2013, at 4:30 PM, Phil Hunt >>> > wrote: >>>> >>>>> It seems unfortunate that I have not gotten a chance to get into >>>>> this level of detail much earlier. But then, I guess that's what >>>>> LC review is for! My apologies for not getting many of these >>>>> concerns to the WG much earlier. >>>>> >>>>> */Overall /* >>>>> ----------- >>>>> I think dynamic registration is a critical part of the OAuth >>>>> framework now that we are starting to consider how individual >>>>> client applications should operate when there is one or more >>>>> deployments of a particular resource API. We've moved from the >>>>> simple use case of a single API provider like Facebook or Flickr >>>>> and moved on to standards based, open source based, and commercial >>>>> based deployments where there are multiple service endpoints and >>>>> many clients to manage. >>>>> >>>>> The dynamic registration spec is actually dealing with a couple of >>>>> issues that I would like to see made more clear in early part of >>>>> the spec: >>>>> >>>>> 1. How is a new client application recognized for the first time >>>>> when deployed against a particular SP endpoint? Should clients >>>>> actually assert an application_id UUID that never changes and >>>>> possibly a version id that does change with versions? >>>> >>>> In the general case, why is any recognition required? If you're >>>> doing things as part of a larger protocol ecosystem, like Blue >>>> Button+ or a particular OpenID Connect provider, then you can >>>> define semantics for tying together classes of clients (see below >>>> for more discussion on this very point). But in general, a client >>>> is just going to show up as a new instance to the AS and get issued >>>> a new, unique client_id, and that's that. >>> >>> I think we have to define more clearly what an "instance" is. For >>> me, there are applications and there are instances of that >>> application. It is useful to understand that a client application >>> represents a set of code that should behave in a consistent way. It >>> seems to me the first time a new application shows up is very >>> different from the subsequent instances that register. For example, >>> after the first registration, subsequent instances don't need >>> special review or approval to the same degree. >> >> But without other mechanisms to tie things together, there's no way >> for an authorization server to know if any client instance is tied to >> any other client instance. Therefore, from the perspective of an AS, >> the first instance of an application (i.e., particular configuration >> of a set of code) to register is no different to subsequent instances >> of that same application. How were you envisioning an AS knowing the >> difference between the first and subsequent instances of an >> application, specifically? If there's an "application_id" like you >> mention above, I think it raises more questions than it resolves: Who >> issues the application_id, some server or the application itself? Is >> it validated at all? Should it be considered secret? What happens >> when someone simply steals an application_id? Does an AS have to do >> anything to check with any other AS to see if the application_id has >> already been used elsewhere? >> >> I do agree that a discussion of "instance vs. application" would be >> helpful in clearing this up, I'll make a note to add text to that >> effect. (We had to do something similar for BB+) > > I think it is simple enough to at least add a self generated UUID for > the application ID. Though I would allow for cases where the > application ID is assigned when the client developer and the APIs > owner do a formal assignment of application IDs. > > In a sense this is just a lower tech way of doing it than what you > described as the initial client credential in Blue Button+ where you > encoded extra claims into the initial app credential. > > What the UUID does is link multiple instances of a client app together > as the same "thing" that should have similar heuristics/behaviours. > This is very useful if you want to be able to revoke access to a set > of clients identified by application id (or a version of that app). I don't see the value in a self-asserted string here, and I'm very, very hesitant to tell the server to put trust in a model like this. And it raises a few questions: Are AS's now required to tie together clients with the same UUID, or is it just an optional thing for them to hang multiple instances off of? Is a client required to always include a UUID? What stops a client from simply sending a different UUID every time or a client from just picking the "google" string and sending it? Could an AS re-use a client_id for instances with the same UUID (that would be very bad for security, but if we're not careful I can see that as a common mistake)? Can an AS use the UUID *as* the client_id (again, a bad mistake that would be easy to make)? And are there new security implications around client impersonation that we then have to consider and discuss? I can think of an immediate DoS attack: - Good App Developer deploys wildly popular application with UUID, it gets registered everywhere - Evil App Developer steals that UUID (easy to do with native apps, hard on web servers) and puts it into their own app - Word gets out that the Evil App is Evil, and AS's start to revoke everything tied to that UUID, including all of the Good Apps There's also a rather bad race condition: - Good App Developer deploys something with a UUID - Evil App Developer steals that UUID and manages to register to a particular AS before the Good App gets there - A copy of the Good App shows up later and is tied to all of Evil App's metadata (such as a redirect URI that tries to steal codes/tokens/puppies) Since there's no way for the AS to check the metadata that's tied to the UUID, there's no way for it to know if it was the Evil App or the Good App that showed up first. So, I can see what you're going for here, but I don't think it really gets there and it opens more issues than it closes. I think that in the context of a larger protocol or extension you can do this right without breaking compatibility. What we're doing in BB+ works *only* because there's also a trusted client information discovery step that verifies and validates the client's previously-fixed parameters, and we're defining enforceable policies and responsibilities around different classes of application depending on what they can protect or not. We're actually requiring that certain parameters be tied to the trusted pre-registration process depending on the kind of application as well. We're also careful to reiterate that an AS can't re-use client_id's even for instances of clients of the same template/class. > >> >>>> >>>>> >>>>> 2. How are client credentials managed. Are we assuming client >>>>> credentials have a limited lifetime or rotation policy? >>>> >>>> The intent was that client_secret could be rotated, as indicated by >>>> the expires_at member of the response. If a client's secret >>>> expires, it calls the read operation on the Client Configuration >>>> Endpoint (§4.2) to get its new client_secret. If this is unclear in >>>> the current text (which I suspect it may be after multiple >>>> refactorings), then I welcome suggestions and specific text as to >>>> how to make that clear. >>> Something like this should be in the draft. >> >> Should this be up in the introductory text, somewhere else, or have >> its own section? > > I'm starting to think credential management is a key part of the > draft. It may be worth introducing a specific section outling the > registration life-cycle, registration access token usage, and client > token usage and bootstrapping. I think you're right that it's not called out enough. I'll work on a section on the whole client registration lifecyle for the next draft. This would be a good place to call out the difference between a client instance and a client template/class/application-code-base, too. >> >>>> >>>>> How does a client authenticate the first time and subsequent >>>>> times to the registration service? >>>> >>>> This is a separate question all together, as it does not involve >>>> the client_secret or client_id at all. Rather, the first time the >>>> client shows up to the registration service, it may either: >>>> - Not authenticate at all (this is the true public, open >>>> registration, and it is recommended that servers do this) >>>> - Authenticate using an OAuth 2.0 token (which ATM means a bearer >>>> token). How the client gets that bearer token and what the bearer >>>> token means to the AS beyond "this client is authorized to >>>> register" is out of scope for the spec, by design. >>>> >>>> Subsequent times that the same registered client (by which we mean >>>> the same instance of a client with a particular client_id) shows up >>>> at the registration endpoint (actually, the Client Configuration >>>> Endpoint), it uses its Registration Access Token that it was issued >>>> on initial registration. This is an OAuth 2.0 Bearer token that is >>>> unique to the client instance. >>> >>> Something like this should be in the draft. >> >> OK, the definition of the registration access token can be expanded, >> but I think that the rest of it is already in there in §3. I'd >> welcome suggestions on which bits of this could be made clearer. >> >>>> >>>>> >>>>> 3. How is versioning of clients managed? Should each new version >>>>> of a client require a change in client registration including >>>>> possibly changing client_id and authentication credential? I don't >>>>> have a strong feeling, but it is something that implementors >>>>> should consider. >>>> >>>> This is up to the AS, really, and I don't think that any global >>>> policy would ever fly here. Especially if you consider that the >>>> entire notion of "version" is more fluid these days than it ever >>>> has been. I wouldn't mind adding a discussion in the security >>>> considerations if it merits mentioning though, so that we can help >>>> both client developers and server developers institute reasonably >>>> good policy. >>> >>> I guess the issue is that when a client upgrades it may have access >>> to the old credentials. What is the intent then of registration. >>> Since you have an update are clients expected to update >>> /re-register or not? I'm not sure this is a security consideration >>> but more part of the whole change management function dynamic >>> registration supports. >> >> If your upgraded version of the client still has access to its old >> credentials, why wouldn't it just use those? I don't see a reason for >> forcing a re-registration. Nor do I see any way that an AS would even >> be able to tell that a client had been upgraded. An upgraded client >> always has the *option* of re-registering itself and getting a new >> client_id. > I think the concern here is that rotation of client credential is not > something discussed before. Before we put it in the spec we should > consider the reasons for doing it and what problems it solves. > The client doesn't get to choose when its credentials get rotated. It used to be able to, but now it's purely the server's choice, including whether or not it wants to rotate things at all. I think this confusion can be cleared up with the explicit lifecycle discussion getting pulled out into one place. > I think this may be just a case of letting people exchange credentials > for whatever reason they feel is appropriate. The version upgrade > thing suggests that when a client is upgraded it should go to the > registration server to "re-register". Depending on the policy of the > server, it may (or may not) receive a new client_id and/or new > credential. > > One of the best benefits I can think of is if you discover a version > of a client has a problem, being able to select a group of clients by > software and version is important. Thus if client_id doesn't trace to > a particular software and version, that makes it hard to do. I think > you talked about this as an issue for Blue Button+ Again, this assumes that the AS can reliably tie together instances of the clients. > >> >>>> >>>>> >>>>> 4. What is the registration access token? Why is is used? What is >>>>> its life-cycle? When is it issued, when is it changed? When is it >>>>> deleted? >>>> >>>> See the response above above and the definition in §1.2: >>>> >>>> Registration Access Token: An OAuth 2.0 Bearer Token issued by >>>> the Authorization Server through the Client Registration >>>> Endpoint which is used by the Client to authenticate itself >>>> during read, update, and delete operations. This token is >>>> associated with a particular Client. >>>> >>>> >>>> If this can be clarified, I welcome text suggestions. >>> >>> The latter part of 1.2 didn't seem like terminology but rather >>> architecture or part of the introduction that describes what the >>> spec does. The third point doesn't seem to fit with the other two >>> except to say that the dynamic registration endpoints use their own >>> access tokens called registration access tokens. >>> >>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>> a Client can request new registration. The means of the Client >>> obtaining the URL for this endpoint are out of scope for this >>> specification. >>> >>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>> which a specific Client can manage its registration information, >>> provided by the Authorization Server to the Client. This URL for >>> this endpoint is communicated to the client by the Authorization >>> Server in the Client Information Response. >>> >>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the >>> Authorization Server through the Client Registration Endpoint >>> which is used by the Client to authenticate itself during read, >>> update, and delete operations. This token is associated with a >>> particular Client. >>> >> >> This section is meant to just introduce the new terms that are then >> explained in greater detail throughout the rest of the document. Yes, >> it's a bit architecture, but only in the sense that you need to >> define the terms that make up your architecture. How would you >> suggest that it change? > > Probably this is more a matter of style. But, what happened for me is > I naturally skipped the terminology section, as I wasn't expecting > protocol components to be there. "terminology" is something I think > people tend to use as a dictionary rather than as protocol component > description. Maybe the chairs can advise? OK, look forward to any advice as to how to structure it. > >> >>> >>>> >>>>> >>>>> If we distinguish between first time registration of a particular >>>>> client software package, it is possible that somethings like >>>>> authentication method can be negotiate in or out-of-band at that >>>>> time. Subsequent registrations should only have parameters for >>>>> items that could change per deployment (like tos_uri). I think >>>>> token_endpoint_auth_method is one thing that should not be >>>>> negotiated per instance. >>>> >>>>> When subsequent instances register, I have to ask the question, >>>>> for example when would things like "token_endpoint_auth_method" be >>>>> negotiated or be different for the same client software? Should >>>>> not all instances use the same authentication method. >>>> >>>> I'm confused by this -- as far as the dynamic registration spec is >>>> concerned, all instances are separate from each other. All >>>> parameters change per instance. And instance, you should keep in >>>> mind, is defined as any one copy of the client code connecting to >>>> any new authorization server. That pairing creates the client_id, >>>> and therefore the instance, and therefore the registration access >>>> token, and therefore the registration itself at a conceptual level. >>>> So there is no way other than per-instance for a client to ask for >>>> a particular token_endpoint_auth_method. Where else would the AS >>>> find out about it? >>> >>> We still disagree on this. It is my assertion that clients should >>> NEVER ask for a particular token auth method. Since it is the AS >>> that is authenticating the client, then it is the AS's right to set >>> the authentication policy. The role of dynamic reg endpoint is to >>> inform the client what it must do. My assumption is that during the >>> first time a piece of software is registered (the first instance), >>> there could be some OOB discussion by an administrator to approve >>> the particular authentication type for the AS in question. >>> >>> I haven't heard a reason justifying this parameter other then "it is >>> needed". Why? >> >> The role of the dynamic registration protocol is twofold: half of >> that is the server informing the client what it must do. But the >> other half is the client informing the server what it *can* do, or >> what it *wants* to do. >> >> And again, there's no way to distinguish a first instance from a >> subsequent instance unless you're doing something in addition. >> Nothing is stopping the same application from registering a new >> instance of itself for every single user or every single token that >> it wants to get access for. That's complicated and wasteful and not a >> great idea, sure, but there's no useful way to prevent that kind of >> behavior if you also want open registration of clients. > > I think we've discussed how recognizing subsequent instances is easily > done. > > As I mentioned in the other thread, if a developer chooses to limit > the capabilities of the client it must do so by looking to the > developer or standard behind the API. Otherwise they are taking the > chance. There's no way a developer can query all the potential > deployers to ask what authn types will you use. As I said, the net > effect in the absence of an API standard dictating what should be > supported, the developer will have to implement all methods. > > My point here is that none of this is helped by the client app saying > what it supports. A developer who takes the route of limiting > implementation takes the chance that the server will not accept. So > why negotiate within registration? And my point here is that it's really a one-sided negotiation that gives the parties the chance to do something right. If this field were to be made plural (see below on how to do that), I think it makes more sense. Say a client can do methods A or B, but prefers A. A server can do methods B or C, but would rather clients to B. Without this field, there's no way for a client to tell the server what it can do, and there's no way for the server to tell the client what it can do in return. The processing is pretty simple in this case: C->S: [A, B] S->C: B C: (use B) If the server supports A, B, or C, it would go like: C->S: [A, B] S->C: [A, B] C: (use A) Or the client can remain silent: C->S: null S->C: [B, C] C: (use B) But if the parameter doesn't exist, the client's going to try "A", and fail. Or if the client isn't allowed to specify anything (and the server can only specify one thing), the server would respond with "C", making it fail. Neither of these cases actually have to fail. > >> >>> >>>> And there's no way other than per-instance for the server to tell >>>> the client which token_endpoint_auth_method to use. All instances >>>> will probably ask for the same token_endpoint_auth_method from all >>>> auth servers they talk to, right? And each AS will tell each >>>> instance that registers with it to use a particular auth method. >>>> There is no way to tie together different instances across (or >>>> within) auth servers without specifying a significant amount of >>>> other machinery. >>>> >>>> Which is not to say that it's not useful in some circumstances to >>>> tie together different instances of the same code across (or >>>> within) auth servers. This is why, with Blue Button+, we specified >>>> a specific token format for the initial access token that the >>>> clients use to call the registration endpoint the first time, as >>>> well as a discovery protocol against a centralized server that >>>> handles pre-registration. All of this machinery is, in my opinion, >>>> a stupendous overkill for the general case, though if some folks >>>> find use for it outside of BB+ then it'd be a good thing to >>>> abstract out and make its own spec that extends the Dyn Reg spec in >>>> a fully compatible way. Furthermore, even in Blue Button+ we >>>> specify that all auth servers MUST also accept open registration, >>>> without an initial access token, where the client simply shows up >>>> and says "hey, here are my parameters." The auth server has no way >>>> to know in this case any kind of out-of-band negotiation for >>>> different things. In BB+ we are writing very specific policy >>>> guidelines about how to present the UX and things to the end user >>>> for all of these different cases. But again, all of this is >>>> specific to the BB+ use case, and I don't see value in dragging it >>>> in to the registration spec on its own. I believe it would be far >>>> too limiting. >>> >>>> >>>>> >>>>> Finally, there seems to be an inconsistent style approach with >>>>> draft-hardjono-oauth-resource-reg >>>>> which >>>>> uses ETags. Should this draft do so as well? >>>> >>>> That's an individual submission, not a working group draft. Nobody >>>> has, until now, even mentioned the use of ETags here. UMA (where >>>> the resource registration draft comes from) uses ETags, hence their >>>> inclusion there. I personally don't see their utility here, though, >>>> and I wouldn't want to include a wholly new mechanism this late. >>> >>> Yes. Thomas' draft is not a WG document. But that doesn't mean he >>> doesn't have a point. It's worth discussing. >>> >>> One could argue that the point of an ETag is that it is useful for >>> change detection when there are multiple writers to a particular >>> resource. In the design of dynamic registration endpoint, there >>> should only be one writer -- the client. This is an important >>> observation. >> >> There are other mechanisms that handle this -- namely, the >> registration access token and the client_id. Many instances include >> the client_id in some form in the client configuration endpoint's URL >> for sanity checking, as described in §4.1. > > If everyone agrees, I'm in agreement. But it will likely mean changes > for the resource reg draft if adopted. >> >>>> >>>>> >>>>> */Specific items:/* >>>>> --------------------- >>>>> *"token_endpoint_auth_method"* >>>>> >>>>> There is some confusion as to whether this applies to server or >>>>> client authentication. Suggest renaming parameter to >>>>> "token_endpoint_client_auth_method" >>>> >>>> This is the first I've heard of this particular confusion. I'm fine >>>> with either name but at this stage I don't want to make syntax >>>> changes without very, very compelling reasons to do so. >>> >>> The question was raised to me by some new developers. It seems >>> obvious to us as experienced OAuth persons, but to new developers it >>> seems unclear. Also, now that you are introducing registration >>> authentication, the whole thing gets very confusing. So it is useful >>> disambiguate all the parameters where possible. That said, I >>> wouldn't mind shorter names (maybe not quite as short as the JOSE >>> stuff ;-) >> >> Fair enough, but again, I only want to do syntax changes if the rest >> of the WG *really* wants to. >> >>>> >>>>> >>>>> * Currently, the API only supports a single value instead of an >>>>> array. If the purpose is to allow the client to know what auth >>>>> methods it supports, this should be an array indicated what >>>>> methods the client supports - or it should not be used. >>>> >>>> I would rather like this to be an array, personally, and brought it >>>> up with the OpenID Connect working group about six months ago. But >>>> there it was decided that a single value was simpler and sufficient >>>> for the purpose. The IETF draft has inherited this decision. I >>>> *believe* (though am not 100% positive) that I brought up this very >>>> issue in the WG here but didn't receive any traction on it, so >>>> single it remains. >>> >>> I can get behind multiple values. In this case, it changes the >>> meaning of the parameter. Instead of the client forcing the server >>> to use a particular method, the client is informing the server about >>> what methods it can perform. This allows the server to assign the >>> appropriate method based on its own policy. >>>> >>>> Also note that this field, like all others in §2, represents two >>>> things: the client telling the server "I want to use this value for >>>> this field", and the server telling the client "this is the value >>>> you have for this field". It's not exactly a negotiation, more like >>>> making a polite request to an absolute dictator who has the last >>>> word anyway. But at least this dictator is nice enough to tell you >>>> what their decision was instead of just decapitating you. >>> >>> This is the heart of my objection. This fuzziness is is going to >>> lead to interop issues. >> >> There is no fuzziness that I can see here. It's parallelism between >> what goes in to the endpoint and what comes out of it. The semantics >> for the request and the response are different, and differentiable by >> the fact that one is a request and the other is a response. > > The inter-op issue I would like to point out is that the spec does not > currently specify if particular input values are singular or multiple. > If an implementer assumes singular and clients assume multiple, we > have issues. It does though -- everything's either a value or an array of values. I would suggest that this field be defined as a singular value if there's only one item or an array of values if one or more (a common JSON practice, used elsewhere in JWT and other places, too). This would let the simple clients and servers with only one value keep sending a string and being happy, and it's a minor breaking change to the client's data model. >> >>>> >>>>> >>>>> * There is no authn method for "client_secret_saml" or >>>>> "private_key_saml". >>>> >>>> Nobody has really asked that these two be included or specified. >>>> The extension mechanism (using an absolute URI) would allow someone >>>> else to define these. Is the definition in the SAML Assertion draft >>>> sufficient for their use? >>> >>> I think this is coming from the fact that there is a JWT bearer >>> draft and a SAML bearer draft. The truth is you are defining an >>> authentication that isn't even defined. >> >>>> >>>>> >>>>> /There are no profiles referenced or defined for >>>>> "client_secret_jwt" or "private_key_jwt". Neither of the JWT or >>>>> SAML Bearer drafts referenced cover these types of flows. They >>>>> only cover bearer flows. "client_secret_jwt" and >>>>> "private_key_jwt" seem to have some meaning within OpenID Connect, >>>>> but I note that OIDC does not fully define these either./ >>>> >>>> The JWT assertion draft does say how to use a JWT for client >>>> authentication, and the DynReg text differentiates between a client >>>> signing said JWT with its own secret symmetrically vs. a client >>>> using its own private key, asymmetrically. >>> >>> Actually my interpretation is the JWT draft assumes the JWT Bearer >>> is a bearer token. The assumption is that if a client has the >>> assertion it has the right to present it. IOW. The JWT Bearer Draft >>> is most definitively not a JWT HoK Draft. :-) >>> >>> Regardless, you are introducing a new profile which is undefined. >> >> I think I see the point that you're making now, let me try to >> re-state it: >> >> While the basics of "how to present a JWT as a client credential" is >> defined here: >> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 >> , it's not completely specified in that it doesn't fully restrict the >> signature secret source, the audience claim, and other things that >> the AS would need to check and validate. Right? The dynamic >> registration draft can define those cases in greater detail if needed >> (though I think it does so sufficiently as-is, I welcome more clarity). >> >> I'd be OK with adding the SAML bit, going into greater detail on the >> JWT bits, or dropping the JWT bits, if the WG wants to do any of >> those actions. My objection is that the JWT stuff is already in use >> and functioning and it'd be a shame to leave it out. > > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors > made is they assumed everyone had the same definition of bearer token. > To me a bearer token opaque to the client. It therefore cannot do any > signature work with regards to the token itself. Now, that's not to > say a proof didn't occur between the client and the token issuer, but > when the client wields the token, it is handling an opaque string. > > The concept of client_secret_jwt suggests an HoK profile. Therefore > of course the bearer drafts are a little underspecified when it comes > to HoK profiles. > > So for example, you need a draft like the MAC draft for this. I've spoken with Mike and John about this, and you're right. What we're proposing to do here is to remove client_secret_jwt and private_key_jwt from the OAuth Dyn Reg draft and create a short-names registry. This way, Connect (or another document) can register client_secret_jwt and private_key_jwt, and people can register saml_bearer or whatever else they'd like. > > I'm having trouble overall here. It seems the authn types suggest ONLY > strong authentication for clients, yet during the registration process > the current draft isn't able to correlate multiple instances of the > same software (even in a self-asserted way). If you haven't > authenticated the software at all, why have strong client auth? There's value for end users in strong auth even if the AS hasn't previously validated the client. Strong auth can work in a trust-on-first-use scenario just as well as a password can. > >> >>>> >>>>> >>>>> There is no authentication method defined for "client_bearer_saml" >>>>> or "client_bearer_jwt" or "client_bearer_ref". Since the bearer >>>>> specs say this is acceptable, the dynamic registration spec >>>>> should accept these. >>>> >>>> I don't understand this bit -- where are these defined in RFC6750? >>>> I don't even know what client_bearer_ref would refer to. >>> >>> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) >>> and wield it as an authentication assertion. The client is NOT >>> creating or modifying the assertion. The client is simply passing >>> one it previously obtained. >>> >>> What you are describing is not bearer. It is holder of key. Very >>> very different. >>>> >>>>> >>>>> A possible suggestion is to remove client_secret_jwt and >>>>> private_key_jwt and define those as register extensions since >>>>> these profiles are not defined. >>>> >>>> That's possible, but they are in active use already. >>> >>> That may be true. But then you need to write another draft so the >>> rest of us can implement it in an interoperable way. Me I prefer >>> not to guess what you are doing. >> >> This much I agree with. >> >>>> >>>>> >>>>> >>>>> *About "tos_uri" and "policy_uri"* >>>>> >>>>> The distinction between tos_uri and policy_uri is unclear. Can we >>>>> clarify or combine them? >>>> >>>> Terms of service and policy are two different documents. One is >>>> something that a user accepts (generally describing what the user >>>> will do), one is a statement of what the service provider (in this >>>> case, the client) will do. More importantly, we used to have only >>>> one, and several people asked for them to be split. >>> >>> Several developers were confused by this. In particular they >>> couldn't figure out which was used for what. Just passing along the >>> feedback. >> >> OK, the distinction that I see is that the TOS is contractual, the >> Policy is a statement. Re-reading the definitions in there right now, >> that can be made much clearer. (It even looks like some OIDC text >> leaked into the definition of policy_uri and that hadn't been caught >> yet.) >> >>>> >>>>> >>>>> Also, aren't these really URIs or are they meant to be URLs? >>>> >>>> There was already discussion about this on the list: The IETF is >>>> apparently trying to deprecate URL in favor of URI in new specs. So >>>> in practice they'll nearly always be URLs, but since all URLs are >>>> URIs we're not technically incorrect in following the new policy. >>>> And it makes the IESG less mad at us, which is a plus. >>> >>> Arg. Nice. Then the text should say the value passed must resolve >>> to a valid web page, document, whatever. >> >> That's fair, and it's something that the AS can even check if it >> wants to. >> >>>> >>>>> >>>>> *About "jwks_uri"* >>>>> >>>>> A normative reference for >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. >>>> >>>> Yes, you're correct, I'll add that. >>>> >>>>> >>>>> Should be URL instead of URI? >>>> >>>> See above. :) >>>> >>>>> >>>>> *Section 2.1* >>>>> >>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. >>>> >>>> It's there in the copy of -10 I'm reading off of ietf.org >>>> right now … ? >>> ' >>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >> >> Ah, that makes more sense. If the WG wants to add in SAML support to >> parallel the JWT support, I'd be OK with that. >> >>>> >>>>> >>>>> “As such, a server supporting these fields SHOULD take steps to >>>>> ensure that a client cannot register itself into an inconsistent >>>>> state.” >>>>> >>>>> We may want to define more detailed HTTP error response. E.g. 400 >>>>> status code + defined error code (“invalid_client_metadata”)? >>>> >>>> I'd be fine with defining a more explicit error state in this case. >>>> I think it would help interop for the servers that want to enforce >>>> grant-type and response-type restrictions, but servers that can't >>>> or don't care about restricting grants types and whatnot don't have >>>> to do anything special. >>>> >>>>> >>>>> *Section 2.2* >>>>> >>>>> May want to add: >>>>> >>>>> When “#” language tag is missing, (e.g. “#en” is missing in >>>>> “client_name”, instead of “client_name#en”) the OAuth server may >>>>> use interpret the language used based on server configuration or >>>>> heuristics. >>>> >>>> That seems inconsistent with what we already have: >>>> >>>> If any human-readable field is sent without a language tag, >>>> parties using it MUST NOT make any assumptions about the >>>> language, character set, or script of the string value, and the >>>> string value MUST be used as-is wherever it is presented in a >>>> user interface. >>>> >>>> >>>> Which is to say, treat it as a raw byte-value-string and don't try >>>> to get fancy. >>> >>> I will discuss with our developers. I'm not sure the as-is works. >>> >>> Is it the intent that when the client has localized "client_name" >>> for example, it should pass all language variations in a JSON array? >>> >>> Or, should part of the registration be to indicate which interface >>> language the client wishes to use? Then it only passes a single >>> value for that registration? >> >> >> No, the client should pass parameters as multiple separate values. >> Connect has this in its example: >> >> "client_name": "My Example", >> "client_name#ja-Jpan-JP": >> "クライアント名", >> Should we add that to at least one of the examples in DynReg? (The >> language tags are a late addition, so the examples don't reflect it.) > > An example would definitely help. OK, I'll add the internationalized string from Connect to at least one of the examples. >> If the client passes only a single unadorned field, the AS can't make >> any assumption about what language it is. Think of this as the >> internationalized value of the field while the language tags are the >> localized versions of the field. This is why we recommend that the >> bare-value always be sent by the client, so that in the lack of >> anything more specific, the AS can at least do *something* with it. >> >> Passing in a "default" language field (like default_locale or the >> like) is only going to lead to pain for implementors of both clients >> and servers, and it's going to hurt the interoperability of the >> human-readable fields. > > I think what I meant is since you are allowing each client to register > different things, AND the client likely already knows the user's > preferred language, why wouldn't the client just pass text values in > one language and another parameter indicating preferred language in > the case of any service generated text. > > Is the reason you are passing multiple localizations is so that you > can use the preferred language of the resource owner rather then the > client user? I wonder if that is correct. If the language preferences > are in fact different, what would the user of the client app expect? > > ----> any multi-lingual people have any opinions here? From my view, not all clients are going to have much knowledge about the end user's preferences. The internationalized strings are being used in the context of the AS (particularly, the authorization screen and any grant management screens), and the AS is going to know more about the user's context there than the client will. The client can make its best guess and send a single string along if it knows the right one (and I imagine most will, and most will put it in the unadorned field), but user-level preferences like "preferred locale" are getting too deep into the the specifics of protocols. >> >>>> >>>>> >>>>> *Section 3* >>>>> >>>>> Existing text: >>>>> >>>>> “In order to support open registration and facilitate >>>>> wider interoperability, the Client Registration >>>>> Endpoint SHOULD allow initial registration requests with >>>>> no authentication. These requests MAY be rate-limited or >>>>> otherwise limited to prevent a denial-of-service attack on >>>>> the Client Registration Endpoint.” >>>>> >>>>> I would suggest to change the first “SHOULD” to “MAY”. In most >>>>> cloud services, the first client is registered by a human user. >>>>> Then, other clients can be further used to automate other client >>>>> registration. So, the first request would typically come with an >>>>> authenticated user identity. >>>> >>>> I think the weight of "SHOULD" is appropriate here, because I >>>> believe that turning off open registration at the AS (which is what >>>> this is talking about) really ought to be the exception rather than >>>> the rule. >>> >>> I think you are reading it wrong -- a double-negative issue. The end >>> of the sentence is "no authentication". You are implying that NO >>> Authentication us what should normally be done. I think you intend >>> anonymous authentication to be the exception rather than the rule >>> don't you? >> >> No, I think that anonymous authentication should be the rule. Open >> registration should be default. > > I disagree. Again, the spec seems contradictory. It suggests strong > client auth methods and at the same time anonymous registration. Yes > you gain uniqueness, but that's about it. You gain the ability to be unspoofable for a given application, which matters to a user. It might seem silly from an enterprise deployment perspective where you want to control all copies of all apps, but the open registration case shouldn't be barred from using higher levels of authn. And I do still believe that open registration ought to be the rule on the internet. It's a SHOULD though, so your enterprise server is free to turn it off and still call itself compliant. >> >>>> >>>>> >>>>> On the flip side, the earlier paragraph: >>>>> >>>>> “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.” >>>>> >>>>> I tend to think it would be better to change this “MAY” to “SHOULD”. >>>>> >>>>> That access token would carry a human user authenticated identity >>>>> somehow. In some cases, it can be a pure authenticated user >>>>> assertion token. >>>> >>>> Again, disagree, for the same reasoning as above. >>> >>> Same reasoning. >>>> >>>>> >>>>> *About section 4.3:* >>>>> >>>>> If the client does not exist on this server, the server MUST respond >>>>> with HTTP 401 Unauthorized, and the Registration Access Token used to >>>>> make this request SHOULD be immediately revoked. >>>>> >>>>> If the Client does not exist on this server, shouldn't it return a >>>>> "404 Not Found"? >>>>> >>>>> If revoking the registration access token, is it bound to a single >>>>> client registration? This is not clear. What is the lifecycle >>>>> around registration access token? Only hint is in the Client >>>>> Information Response in section 5.1. >>>> >>>> The language about the 401 here (and in other nearby sections) is >>>> specifically so that you treat a missing client and a bad >>>> registration access token the same way. You see, returning a 404 >>>> here actually indicates things were in an inconsistent state. >>>> Namely, that the registration access token was still valid but the >>>> client that the registration access token was attached to doesn't >>>> exist anymore. The registration access token in meant to be tied to >>>> a client's instance (or registration), so it's actually more >>>> sensible to act as though the registration access token isn't valid >>>> anymore. In at least some implementations (specifically ours at >>>> MITRE that's built on SECOAUTH in Java), you'd never be able to >>>> reach the 404 state due to consistency checking with the inbound token. >>>> >>>> Since the intent of the registration access token is that it's >>>> bound to a single instance, its lifecycle is generally tied to the >>>> lifecycle begins at the issuance of a new client_id with that >>>> instance. That token might be revoked and a new one issued on Read >>>> and Update requests to the Client Configuration Endpoint (and the >>>> client needs to be prepared for that -- same as the client_secret), >>>> and it will be revoked when the client is deleted either with a >>>> Delete call to the Client Configuration Endpoint or something >>>> happening out-of-band to kill the client. >>>> >>>> Should we add more explanatory text to the definition in the >>>> terminology section? Elsewhere? I'm very open to concrete >>>> suggestions with this, since I don't think it's as clear as we'd like. >>> >>> I think we should look at it. >>>> >>>>> >>>>> *About section 5.1: >>>>> * >>>>> Is registration_access_token unique? Or is it shared by multiple >>>>> instances? If shared, then registration_access_token can't be >>>>> revoked on delete of client. >>>>> >>>>> Suggest rename “expires_at” to “client_secret_expires_at”, >>>>> >>>>> Suggest to rename “issued_at” to “id_issued_at” >>>> >>>> While I do like the suggestion of changing these to >>>> client_secret_expires_at and client_id_issued_at, and I think these >>>> are more clear and readable, >>> >>>> I don't want to change the syntax during last call unless there is >>>> a clear need and a clear consensus for doing so. >>> >>> That's why we are having last call. To confirm consensus on the draft. >>> >>> Same reasoning as earlier. You now have multiple tokens >>> (registration access and client) in play. The spec needs to be clear >>> which one it is talking about. >> >> I'm fine with the suggested change but I would like more feedback >> from other people before moving forward with it. There's a lot of >> value in "just pick a name and ship it" as well though, and I don't >> want to devolve into bike shedding. (I'm not accusing you of bike >> shedding quite yet, btw, just afraid of getting into a long debate on >> names.) > > Again, this was a problem raised by people new to the specification. > They found it confusing. I tend to agree. We're not talking about what > colour to paint the shed. We're talking about whether the bike shed is > a house. :-) > > I'm not too fussed about whether you call it "cl_sec_expiry" or > "client_secret_expires_at". Speaking as the editor, I'd like to hear from current developers on this one, more than anyone else, then. If we were to change these fields, would it break your implementations? How painful would that break be? Speaking as an individual implementor, it would be a fairly easy break for me to make on the server. Though I'd want to get feedback from the other engineers working on clients on different platforms here before really committing to it, I think that "issued_at -> client_id_issued_at" and "expires_at -> client_secret_expires_at" both do make sense and wouldn't actively break things. Speaking as an OpenID Connect WG member, though, this change would break the syntactical alignment with OIDC registration which is moments away from implementor's drafts. Since there is a dependency, I think we need to get them on board too. >> >>>> >>>>> >>>>> *Section 7* >>>>> >>>>> When a client_secret expires is it the intent that clients do an >>>>> update or refresh to get a new client secret? >>>> >>>> Yes, the client is supposed to either call the read or update >>>> methods on the client configuration endpoint to get its new secret. >>>> As discussed above, I'm not sure that's as clear as it needs to be, >>>> and I welcome suggestions on how to clarify this. >>>> >>>> >>>> >>>> Again, thanks for the very thorough read through. Have you >>>> implemented any of the spec yet, either as-is or with any of your >>>> suggested changes? >>> >>> Yes. Much of the feedback is coming from our development community. >> >> Ah, very cool. Developer experience is the most valuable feedback, in >> my opinion. If you can't actually build the blasted thing, what good >> is it? :) >> >> >> -- Justin > --------------060405090400080706040308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 05/16/2013 03:53 PM, Phil Hunt wrote:
Justin,

Thanks for the discussion. More comments below...

BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.


On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:


On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:

Phil, many thanks for the extremely thorough review! It is very useful indeed. 

My comments and responses to each point are inline. 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:

1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?

In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 

I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.

But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?

I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)

I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.

In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.

What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).

I don't see the value in a self-asserted string here, and I'm very, very hesitant to tell the server to put trust in a model like this. And it raises a few questions: Are AS's now required to tie together clients with the same UUID, or is it just an optional thing for them to hang multiple instances off of? Is a client required to always include a UUID? What stops a client from simply sending a different UUID every time or a client from just picking the "google" string and sending it? Could an AS re-use a client_id for instances with the same UUID (that would be very bad for security, but if we're not careful I can see that as a common mistake)? Can an AS use the UUID *as* the client_id (again, a bad mistake that would be easy to make)? And are there new security implications around client impersonation that we then have to consider and discuss?

I can think of an immediate DoS attack:

 - Good App Developer deploys wildly popular application with UUID, it gets registered everywhere
 - Evil App Developer steals that UUID (easy to do with native apps, hard on web servers) and puts it into their own app
 - Word gets out that the Evil App is Evil, and AS's start to revoke everything tied to that UUID, including all of the Good Apps

There's also a rather bad race condition:

 - Good App Developer deploys something with a UUID
 - Evil App Developer steals that UUID and manages to register to a particular AS before the Good App gets there
 - A copy of the Good App shows up later and is tied to all of Evil App's metadata (such as a redirect URI that tries to steal codes/tokens/puppies)

Since there's no way for the AS to check the metadata that's tied to the UUID, there's no way for it to know if it was the Evil App or the Good App that showed up first.

So, I can see what you're going for here, but I don't think it really gets there and it opens more issues than it closes. I think that in the context of a larger protocol or extension you can do this right without breaking compatibility. What we're doing in BB+ works *only* because there's also a trusted client information discovery step that verifies and validates the client's previously-fixed parameters, and we're defining enforceable policies and responsibilities around different classes of application depending on what they can protect or not. We're actually requiring that certain parameters be tied to the trusted pre-registration process depending on the kind of application as well. We're also careful to reiterate that an AS can't re-use client_id's even for instances of clients of the same template/class.





2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 
Something like this should be in the draft.

Should this be up in the introductory text, somewhere else, or have its own section?

I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.

I think you're right that it's not called out enough. I'll work on a section on the whole client registration lifecyle for the next draft. This would be a good place to call out the difference between a client instance and a client template/class/application-code-base, too.



  How does a client authenticate the first time and subsequent times to the registration service?

This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.

Something like this should be in the draft.

OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer. 



3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.

This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.

I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.

If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.


The client doesn't get to choose when its credentials get rotated. It used to be able to, but now it's purely the server's choice, including whether or not it wants to rotate things at all. I think this confusion can be cleared up with the explicit lifecycle discussion getting pulled out into one place.

I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.

One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+

Again, this assumes that the AS can reliably tie together instances of the clients.





4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?

See the response above above and the definition in §1.2: 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.

The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.

Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.

   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.

   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.


This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?

Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?

OK, look forward to any advice as to how to structure it.






If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.

When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.

I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?

We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.

I haven't heard a reason justifying this parameter other then "it is needed".  Why?

The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 

And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 

I think we've discussed how recognizing subsequent instances is easily done.

As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.

My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?

And my point here is that it's really a one-sided negotiation that gives the parties the chance to do something right. If this field were to be made plural (see below on how to do that), I think it makes more sense. Say a client can do methods A or B, but prefers A. A server can do methods B or C, but would rather clients to B. Without this field, there's no way for a client to tell the server what it can do, and there's no way for the server to tell the client what it can do in return. The processing is pretty simple in this case:

C->S: [A, B]
S->C: B
C: (use B)

If the server supports A, B, or C, it would go like:

C->S: [A, B]
S->C: [A, B]
C: (use A)

Or the client can remain silent:

C->S: null
S->C: [B, C]
C: (use B)

But if the parameter doesn't exist, the client's going to try "A", and fail. Or if the client isn't allowed to specify anything (and the server can only specify one thing), the server would respond with "C", making it fail. Neither of these cases actually have to fail.




And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.



Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?

That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.

Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 

One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.

There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 

If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.



Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"

This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.

The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)

Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to. 



* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.

I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.

I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.

This is the heart of my objection. This fuzziness is is going to lead to interop issues.

There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 

The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.

It does though -- everything's either a value or an array of values. I would suggest that this field be defined as a singular value if there's only one item or an array of values if one or more (a common JSON practice, used elsewhere in JWT and other places, too). This would let the simple clients and servers with only one value keep sending a string and being happy, and it's a minor breaking change to the client's data model.




* There is no authn method for "client_secret_saml" or "private_key_saml".

Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?

I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.



There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.

The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.

Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)

Regardless, you are introducing a new profile which is undefined.

I think I see the point that you're making now, let me try to re-state it:

While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).

I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.

I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.

The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.

So for example, you need a draft like the MAC draft for this.

I've spoken with Mike and John about this, and you're right. What we're proposing to do here is to remove client_secret_jwt and private_key_jwt from the OAuth Dyn Reg draft and create a short-names registry. This way, Connect (or another document) can register client_secret_jwt and private_key_jwt, and people can register saml_bearer or whatever else they'd like.


I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?

There's value for end users in strong auth even if the AS hasn't previously validated the client. Strong auth can work in a trust-on-first-use scenario just as well as a password can.





There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.

I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.

6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.

What you are describing is not bearer. It is holder of key. Very very different. 


A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.

That's possible, but they are in active use already. 

That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.

This much I agree with.




About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?

Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.

Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.

OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)

 

Also, aren't these really URIs or are they meant to be URLs?

There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.

Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.

That's fair, and it's something that the AS can even check if it wants to.



About "jwks_uri"

A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 

Yes, you're correct, I'll add that.

 
Should be URL instead of URI?

See above. :)


Section 2.1

In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing.

It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer

Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.



“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?

I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.


Section 2.2

May want to add:

When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try to get fancy.

I will discuss with our developers. I'm not sure the as-is works.  

Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?

Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?


No, the client should pass parameters as multiple separate values. Connect has this in its example:

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)

An example would definitely help.
OK, I'll add the internationalized string from Connect to at least one of the examples.

If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.

Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 

I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.

Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?

----> any multi-lingual people have any opinions here?

From my view, not all clients are going to have much knowledge about the end user's preferences. The internationalized strings are being used in the context of the AS (particularly, the authorization screen and any grant management screens), and the AS is going to know more about the user's context there than the client will. The client can make its best guess and send a single string along if it knows the right one (and I imagine most will, and most will put it in the unadorned field), but user-level preferences like "preferred locale" are getting too deep into the the specifics of protocols.




Section 3

Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 

I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 

I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?

No, I think that anonymous authentication should be the rule. Open registration should be default. 

I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

You gain the ability to be unspoofable for a given application, which matters to a user. It might seem silly from an enterprise deployment perspective where you want to control all copies of all apps, but the open registration case shouldn't be barred from using higher levels of authn.

And I do still believe that open registration ought to be the rule on the internet. It's a SHOULD though, so your enterprise server is free to turn it off and still call itself compliant.




On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.

Again, disagree, for the same reasoning as above.

Same reasoning. 


About section 4.3:

If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.

The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.

Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 

Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.

I think we should look at it.

 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”

While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,

I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.

That's why we are having last call. To confirm consensus on the draft. 

Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.

I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)

Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 

I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at".

Speaking as the editor, I'd like to hear from current developers on this one, more than anyone else, then. If we were to change these fields, would it break your implementations? How painful would that break be?

Speaking as an individual implementor, it would be a fairly easy break for me to make on the server. Though I'd want to get feedback from the other engineers working on clients on different platforms here before really committing to it, I think that "issued_at -> client_id_issued_at" and "expires_at -> client_secret_expires_at" both do make sense and wouldn't actively break things.

Speaking as an OpenID Connect WG member, though, this change would break the syntactical alignment with OIDC registration which is moments away from implementor's drafts. Since there is a dependency, I think we need to get them on board too.




Section 7

When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?

Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.



Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?

Yes. Much of the feedback is coming from our development community. 

Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)


 -- Justin


--------------060405090400080706040308-- From jricher@mitre.org Fri May 17 09:01:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81D21F974C for ; Fri, 17 May 2013 09:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAUENVBnzUdD for ; Fri, 17 May 2013 09:01:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6B21F974A for ; Fri, 17 May 2013 09:01:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EEA21226025E; Fri, 17 May 2013 12:01:39 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C8B6A2260229; Fri, 17 May 2013 12:01:34 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 17 May 2013 12:01:34 -0400 Message-ID: <51965446.2070404@mitre.org> Date: Fri, 17 May 2013 12:01:10 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Phil Hunt References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 16:01:50 -0000 The separation between these two is necessary: Not all clients have client_secret, and you want the lifecycle/management of the registration to be protected. This is what the registration access token was made for. In older versions of Connect's registration, the client_secret was forced on all clients in order to provide this, but then you had public clients with a client_secret that they couldn't use to get tokens, and it was a bad disconnect. The requirement for client secrets to expire or otherwise be rotated by the server came from several implementors in the Connect WG. There's an easy way to indicate that they don't expire, and a fairly straightforward way for them to be rotated (client does a GET on its client configuration endpoint url, with its registration access token as auth). -- Justin On 05/16/2013 05:35 PM, Phil Hunt wrote: > All, > > In the dynamic registration draft, a new token type is defined called the "registration access token". Its use is intended to facilitate clients being able to update their registration and obtain new client credentials over time. The client credential is issued on completion of the initial registration request by a particular client instance. > > It appears the need for the registration access token arises from the implied assertion that client credentials should expire. > --> Is anyone expiring client credentials? > > To date, we haven't had much discussion about client credential expiry. It leads me to the following questions: > > 1. Is there technical value with client credential/token expiry? Keep in mind that client credential is only used with the token endpoint over TLS connection. It is NOT used to access resources directly. > > 2. If yes, on what basis should client credential/token expire? > a. Time? > b. A change to the client software (e.g. version update)? > c. Some other reason? > > 3. Is it worth the complication to create a new token type (registration access token) just to allow clients to obtain new client tokens? Keep in mind that client tokens are only usable with the AS token endpoint. Why not instead use a client token for dyn reg and token endpoint with the rule that once a client token has expired (if they expire), an expired token may still be used at the registration end-point. > > 4. Are there other reasons for the registration token? > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Fri May 17 10:27:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6011E8101 for ; Fri, 17 May 2013 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeNP7kRVAAL5 for ; Fri, 17 May 2013 10:27:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB511E80F4 for ; Fri, 17 May 2013 10:27:36 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4HHRYio018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 17:27:35 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HHRYEu020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 17:27:34 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HHRYNa011804; Fri, 17 May 2013 17:27:34 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 10:27:33 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: <51965446.2070404@mitre.org> Date: Fri, 17 May 2013 10:27:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> References: <51965446.2070404@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 17:27:41 -0000 Justin, Your reason was you copied connect. Ok. I was looking for a technical = reason. A security reason. BTW. Mike Jones says expiry wasn't the reason. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 9:01 AM, Justin Richer wrote: > The separation between these two is necessary: Not all clients have = client_secret, and you want the lifecycle/management of the registration = to be protected. This is what the registration access token was made = for. In older versions of Connect's registration, the client_secret was = forced on all clients in order to provide this, but then you had public = clients with a client_secret that they couldn't use to get tokens, and = it was a bad disconnect. >=20 > The requirement for client secrets to expire or otherwise be rotated = by the server came from several implementors in the Connect WG. There's = an easy way to indicate that they don't expire, and a fairly = straightforward way for them to be rotated (client does a GET on its = client configuration endpoint url, with its registration access token as = auth). >=20 > -- Justin >=20 > On 05/16/2013 05:35 PM, Phil Hunt wrote: >> All, >>=20 >> In the dynamic registration draft, a new token type is defined called = the "registration access token". Its use is intended to facilitate = clients being able to update their registration and obtain new client = credentials over time. The client credential is issued on completion of = the initial registration request by a particular client instance. >>=20 >> It appears the need for the registration access token arises from the = implied assertion that client credentials should expire. >> --> Is anyone expiring client credentials? >>=20 >> To date, we haven't had much discussion about client credential = expiry. It leads me to the following questions: >>=20 >> 1. Is there technical value with client credential/token expiry? = Keep in mind that client credential is only used with the token endpoint = over TLS connection. It is NOT used to access resources directly. >>=20 >> 2. If yes, on what basis should client credential/token expire? >> a. Time? >> b. A change to the client software (e.g. version update)? >> c. Some other reason? >>=20 >> 3. Is it worth the complication to create a new token type = (registration access token) just to allow clients to obtain new client = tokens? Keep in mind that client tokens are only usable with the AS = token endpoint. Why not instead use a client token for dyn reg and = token endpoint with the rule that once a client token has expired (if = they expire), an expired token may still be used at the registration = end-point. >>=20 >> 4. Are there other reasons for the registration token? >>=20 >> Thanks, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Fri May 17 10:40:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4311E8107 for ; Fri, 17 May 2013 10:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1As5oXaVIQF for ; Fri, 17 May 2013 10:40:11 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id E296411E80FE for ; Fri, 17 May 2013 10:40:05 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id l10so2668804eei.4 for ; Fri, 17 May 2013 10:40:04 -0700 (PDT) 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=X/2mcBnftR8QpmAvwEyOshy1mZYfmSKYqol/cDEqhNY=; b=RHmgOep9SBTe8zgsu3xWxVb5bLUEGjc3jaMq/ZbWHpVR3OQWZ3Uovy9xjHYhrmqbSm J5huYhtVrpunqQBX+r0YfMEFWZOeudR9zwgvhqMIakd1PkvYJkLNc6+Gh/v92BcizNTH JU4UyXkjuZO+yTK7aHRkS7AiqCZlLOrtUyh7ApsInYxStEXb7yEG49N/ImessNXkwNqO /LWfTM5zRH61l2OXGzngAW7W2uPC4mRr6qNc2BO3DsNJhLGrAYVlCYYao+E+/ifdrUeM kQ4AK6rJADk2ysE7XFiE/2eoa5qn2YCZEe1PzgywVnXJpCj0ZgZNWOKADzvSx9de/6ar /m2A== X-Received: by 10.14.109.131 with SMTP id s3mr131173057eeg.26.1368812404774; Fri, 17 May 2013 10:40:04 -0700 (PDT) Received: from [10.121.233.103] ([195.50.165.102]) by mx.google.com with ESMTPSA id bn53sm20255491eeb.7.2013.05.17.10.40.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 10:40:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8D5ECF24-1D67-4DCC-BB16-DA406AB8AC79"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> Date: Fri, 17 May 2013 19:40:08 +0200 Message-Id: <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQktQqIVLh3aB/28I3deIGEx0X1LUF1N1zBA13mNA4hXEmZXPYABWSxPvPmz4cWDMZPQYhYf Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 17:40:16 -0000 --Apple-Mail=_8D5ECF24-1D67-4DCC-BB16-DA406AB8AC79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 1 No reasonable security profile is going to let you use the same = symmetric password over long time periods. It will be brute forced = given enough time. =20 The rotation time will depend on entropy and the rate an attacker can = submit attempts. I would expect profiles to look at SP-800-63 for = guidance as essentially a password for the client. 2 the registration interface is likely used by a developer who probably = doesn't want the client instances (say native clients) to be able to = update the configuration directly. using the client secret credential = for updates would break the separation. Registration my be done by the = client itself or by a developer as a separate process. John B. On 2013-05-17, at 7:27 PM, Phil Hunt wrote: > Justin, >=20 > Your reason was you copied connect. Ok. I was looking for a technical = reason. A security reason. >=20 > BTW. Mike Jones says expiry wasn't the reason. =20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-17, at 9:01 AM, Justin Richer wrote: >=20 >> The separation between these two is necessary: Not all clients have = client_secret, and you want the lifecycle/management of the registration = to be protected. This is what the registration access token was made = for. In older versions of Connect's registration, the client_secret was = forced on all clients in order to provide this, but then you had public = clients with a client_secret that they couldn't use to get tokens, and = it was a bad disconnect. >>=20 >> The requirement for client secrets to expire or otherwise be rotated = by the server came from several implementors in the Connect WG. There's = an easy way to indicate that they don't expire, and a fairly = straightforward way for them to be rotated (client does a GET on its = client configuration endpoint url, with its registration access token as = auth). >>=20 >> -- Justin >>=20 >> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>> All, >>>=20 >>> In the dynamic registration draft, a new token type is defined = called the "registration access token". Its use is intended to = facilitate clients being able to update their registration and obtain = new client credentials over time. The client credential is issued on = completion of the initial registration request by a particular client = instance. >>>=20 >>> It appears the need for the registration access token arises from = the implied assertion that client credentials should expire. >>> --> Is anyone expiring client credentials? >>>=20 >>> To date, we haven't had much discussion about client credential = expiry. It leads me to the following questions: >>>=20 >>> 1. Is there technical value with client credential/token expiry? = Keep in mind that client credential is only used with the token endpoint = over TLS connection. It is NOT used to access resources directly. >>>=20 >>> 2. If yes, on what basis should client credential/token expire? >>> a. Time? >>> b. A change to the client software (e.g. version update)? >>> c. Some other reason? >>>=20 >>> 3. Is it worth the complication to create a new token type = (registration access token) just to allow clients to obtain new client = tokens? Keep in mind that client tokens are only usable with the AS = token endpoint. Why not instead use a client token for dyn reg and = token endpoint with the rule that once a client token has expired (if = they expire), an expired token may still be used at the registration = end-point. >>>=20 >>> 4. Are there other reasons for the registration token? >>>=20 >>> Thanks, >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8D5ECF24-1D67-4DCC-BB16-DA406AB8AC79 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE3MTc0MDA5WjAjBgkqhkiG9w0BCQQxFgQUpkpCjAHk GQR+2e+T7gpdKKlQHugwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAd/q99FG1BXIaRdHjLeyoDDl7IjhTgQUOnmtrSZ9F oWS32tc/+4om+cpmy6AKMaGI3u451rRlzusvytKeEPVs1qReMFSDmi/40yA7GrscWOZOs6Vin7A+ OSJz/PHpfyZCQW/MOSktzbVoWicxrYuro4GotinHLEeKLf9JmGoQEvrVAKdbG9KviNFTWtgkkjxP KL/75VOrgfRV//KNKYCK4l+JAMM8Cljc3KvbBJsfEeaLhEKf3wamhaguZjEGSei0l10C5l57b9Cp 85KiqVkAkE6My+ha4VLetk+xIyC6lzTTNrxa1aq/PVkd+Atl+0YefijV2v9jmmHwkUYlZhzSuwAA AAAAAA== --Apple-Mail=_8D5ECF24-1D67-4DCC-BB16-DA406AB8AC79-- From donald.coffin@reminetworks.com Fri May 17 11:56:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5021F9746 for ; Fri, 17 May 2013 11:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F38v7UgkthaT for ; Fri, 17 May 2013 11:56:00 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 4099221F9747 for ; Fri, 17 May 2013 11:56:00 -0700 (PDT) Received: (qmail 29119 invoked by uid 0); 17 May 2013 18:55:30 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy3.bluehost.com with SMTP; 17 May 2013 18:55:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=oUk0SYm0lGcHbv5w4INW3A/8fAUT6LUZNKaP+n2d8rk=; b=vu+KyAEyZDJusORJvVPFo1hxmUnfLbz0YRZuK7jTRr7qBVBnsPpRBuel40UogicsON+2tk/hbuf50expQwQ5zNlCxxCZAQJAPGUnK45H3kzZ6SrzKqEGFfKV+deFBP5u; Received: from [68.4.207.246] (port=1599 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UdPoP-0003KU-WE; Fri, 17 May 2013 12:55:30 -0600 From: "Donald F Coffin" To: "'Mike Jones'" , "'Phil Hunt'" , References: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 17 May 2013 11:53:41 -0700 Message-ID: <015101ce532f$d9e75d70$8db61850$@reminetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGc2XTV0stTXKINHA5eqQN7Dtb7MgNZWJg/mVHfx4A= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 18:56:05 -0000 The statement "Keep in mind that client credential is only used with the token endpoint over TLS connection. It is NOT used to access resources directly." is incorrect. Section 4.4 of RFC 6749 states: The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification). I have interpreted section 4.4 to imply that a client who has been granted access to resources via an authorization code, for example, may use their client credentials to access either a single resource or multiple resources for which they have been granted access. Although it is possible to never expire an access token obtained using client credentials, I believe not expiring the token, since it allows access to resources, is not desirable from a security stand point. On the other hand, the registration_access_token clearly will not allow a client to access any resources and can only be used with client application information. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com -----Original Message----- From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, May 16, 2013 3:27 PM To: Phil Hunt; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 This is nothing more than an RFC 6750 bearer token. These can expire, as explained in that draft. (The can also be issued an a manner that they don't expire.) Nothing new is being invented in this regard. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 16, 2013 2:35 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 All, In the dynamic registration draft, a new token type is defined called the "registration access token". Its use is intended to facilitate clients being able to update their registration and obtain new client credentials over time. The client credential is issued on completion of the initial registration request by a particular client instance. It appears the need for the registration access token arises from the implied assertion that client credentials should expire. --> Is anyone expiring client credentials? To date, we haven't had much discussion about client credential expiry. It leads me to the following questions: 1. Is there technical value with client credential/token expiry? Keep in mind that client credential is only used with the token endpoint over TLS connection. It is NOT used to access resources directly. 2. If yes, on what basis should client credential/token expire? a. Time? b. A change to the client software (e.g. version update)? c. Some other reason? 3. Is it worth the complication to create a new token type (registration access token) just to allow clients to obtain new client tokens? Keep in mind that client tokens are only usable with the AS token endpoint. Why not instead use a client token for dyn reg and token endpoint with the rule that once a client token has expired (if they expire), an expired token may still be used at the registration end-point. 4. Are there other reasons for the registration token? Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Fri May 17 12:01:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADEF21F97D0 for ; Fri, 17 May 2013 12:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bIcRDclLJ1B for ; Fri, 17 May 2013 12:01:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1342A21F9354 for ; Fri, 17 May 2013 12:01:09 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4HJ160K017539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 19:01:06 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HJ15JB015623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 19:01:06 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HJ15Dj027044; Fri, 17 May 2013 19:01:05 GMT Received: from [10.98.105.5] (/24.244.23.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 12:01:05 -0700 References: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> <015101ce532f$d9e75d70$8db61850$@reminetworks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <015101ce532f$d9e75d70$8db61850$@reminetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <57F130F2-AE65-4B78-A7B4-797965285067@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Fri, 17 May 2013 12:00:57 -0700 To: Donald F Coffin X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 19:01:16 -0000 That is incorrect. A client grant request still results in a separate access= token issued.=20 Phil On 2013-05-17, at 11:53, Donald F Coffin wr= ote: > The statement "Keep in mind that client credential is only used with the > token endpoint over TLS connection. It is NOT used to access resources > directly." is incorrect. Section 4.4 of RFC 6749 states: >=20 > The client can request an access token using only its client > credentials (or other supported means of authentication) when the client i= s > requesting access to the protected > resources under its control, or those of another resource owner that > have been previously arranged with the authorization server (the method of= > which is beyond the scope > of this specification). >=20 > I have interpreted section 4.4 to imply that a client who has been granted= > access to resources via an authorization code, for example, may use their > client credentials to access either a single > resource or multiple resources for which they have been granted access. > Although it is possible to never expire an access token obtained using > client credentials, I believe not expiring the > token, since it allows access to resources, is not desirable from a securi= ty > stand point. >=20 > On the other hand, the registration_access_token clearly will not allow a > client to access any resources and can only be used with client applicatio= n > information. >=20 > Best regards, > Don > Donald F. Coffin > Founder/CTO >=20 > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 >=20 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com >=20 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Thursday, May 16, 2013 3:27 PM > To: Phil Hunt; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Acce= ss > Token - draft-ietf-oauth-dyn-reg-10 >=20 > This is nothing more than an RFC 6750 bearer token. These can expire, as > explained in that draft. (The can also be issued an a manner that they > don't expire.) Nothing new is being invented in this regard. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Phil Hunt > Sent: Thursday, May 16, 2013 2:35 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access > Token - draft-ietf-oauth-dyn-reg-10 >=20 > All, >=20 > In the dynamic registration draft, a new token type is defined called the > "registration access token". Its use is intended to facilitate clients bei= ng > able to update their registration and obtain new client credentials over > time. The client credential is issued on completion of the initial > registration request by a particular client instance. >=20 > It appears the need for the registration access token arises from the > implied assertion that client credentials should expire.=20 > --> Is anyone expiring client credentials? >=20 > To date, we haven't had much discussion about client credential expiry. It= > leads me to the following questions: >=20 > 1. Is there technical value with client credential/token expiry? Keep in= > mind that client credential is only used with the token endpoint over TLS > connection. It is NOT used to access resources directly. >=20 > 2. If yes, on what basis should client credential/token expire? > a. Time? > b. A change to the client software (e.g. version update)? > c. Some other reason? >=20 > 3. Is it worth the complication to create a new token type (registration > access token) just to allow clients to obtain new client tokens? Keep in > mind that client tokens are only usable with the AS token endpoint. Why n= ot > instead use a client token for dyn reg and token endpoint with the rule th= at > once a client token has expired (if they expire), an expired token may sti= ll > be used at the registration end-point. >=20 > 4. Are there other reasons for the registration token? >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From asanso@adobe.com Fri May 17 12:06:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E6521F9727 for ; Fri, 17 May 2013 12:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.144 X-Spam-Level: X-Spam-Status: No, score=-104.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbuXImAhHfAs for ; Fri, 17 May 2013 12:06:37 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2316E21F92CB for ; Fri, 17 May 2013 12:06:34 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUZZ/utRCcp0PxekkCe3KYXWOsZtiwcSU@postini.com; Fri, 17 May 2013 12:06:37 PDT 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 r4HJ3HKs015773; Fri, 17 May 2013 12:03:18 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r4HJ6CGa019113; Fri, 17 May 2013 12:06:30 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 17 May 2013 12:06:29 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Fri, 17 May 2013 20:06:27 +0100 From: Antonio Sanso To: John Bradley Date: Fri, 17 May 2013 20:06:16 +0100 Thread-Topic: [OAUTH-WG] Recap of two well known OAuth related attacks Thread-Index: Ac5TMaGveFXDmV1tRVavf/Y1tbOrGg== Message-ID: <4B7A9E06-D5F6-4F81-AAD4-1C8F33B5E564@adobe.com> References: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> <59E470B10C4630419ED717AC79FCF9A96599A278@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 19:06:42 -0000 Hi *, I was wondering what you thing about the second "issue" described (the "Las= sie come home"). I have encountered lately in one enterprise installation and I think is fai= rly easy to make it wrong as well. Regards Antonio On May 17, 2013, at 5:46 PM, John Bradley wrote: > The implicit flow is secure in Connect, but we added a number of things t= o make it so. >=20 > The reason to have it in OAuth 2 is for clients in the browser there are = use cases for that and it allows the browser to receive and extract the tok= en without passing it to a web server backend. > Used as intended it is fine as the browser based JS App is receiving the = the token directly over TLS so there is no substitution attack possible. = =20 >=20 > The problem is when the client is not in the browser the browser itself i= s an attack surface, that an attacker can use to confuse a client. >=20 > If people want to do SSO based on OAuth they need to follow the example o= f Google, PayPal and others who are implementing Connect rather than rollin= g there own protocol on top of OAuth 2. >=20 > John B. >=20 >=20 > On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 wrote: >=20 >> One wonders that - if in hindsight - the implicit flow was a mistake to = include in the framework. Yes it saves a single round trip for use cases w= here the tokens are exposed to the UA, but it's not clear that optimization= is worth the security headaches that are going to be caused down the road = (or are already going on for that matter) by people using it in scenarios w= here it should not be (because as stated, it is easier). Probably would ha= ve been better to let the subset of cases that didn't need the extra step o= f the code just go ahead and implement it anyway, and ensure that the major= ity of native apps use cases would have been implemented with better securi= ty.=20 >>=20 >> adam >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Richer, Justin P. >> Sent: Wednesday, May 15, 2013 3:22 PM >> To: Antonio Sanso >> Cc: "WG "@il06exr01.mot.com >> Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks >>=20 >> The biggest problem with this attack is the passing of the access token = to a backend server (and its subsequent passing of that token to someone el= se) and the assumption that the presentation of the access token means that= the user is authenticated and present. It simply doesn't mean that, and th= is is a bad assumption that unfortunately many people make thanks to provid= ers like Facebook using OAuth (or, mostly-OAuth since they're not actually = RFC compliant) in the authentication protocol. >>=20 >> It's also a problem that so many people are using the implicit flow "bec= ause it's easy", missing the point of why it's there in the first place. Th= e implicit flow is really only intended for cases where you can't hide secr= ets from the user agent, cases like an in-browser application. The flow dia= grams that you have don't fit the implicit flow very well at all, since the= access token is getting passed back to some other service.=20 >>=20 >> -- Justin >>=20 >> On May 13, 2013, at 11:14 AM, Antonio Sanso >> wrote: >>=20 >>> Hi *, >>>=20 >>> I wrote a blog post showing two well known OAuth related attacks. I pas= te here the link for your consideration: >>>=20 >>> http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-= devil-wears.html >>>=20 >>> Any comment is more than appreciated. >>>=20 >>> Regards >>>=20 >>> Antonio >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Fri May 17 12:43:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61A221F922A for ; Fri, 17 May 2013 12:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMwvhETlCwwC for ; Fri, 17 May 2013 12:43:53 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7018B21F968D for ; Fri, 17 May 2013 12:43:52 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id m14so2798455eaj.0 for ; Fri, 17 May 2013 12:43:51 -0700 (PDT) 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=9hXN1dNqHIlxpc6z9yM34v7CLWE5Wi8WwXeUYCkipzM=; b=WwaLSOC6vCSMp1pEzjCmoRVIJ3KKGBnH1lx5huDNzzrZ0+ubx2pEYe0KWfSLPWsuIb 1JLKnlkjQhQN0uc1L7TBYlFTQzSMOrM+T+//b+WAuBsm38CUi25gHNOwn08EwfrJiv/i eHlvlyRFVuYKt67q8+KpN3H7iTHt+PPtYMSRhx93N1eenfeo48juXFKSChwCyaLQMhTd yPSuzcImh+Dfme4Fgu9AU+z+JZ0CEv797yVRc5y9pQ800TfxFmIXDmSw5+8kVfSwcl57 QGKr86L+Ea+4wS5pnswAVHihP1FXd38QMP57OvSj+8GsrgI4Cmga32RjWeo+9vjInNqY w1xA== X-Received: by 10.15.49.199 with SMTP id j47mr88952767eew.24.1368819831395; Fri, 17 May 2013 12:43:51 -0700 (PDT) Received: from [10.121.233.103] ([195.50.165.102]) by mx.google.com with ESMTPSA id n7sm21105375eeo.0.2013.05.17.12.43.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 12:43:49 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3DC5F8FD-0693-4699-9B1C-B0015619E00A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4B7A9E06-D5F6-4F81-AAD4-1C8F33B5E564@adobe.com> Date: Fri, 17 May 2013 21:43:46 +0200 Message-Id: <5FB00E1D-7F00-4033-A475-922C67A3F0F8@ve7jtb.com> References: <2AF08A9B-0E0A-42E1-9575-E582065D66D8@mitre.org> <59E470B10C4630419ED717AC79FCF9A96599A278@BY2PRD0411MB441.namprd04.prod.outlook.com> <4B7A9E06-D5F6-4F81-AAD4-1C8F33B5E564@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnLaH07vFvGvCrQfRZg4reXpdLpnJI9zQSQ4NTFk2xcxqIoONC63huSA46puYWptYU6z//t Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 19:43:53 -0000 --Apple-Mail=_3DC5F8FD-0693-4699-9B1C-B0015619E00A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes redirect URI matching is a problem. In Connect we mandate an exact = match because people are really bad at securing open relays. Trying = to pattern match the redirect also allows an attacker to circumvent the = fragment processing of the browser and generally increase the possible = attack surface. =20 There is the state parameter that can be used to maintain a relay state = at the client, there is no real need for anything other than an exact = match. =20 Anything other than an exact match on the registered redirect will lead = to sadness due to the client inevitably being unclear on the pattern = matching rules. John B. On 2013-05-17, at 9:06 PM, Antonio Sanso wrote: > Hi *, >=20 >=20 > I was wondering what you thing about the second "issue" described (the = "Lassie come home"). >=20 > I have encountered lately in one enterprise installation and I think = is fairly easy to make it wrong as well. >=20 > Regards >=20 > Antonio >=20 > On May 17, 2013, at 5:46 PM, John Bradley wrote: >=20 >> The implicit flow is secure in Connect, but we added a number of = things to make it so. >>=20 >> The reason to have it in OAuth 2 is for clients in the browser there = are use cases for that and it allows the browser to receive and extract = the token without passing it to a web server backend. >> Used as intended it is fine as the browser based JS App is receiving = the the token directly over TLS so there is no substitution attack = possible. =20 >>=20 >> The problem is when the client is not in the browser the browser = itself is an attack surface, that an attacker can use to confuse a = client. >>=20 >> If people want to do SSO based on OAuth they need to follow the = example of Google, PayPal and others who are implementing Connect rather = than rolling there own protocol on top of OAuth 2. >>=20 >> John B. >>=20 >>=20 >> On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 = wrote: >>=20 >>> One wonders that - if in hindsight - the implicit flow was a mistake = to include in the framework. Yes it saves a single round trip for use = cases where the tokens are exposed to the UA, but it's not clear that = optimization is worth the security headaches that are going to be caused = down the road (or are already going on for that matter) by people using = it in scenarios where it should not be (because as stated, it is = easier). Probably would have been better to let the subset of cases = that didn't need the extra step of the code just go ahead and implement = it anyway, and ensure that the majority of native apps use cases would = have been implemented with better security.=20 >>>=20 >>> adam >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Richer, Justin P. >>> Sent: Wednesday, May 15, 2013 3:22 PM >>> To: Antonio Sanso >>> Cc: "WG "@il06exr01.mot.com >>> Subject: Re: [OAUTH-WG] Recap of two well known OAuth related = attacks >>>=20 >>> The biggest problem with this attack is the passing of the access = token to a backend server (and its subsequent passing of that token to = someone else) and the assumption that the presentation of the access = token means that the user is authenticated and present. It simply = doesn't mean that, and this is a bad assumption that unfortunately many = people make thanks to providers like Facebook using OAuth (or, = mostly-OAuth since they're not actually RFC compliant) in the = authentication protocol. >>>=20 >>> It's also a problem that so many people are using the implicit flow = "because it's easy", missing the point of why it's there in the first = place. The implicit flow is really only intended for cases where you = can't hide secrets from the user agent, cases like an in-browser = application. The flow diagrams that you have don't fit the implicit flow = very well at all, since the access token is getting passed back to some = other service.=20 >>>=20 >>> -- Justin >>>=20 >>> On May 13, 2013, at 11:14 AM, Antonio Sanso >>> wrote: >>>=20 >>>> Hi *, >>>>=20 >>>> I wrote a blog post showing two well known OAuth related attacks. I = paste here the link for your consideration: >>>>=20 >>>> = http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-dev= il-wears.html >>>>=20 >>>> Any comment is more than appreciated. >>>>=20 >>>> Regards >>>>=20 >>>> Antonio >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_3DC5F8FD-0693-4699-9B1C-B0015619E00A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE3MTk0MzQ3WjAjBgkqhkiG9w0BCQQxFgQU/D6sLL0T 0+mn/u/KhFZIzCKj1kIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAkKsLiyIuPjS8nprYuWIx3dR4OP0Iggn2TCTyBFxa mc5kBPRc+JTav5b65EM0fd7XzPvHSDoqTdaZQIaOeG1SvEiHRkmYvwcykoNDTkMXyA13zjLZkBUg c7/GNQhStT72n8s//ieLEOxtCoqHfDxPTOyz95UJ96QFmkSLRteJYZykCwXhpyZMjF/NtMvhtUIH bk0LsI+2jBmr77VVuZHjxB4Wo8rVp8MxRHb5jVDBh6R2oQWM02keP3LXaENlt+l6Hgp7UxW/xUWW tl6NHVmhMBHcia8rg/l08/bCf9nLxYd8T+qeT42lsftjaFP15MYl+8LT0610QhxPFm+9Pyj6wwAA AAAAAA== --Apple-Mail=_3DC5F8FD-0693-4699-9B1C-B0015619E00A-- From Michael.Jones@microsoft.com Fri May 17 13:13:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA3B21F90DF for ; Fri, 17 May 2013 13:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WanJ4t6A7LNK for ; Fri, 17 May 2013 13:13:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 391AA21F8DFC for ; Fri, 17 May 2013 13:13:51 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.161.202) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.687.1; Fri, 17 May 2013 20:08:27 +0000 Received: from TK5EX14HUBC104.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.698.0 via Frontend Transport; Fri, 17 May 2013 20:08:26 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Fri, 17 May 2013 20:08:12 +0000 From: Mike Jones To: Phil Hunt , "Richer, Justin P." Thread-Topic: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUas2JA4xslwK7Eu6I2Qndjwd05kG/FsAgAAbFoCAAKOFAIAAf+YAgADupEA= Date: Fri, 17 May 2013 20:08:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> In-Reply-To: <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.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_4E1F6AAD24975D4BA5B16804296739436773435CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(50854003)(377424003)(199002)(189002)(377454002)(66654002)(85644002)(54094003)(51914003)(24454002)(15454003)(51444003)(59766001)(16406001)(15974865001)(47976001)(81542001)(47736001)(79102001)(56776001)(16236675002)(53806001)(74662001)(4396001)(16601075002)(69226001)(65816001)(71186001)(15202345002)(81342001)(20776003)(74502001)(47446002)(31966008)(46102001)(49866001)(54316002)(66066001)(80022001)(44976003)(76482001)(63696002)(54356001)(15395725003)(56816002)(77982001)(50986001)(55846006)(512874002)(33656001)(6806003)(51856001)(74706001)(74366001)(74876001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 20:13:59 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436773435CTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZmVlZGJhY2ssIFBoaWwuICBTb3JyeSBmb3IgdGhlIGRl bGF5ZWQgcmVzcG9uc2Ug4oCTIEkgd2FzIHByZXR0eSBmdWxseSBlbmdhZ2VkIGF0IHRoZSBFdXJv cGVhbiBJZGVudGl0eSBDb25mZXJlbmNlICh3aGVyZSBPQXV0aCAyLjAgd29uIHRoZSBhd2FyZCBm b3IgYmVzdCBuZXcgc3RhbmRhcmQ8aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTAyNj4g4pi6 KS4gIE15IGZlZWRiYWNrIG9uIHRoZSBwb2ludHMgcmFpc2VkIGlzIGlubGluZSBpbiBncmVlbuKA pg0KDQooUGVyaGFwcyBpZiBhbnkgb2YgeW91IHJlcGx5IHRvIHRoaXMgdGhyZWFkLCB5b3UgY291 bGQgYWxzbyBjaG9vc2UgYSBkaXN0aW5jdCBjb2xvciBmb3IgeW91ciBpbmxpbmUgcmVwbGllcywg c28gdGhhdCBpdCB3aWxsIGJlIGVhc2lseSBldmlkZW50IHdobyBzYWlkIHdoYXQuICBBcyBpdCBp cywganVzdCB0aGUgYmFjay1hbmQtZm9ydGggYmV0d2VlbiBQaGlsIGFuZCBKdXN0aW4gaXMgYWxy ZWFkeSB2ZXJ5IGRpZmZpY3VsdCB0byBmb2xsb3cuICBUaGFua3MuKQ0KDQpGcm9tOiBvYXV0aC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFBoaWwgSHVudA0KU2VudDogVGh1cnNkYXksIE1heSAxNiwgMjAxMyAxMjo1NCBQTQ0KVG86 IFJpY2hlciwgSnVzdGluIFAuDQpDYzogb2F1dGhAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIExhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEw DQoNCkp1c3RpbiwNCg0KVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbi4gTW9yZSBjb21tZW50cyBi ZWxvdy4uLg0KDQpCVFcuIEknbSBoYXBweSB0byBjb250cmlidXRlIHRleHQuIEp1c3Qgd2FudCB0 byBnZXQgdG8gc29tZSByb3VnaCBhZ3JlZW1lbnQgZmlyc3QuICBGb3IgZXhhbXBsZSwgSSB0aGlu ayB3ZSBuZWVkIHRvIGhhdmUgYSBhd2F5IHRvIHJlY29nbml6ZSB0d28gcGllY2VzIG9mIHNvZnR3 YXJlIGFzIGJlaW5nIHRoZSBzYW1lIChldmVuIGlmIHNlbGYtYXNzZXJ0ZWQpLiAgT25jZSBkZWZp bmVkLCBJIGNhbiBwdXQgdG9nZXRoZXIgc29tZSBpbnRybyB0ZXh0LCBldGMuDQoNClBoaWwNCg0K QGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPg0KDQpPbiAyMDEzLTA1LTE2LCBhdCA1OjE2IEFNLCBSaWNoZXIsIEp1c3RpbiBQLiB3cm90 ZToNCg0KT24gTWF5IDE1LCAyMDEzLCBhdCAxMDozMCBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRA b3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KIHdyb3RlOg0KDQpPbiAy MDEzLTA1LTE1LCBhdCA1OjUzIFBNLCBSaWNoZXIsIEp1c3RpbiBQLiB3cm90ZToNCg0KUGhpbCwg bWFueSB0aGFua3MgZm9yIHRoZSBleHRyZW1lbHkgdGhvcm91Z2ggcmV2aWV3ISBJdCBpcyB2ZXJ5 IHVzZWZ1bCBpbmRlZWQuDQoNCk15IGNvbW1lbnRzIGFuZCByZXNwb25zZXMgdG8gZWFjaCBwb2lu dCBhcmUgaW5saW5lLg0KDQpPbiBNYXkgMTUsIDIwMTMsIGF0IDQ6MzAgUE0sIFBoaWwgSHVudCA8 cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6 DQoNCkl0IHNlZW1zIHVuZm9ydHVuYXRlIHRoYXQgSSBoYXZlIG5vdCBnb3R0ZW4gYSBjaGFuY2Ug dG8gZ2V0IGludG8gdGhpcyBsZXZlbCBvZiBkZXRhaWwgbXVjaCBlYXJsaWVyLiBCdXQgdGhlbiwg SSBndWVzcyB0aGF0J3Mgd2hhdCBMQyByZXZpZXcgaXMgZm9yISBNeSBhcG9sb2dpZXMgZm9yIG5v dCBnZXR0aW5nIG1hbnkgb2YgdGhlc2UgY29uY2VybnMgdG8gdGhlIFdHIG11Y2ggZWFybGllci4N Cg0KT3ZlcmFsbA0KLS0tLS0tLS0tLS0NCkkgdGhpbmsgZHluYW1pYyByZWdpc3RyYXRpb24gaXMg YSBjcml0aWNhbCBwYXJ0IG9mIHRoZSBPQXV0aCBmcmFtZXdvcmsgbm93IHRoYXQgd2UgYXJlIHN0 YXJ0aW5nIHRvIGNvbnNpZGVyIGhvdyBpbmRpdmlkdWFsIGNsaWVudCBhcHBsaWNhdGlvbnMgc2hv dWxkIG9wZXJhdGUgd2hlbiB0aGVyZSBpcyBvbmUgb3IgbW9yZSBkZXBsb3ltZW50cyBvZiBhIHBh cnRpY3VsYXIgcmVzb3VyY2UgQVBJLiBXZSd2ZSBtb3ZlZCBmcm9tIHRoZSBzaW1wbGUgdXNlIGNh c2Ugb2YgYSBzaW5nbGUgQVBJIHByb3ZpZGVyIGxpa2UgRmFjZWJvb2sgb3IgRmxpY2tyIGFuZCBt b3ZlZCBvbiB0byBzdGFuZGFyZHMgYmFzZWQsIG9wZW4gc291cmNlIGJhc2VkLCBhbmQgY29tbWVy Y2lhbCBiYXNlZCBkZXBsb3ltZW50cyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgc2VydmljZSBl bmRwb2ludHMgYW5kIG1hbnkgY2xpZW50cyB0byBtYW5hZ2UuDQoNClRoZSBkeW5hbWljIHJlZ2lz dHJhdGlvbiBzcGVjIGlzIGFjdHVhbGx5IGRlYWxpbmcgd2l0aCBhIGNvdXBsZSBvZiBpc3N1ZXMg dGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIG1hZGUgbW9yZSBjbGVhciBpbiBlYXJseSBwYXJ0IG9m IHRoZSBzcGVjOg0KDQoxLiAgSG93IGlzIGEgbmV3IGNsaWVudCBhcHBsaWNhdGlvbiByZWNvZ25p emVkIGZvciB0aGUgZmlyc3QgdGltZSB3aGVuIGRlcGxveWVkIGFnYWluc3QgYSBwYXJ0aWN1bGFy IFNQIGVuZHBvaW50PyAgU2hvdWxkIGNsaWVudHMgYWN0dWFsbHkgYXNzZXJ0IGFuIGFwcGxpY2F0 aW9uX2lkIFVVSUQgdGhhdCBuZXZlciBjaGFuZ2VzIGFuZCBwb3NzaWJseSBhIHZlcnNpb24gaWQg dGhhdCBkb2VzIGNoYW5nZSB3aXRoIHZlcnNpb25zPw0KDQpJbiB0aGUgZ2VuZXJhbCBjYXNlLCB3 aHkgaXMgYW55IHJlY29nbml0aW9uIHJlcXVpcmVkPyBJZiB5b3UncmUgZG9pbmcgdGhpbmdzIGFz IHBhcnQgb2YgYSBsYXJnZXIgcHJvdG9jb2wgZWNvc3lzdGVtLCBsaWtlIEJsdWUgQnV0dG9uKyBv ciBhIHBhcnRpY3VsYXIgT3BlbklEIENvbm5lY3QgcHJvdmlkZXIsIHRoZW4geW91IGNhbiBkZWZp bmUgc2VtYW50aWNzIGZvciB0eWluZyB0b2dldGhlciBjbGFzc2VzIG9mIGNsaWVudHMgKHNlZSBi ZWxvdyBmb3IgbW9yZSBkaXNjdXNzaW9uIG9uIHRoaXMgdmVyeSBwb2ludCkuIEJ1dCBpbiBnZW5l cmFsLCBhIGNsaWVudCBpcyBqdXN0IGdvaW5nIHRvIHNob3cgdXAgYXMgYSBuZXcgaW5zdGFuY2Ug dG8gdGhlIEFTIGFuZCBnZXQgaXNzdWVkIGEgbmV3LCB1bmlxdWUgY2xpZW50X2lkLCBhbmQgdGhh dCdzIHRoYXQuDQoNCkkgdGhpbmsgd2UgaGF2ZSB0byBkZWZpbmUgbW9yZSBjbGVhcmx5IHdoYXQg YW4gImluc3RhbmNlIiBpcy4gRm9yIG1lLCB0aGVyZSBhcmUgYXBwbGljYXRpb25zIGFuZCB0aGVy ZSBhcmUgaW5zdGFuY2VzIG9mIHRoYXQgYXBwbGljYXRpb24uICBJdCBpcyB1c2VmdWwgdG8gdW5k ZXJzdGFuZCB0aGF0IGEgY2xpZW50IGFwcGxpY2F0aW9uIHJlcHJlc2VudHMgYSBzZXQgb2YgY29k ZSB0aGF0IHNob3VsZCBiZWhhdmUgaW4gYSBjb25zaXN0ZW50IHdheS4gIEl0IHNlZW1zIHRvIG1l IHRoZSBmaXJzdCB0aW1lIGEgbmV3IGFwcGxpY2F0aW9uIHNob3dzIHVwIGlzIHZlcnkgZGlmZmVy ZW50IGZyb20gdGhlIHN1YnNlcXVlbnQgaW5zdGFuY2VzIHRoYXQgcmVnaXN0ZXIuIEZvciBleGFt cGxlLCBhZnRlciB0aGUgZmlyc3QgcmVnaXN0cmF0aW9uLCBzdWJzZXF1ZW50IGluc3RhbmNlcyBk b24ndCBuZWVkIHNwZWNpYWwgcmV2aWV3IG9yIGFwcHJvdmFsIHRvIHRoZSBzYW1lIGRlZ3JlZS4N Cg0KQnV0IHdpdGhvdXQgb3RoZXIgbWVjaGFuaXNtcyB0byB0aWUgdGhpbmdzIHRvZ2V0aGVyLCB0 aGVyZSdzIG5vIHdheSBmb3IgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8ga25vdyBpZiBhbnkg Y2xpZW50IGluc3RhbmNlIGlzIHRpZWQgdG8gYW55IG90aGVyIGNsaWVudCBpbnN0YW5jZS4gVGhl cmVmb3JlLCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBhbiBBUywgdGhlIGZpcnN0IGluc3RhbmNl IG9mIGFuIGFwcGxpY2F0aW9uIChpLmUuLCBwYXJ0aWN1bGFyIGNvbmZpZ3VyYXRpb24gb2YgYSBz ZXQgb2YgY29kZSkgdG8gcmVnaXN0ZXIgaXMgbm8gZGlmZmVyZW50IHRvIHN1YnNlcXVlbnQgaW5z dGFuY2VzIG9mIHRoYXQgc2FtZSBhcHBsaWNhdGlvbi4gSG93IHdlcmUgeW91IGVudmlzaW9uaW5n IGFuIEFTIGtub3dpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZmlyc3QgYW5kIHN1YnNl cXVlbnQgaW5zdGFuY2VzIG9mIGFuIGFwcGxpY2F0aW9uLCBzcGVjaWZpY2FsbHk/IElmIHRoZXJl J3MgYW4gImFwcGxpY2F0aW9uX2lkIiBsaWtlIHlvdSBtZW50aW9uIGFib3ZlLCBJIHRoaW5rIGl0 IHJhaXNlcyBtb3JlIHF1ZXN0aW9ucyB0aGFuIGl0IHJlc29sdmVzOiBXaG8gaXNzdWVzIHRoZSBh cHBsaWNhdGlvbl9pZCwgc29tZSBzZXJ2ZXIgb3IgdGhlIGFwcGxpY2F0aW9uIGl0c2VsZj8gSXMg aXQgdmFsaWRhdGVkIGF0IGFsbD8gU2hvdWxkIGl0IGJlIGNvbnNpZGVyZWQgc2VjcmV0PyBXaGF0 IGhhcHBlbnMgd2hlbiBzb21lb25lIHNpbXBseSBzdGVhbHMgYW4gYXBwbGljYXRpb25faWQ/IERv ZXMgYW4gQVMgaGF2ZSB0byBkbyBhbnl0aGluZyB0byBjaGVjayB3aXRoIGFueSBvdGhlciBBUyB0 byBzZWUgaWYgdGhlIGFwcGxpY2F0aW9uX2lkIGhhcyBhbHJlYWR5IGJlZW4gdXNlZCBlbHNld2hl cmU/DQoNCkkgZG8gYWdyZWUgdGhhdCBhIGRpc2N1c3Npb24gb2YgImluc3RhbmNlIHZzLiBhcHBs aWNhdGlvbiIgd291bGQgYmUgaGVscGZ1bCBpbiBjbGVhcmluZyB0aGlzIHVwLCBJJ2xsIG1ha2Ug YSBub3RlIHRvIGFkZCB0ZXh0IHRvIHRoYXQgZWZmZWN0LiAoV2UgaGFkIHRvIGRvIHNvbWV0aGlu ZyBzaW1pbGFyIGZvciBCQispDQoNCkkgdGhpbmsgaXQgaXMgc2ltcGxlIGVub3VnaCB0byBhdCBs ZWFzdCBhZGQgYSBzZWxmIGdlbmVyYXRlZCBVVUlEIGZvciB0aGUgYXBwbGljYXRpb24gSUQuICBU aG91Z2ggSSB3b3VsZCBhbGxvdyBmb3IgY2FzZXMgd2hlcmUgdGhlIGFwcGxpY2F0aW9uIElEIGlz IGFzc2lnbmVkIHdoZW4gdGhlIGNsaWVudCBkZXZlbG9wZXIgYW5kIHRoZSBBUElzIG93bmVyIGRv IGEgZm9ybWFsIGFzc2lnbm1lbnQgb2YgYXBwbGljYXRpb24gSURzLg0KDQpJbiBhIHNlbnNlIHRo aXMgaXMganVzdCBhIGxvd2VyIHRlY2ggd2F5IG9mIGRvaW5nIGl0IHRoYW4gd2hhdCB5b3UgZGVz Y3JpYmVkIGFzIHRoZSBpbml0aWFsIGNsaWVudCBjcmVkZW50aWFsIGluIEJsdWUgQnV0dG9uKyB3 aGVyZSB5b3UgZW5jb2RlZCBleHRyYSBjbGFpbXMgaW50byB0aGUgaW5pdGlhbCBhcHAgY3JlZGVu dGlhbC4NCg0KV2hhdCB0aGUgVVVJRCBkb2VzIGlzIGxpbmsgbXVsdGlwbGUgaW5zdGFuY2VzIG9m IGEgY2xpZW50IGFwcCB0b2dldGhlciBhcyB0aGUgc2FtZSAidGhpbmciIHRoYXQgc2hvdWxkIGhh dmUgc2ltaWxhciBoZXVyaXN0aWNzL2JlaGF2aW91cnMuICBUaGlzIGlzIHZlcnkgdXNlZnVsIGlm IHlvdSB3YW50IHRvIGJlIGFibGUgdG8gcmV2b2tlIGFjY2VzcyB0byBhIHNldCBvZiBjbGllbnRz IGlkZW50aWZpZWQgYnkgYXBwbGljYXRpb24gaWQgKG9yIGEgdmVyc2lvbiBvZiB0aGF0IGFwcCku DQoNCldoaWxlIEnigJltIHN5bXBhdGhldGljIHRvIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGV2 ZW50dWFsbHkgZG9pbmcgd29yayBvbiBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBpbnN0YW5jZXMg b2YgYW4gT0F1dGggY2xpZW50LCBJ4oCZbGwgbm90ZSB0aGF0IGluIFJGQyA2NzQ5IG9yIFJGQyA2 NzUwIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYSBjbGllbnQgaW5zdGFuY2UuICBUaGVyZSBh cmUgb25seSBjbGllbnRzLCB3aGljaCBhcmUgaWRlbnRpZmllZCBieSBjbGllbnRfaWQgdmFsdWVz LiAgSWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIGNsaWVudCBpbnN0YW5jZXMsIHdlIHNob3VsZCBy ZWNoYXJ0ZXIgdG8gYWRkIHRoaXMgbmV3IHdvcmsgYXMgYSB3b3JraW5nIGdyb3VwIGRlbGl2ZXJh YmxlLiAgV2Ugc2hvdWxkIG5vdCB0cnkgdG8gc2hvZWhvcm4gYml0cyBhbmQgcGllY2VzIG9mIGl0 IGludG8gdGhlIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNwZWMsIGFueSBtb3JlIHRoYW4gd2Ugc2hv dWxkIGhhdmUgdHJpZWQgdG8gc2hvZWhvcm4gaXQgaW50byBSRkMgNjc0OSBvciBSRkMgNjc1MC4g IE9hdXRoLWR5bi1yZWcgaXMgdGhlcmUgdG8gcmVnaXN0ZXIgY2xpZW50cyBhcyBkZWZpbmVkIGlu IFJGQyA2NzQ5LiAgSXTigJlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8gZXh0ZW5kIHdoYXQgYW4g T0F1dGggY2xpZW50IGlzIGluIG5ldyB3YXlzLg0KDQoyLiAgSG93IGFyZSBjbGllbnQgY3JlZGVu dGlhbHMgbWFuYWdlZC4gQXJlIHdlIGFzc3VtaW5nIGNsaWVudCBjcmVkZW50aWFscyBoYXZlIGEg bGltaXRlZCBsaWZldGltZSBvciByb3RhdGlvbiBwb2xpY3k/DQoNClRoZSBpbnRlbnQgd2FzIHRo YXQgY2xpZW50X3NlY3JldCBjb3VsZCBiZSByb3RhdGVkLCBhcyBpbmRpY2F0ZWQgYnkgdGhlIGV4 cGlyZXNfYXQgbWVtYmVyIG9mIHRoZSByZXNwb25zZS4gSWYgYSBjbGllbnQncyBzZWNyZXQgZXhw aXJlcywgaXQgY2FsbHMgdGhlIHJlYWQgb3BlcmF0aW9uIG9uIHRoZSBDbGllbnQgQ29uZmlndXJh dGlvbiBFbmRwb2ludCAowqc0LjIpIHRvIGdldCBpdHMgbmV3IGNsaWVudF9zZWNyZXQuIElmIHRo aXMgaXMgdW5jbGVhciBpbiB0aGUgY3VycmVudCB0ZXh0ICh3aGljaCBJIHN1c3BlY3QgaXQgbWF5 IGJlIGFmdGVyIG11bHRpcGxlIHJlZmFjdG9yaW5ncyksIHRoZW4gSSB3ZWxjb21lIHN1Z2dlc3Rp b25zIGFuZCBzcGVjaWZpYyB0ZXh0IGFzIHRvIGhvdyB0byBtYWtlIHRoYXQgY2xlYXIuDQpTb21l dGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuDQoNClNob3VsZCB0aGlzIGJl IHVwIGluIHRoZSBpbnRyb2R1Y3RvcnkgdGV4dCwgc29tZXdoZXJlIGVsc2UsIG9yIGhhdmUgaXRz IG93biBzZWN0aW9uPw0KDQpJJ20gc3RhcnRpbmcgdG8gdGhpbmsgY3JlZGVudGlhbCBtYW5hZ2Vt ZW50IGlzIGEga2V5IHBhcnQgb2YgdGhlIGRyYWZ0LiBJdCBtYXkgYmUgd29ydGggaW50cm9kdWNp bmcgYSBzcGVjaWZpYyBzZWN0aW9uIG91dGxpbmcgdGhlIHJlZ2lzdHJhdGlvbiBsaWZlLWN5Y2xl LCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIHVzYWdlLCBhbmQgY2xpZW50IHRva2VuIHVzYWdl IGFuZCBib290c3RyYXBwaW5nLg0KDQpJIHRoaW5rIHRoYXQgYWRkaW5nIGEgZGlzY3Vzc2lvbiBv biB0aGlzIHdvdWxkIGJlIGZpbmUsIGFzIGl0IGNvdWxkIGhlbHAgZGV2ZWxvcGVycyB1bmRlcnN0 YW5kIHRoZSB3b3JrZmxvdyBvZiByZWdpc3RlcmluZywgdXNpbmcsIGFuZCB1cGRhdGluZyByZWdp c3RlcmVkIGNsaWVudHMuDQoNCkhvdyBkb2VzIGEgY2xpZW50IGF1dGhlbnRpY2F0ZSB0aGUgZmly c3QgdGltZSBhbmQgc3Vic2VxdWVudCB0aW1lcyB0byB0aGUgcmVnaXN0cmF0aW9uIHNlcnZpY2U/ DQoNClRoaXMgaXMgYSBzZXBhcmF0ZSBxdWVzdGlvbiBhbGwgdG9nZXRoZXIsIGFzIGl0IGRvZXMg bm90IGludm9sdmUgdGhlIGNsaWVudF9zZWNyZXQgb3IgY2xpZW50X2lkIGF0IGFsbC4gUmF0aGVy LCB0aGUgZmlyc3QgdGltZSB0aGUgY2xpZW50IHNob3dzIHVwIHRvIHRoZSByZWdpc3RyYXRpb24g c2VydmljZSwgaXQgbWF5IGVpdGhlcjoNCiAgLSBOb3QgYXV0aGVudGljYXRlIGF0IGFsbCAodGhp cyBpcyB0aGUgdHJ1ZSBwdWJsaWMsIG9wZW4gcmVnaXN0cmF0aW9uLCBhbmQgaXQgaXMgcmVjb21t ZW5kZWQgdGhhdCBzZXJ2ZXJzIGRvIHRoaXMpDQogLSBBdXRoZW50aWNhdGUgdXNpbmcgYW4gT0F1 dGggMi4wIHRva2VuICh3aGljaCBBVE0gbWVhbnMgYSBiZWFyZXIgdG9rZW4pLiBIb3cgdGhlIGNs aWVudCBnZXRzIHRoYXQgYmVhcmVyIHRva2VuIGFuZCB3aGF0IHRoZSBiZWFyZXIgdG9rZW4gbWVh bnMgdG8gdGhlIEFTIGJleW9uZCAidGhpcyBjbGllbnQgaXMgYXV0aG9yaXplZCB0byByZWdpc3Rl ciIgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgc3BlYywgYnkgZGVzaWduLg0KDQpTdWJzZXF1ZW50 IHRpbWVzIHRoYXQgdGhlIHNhbWUgcmVnaXN0ZXJlZCBjbGllbnQgKGJ5IHdoaWNoIHdlIG1lYW4g dGhlIHNhbWUgaW5zdGFuY2Ugb2YgYSBjbGllbnQgd2l0aCBhIHBhcnRpY3VsYXIgY2xpZW50X2lk KSBzaG93cyB1cCBhdCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IChhY3R1YWxseSwgdGhlIENs aWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50KSwgaXQgdXNlcyBpdHMgUmVnaXN0cmF0aW9uIEFj Y2VzcyBUb2tlbiB0aGF0IGl0IHdhcyBpc3N1ZWQgb24gaW5pdGlhbCByZWdpc3RyYXRpb24uIFRo aXMgaXMgYW4gT0F1dGggMi4wIEJlYXJlciB0b2tlbiB0aGF0IGlzIHVuaXF1ZSB0byB0aGUgY2xp ZW50IGluc3RhbmNlLg0KDQpTb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJh ZnQuDQoNCk9LLCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biBjYW4gYmUgZXhwYW5kZWQsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIHJlc3Qgb2YgaXQgaXMgYWxy ZWFkeSBpbiB0aGVyZSBpbiDCpzMuIEknZCB3ZWxjb21lIHN1Z2dlc3Rpb25zIG9uIHdoaWNoIGJp dHMgb2YgdGhpcyBjb3VsZCBiZSBtYWRlIGNsZWFyZXIuDQoNClNlZSB0aGUgZGlzY3Vzc2lvbiBv biB3aGF0IHRoZSByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGlzIGluIHRoZSB0aHJlYWQg4oCc Q2xpZW50IENyZWRlbnRpYWwgRXhwaXJ5IGFuZCBuZXcgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tl biAtIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMOKAnS4gIEkgd2lsbCB3b3JrIHdpdGggSnVz dGluIHRvIGFwcGx5IHRoZXNlIGNsYXJpZmljYXRpb25zIHRvIHRoZSBzcGVjaWZpY2F0aW9uLiAg VGhpcyBtYXkgZ28gaW50byB0aGUgcHJvcG9zZWQgY3JlZGVudGlhbCBtYW5hZ2VtZW50IG92ZXJ2 aWV3IHNlY3Rpb24gZGlzY3Vzc2VkIGFib3ZlLg0KDQozLiAgSG93IGlzIHZlcnNpb25pbmcgb2Yg Y2xpZW50cyBtYW5hZ2VkPyBTaG91bGQgZWFjaCBuZXcgdmVyc2lvbiBvZiBhIGNsaWVudCByZXF1 aXJlIGEgY2hhbmdlIGluIGNsaWVudCByZWdpc3RyYXRpb24gaW5jbHVkaW5nIHBvc3NpYmx5IGNo YW5naW5nIGNsaWVudF9pZCBhbmQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbD8gSSBkb24ndCBo YXZlIGEgc3Ryb25nIGZlZWxpbmcsIGJ1dCBpdCBpcyBzb21ldGhpbmcgdGhhdCBpbXBsZW1lbnRv cnMgc2hvdWxkIGNvbnNpZGVyLg0KDQpUaGlzIGlzIHVwIHRvIHRoZSBBUywgcmVhbGx5LCBhbmQg SSBkb24ndCB0aGluayB0aGF0IGFueSBnbG9iYWwgcG9saWN5IHdvdWxkIGV2ZXIgZmx5IGhlcmUu IEVzcGVjaWFsbHkgaWYgeW91IGNvbnNpZGVyIHRoYXQgdGhlIGVudGlyZSBub3Rpb24gb2YgInZl cnNpb24iIGlzIG1vcmUgZmx1aWQgdGhlc2UgZGF5cyB0aGFuIGl0IGV2ZXIgaGFzIGJlZW4uIEkg d291bGRuJ3QgbWluZCBhZGRpbmcgYSBkaXNjdXNzaW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBpZiBpdCBtZXJpdHMgbWVudGlvbmluZyB0aG91Z2gsIHNvIHRoYXQgd2UgY2FuIGhl bHAgYm90aCBjbGllbnQgZGV2ZWxvcGVycyBhbmQgc2VydmVyIGRldmVsb3BlcnMgaW5zdGl0dXRl IHJlYXNvbmFibHkgZ29vZCBwb2xpY3kuDQoNCkkgZ3Vlc3MgdGhlIGlzc3VlIGlzIHRoYXQgd2hl biBhIGNsaWVudCB1cGdyYWRlcyBpdCBtYXkgaGF2ZSBhY2Nlc3MgdG8gdGhlIG9sZCBjcmVkZW50 aWFscy4gV2hhdCBpcyB0aGUgaW50ZW50IHRoZW4gb2YgcmVnaXN0cmF0aW9uLiAgU2luY2UgeW91 IGhhdmUgYW4gdXBkYXRlIGFyZSBjbGllbnRzIGV4cGVjdGVkIHRvIHVwZGF0ZSAvcmUtcmVnaXN0 ZXIgb3Igbm90PyAgSSdtIG5vdCBzdXJlIHRoaXMgaXMgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9u IGJ1dCBtb3JlIHBhcnQgb2YgdGhlIHdob2xlIGNoYW5nZSBtYW5hZ2VtZW50IGZ1bmN0aW9uIGR5 bmFtaWMgcmVnaXN0cmF0aW9uIHN1cHBvcnRzLg0KDQpJZiB5b3VyIHVwZ3JhZGVkIHZlcnNpb24g b2YgdGhlIGNsaWVudCBzdGlsbCBoYXMgYWNjZXNzIHRvIGl0cyBvbGQgY3JlZGVudGlhbHMsIHdo eSB3b3VsZG4ndCBpdCBqdXN0IHVzZSB0aG9zZT8gSSBkb24ndCBzZWUgYSByZWFzb24gZm9yIGZv cmNpbmcgYSByZS1yZWdpc3RyYXRpb24uIE5vciBkbyBJIHNlZSBhbnkgd2F5IHRoYXQgYW4gQVMg d291bGQgZXZlbiBiZSBhYmxlIHRvIHRlbGwgdGhhdCBhIGNsaWVudCBoYWQgYmVlbiB1cGdyYWRl ZC4gQW4gdXBncmFkZWQgY2xpZW50IGFsd2F5cyBoYXMgdGhlICpvcHRpb24qIG9mIHJlLXJlZ2lz dGVyaW5nIGl0c2VsZiBhbmQgZ2V0dGluZyBhIG5ldyBjbGllbnRfaWQuDQpJIHRoaW5rIHRoZSBj b25jZXJuIGhlcmUgaXMgdGhhdCByb3RhdGlvbiBvZiBjbGllbnQgY3JlZGVudGlhbCBpcyBub3Qg c29tZXRoaW5nIGRpc2N1c3NlZCBiZWZvcmUuIEJlZm9yZSB3ZSBwdXQgaXQgaW4gdGhlIHNwZWMg d2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSByZWFzb25zIGZvciBkb2luZyBpdCBhbmQgd2hhdCBwcm9i bGVtcyBpdCBzb2x2ZXMuDQoNCkkgdGhpbmsgdGhpcyBtYXkgYmUganVzdCBhIGNhc2Ugb2YgbGV0 dGluZyBwZW9wbGUgZXhjaGFuZ2UgY3JlZGVudGlhbHMgZm9yIHdoYXRldmVyIHJlYXNvbiB0aGV5 IGZlZWwgaXMgYXBwcm9wcmlhdGUuICBUaGUgdmVyc2lvbiB1cGdyYWRlIHRoaW5nIHN1Z2dlc3Rz IHRoYXQgd2hlbiBhIGNsaWVudCBpcyB1cGdyYWRlZCBpdCBzaG91bGQgZ28gdG8gdGhlIHJlZ2lz dHJhdGlvbiBzZXJ2ZXIgdG8gInJlLXJlZ2lzdGVyIi4gIERlcGVuZGluZyBvbiB0aGUgcG9saWN5 IG9mIHRoZSBzZXJ2ZXIsIGl0IG1heSAob3IgbWF5IG5vdCkgcmVjZWl2ZSBhIG5ldyBjbGllbnRf aWQgYW5kL29yIG5ldyBjcmVkZW50aWFsLg0KDQpPbmUgb2YgdGhlIGJlc3QgYmVuZWZpdHMgSSBj YW4gdGhpbmsgb2YgaXMgaWYgeW91IGRpc2NvdmVyIGEgdmVyc2lvbiBvZiBhIGNsaWVudCBoYXMg YSBwcm9ibGVtLCBiZWluZyBhYmxlIHRvIHNlbGVjdCBhIGdyb3VwIG9mIGNsaWVudHMgYnkgc29m dHdhcmUgYW5kIHZlcnNpb24gaXMgaW1wb3J0YW50LiBUaHVzIGlmIGNsaWVudF9pZCBkb2Vzbid0 IHRyYWNlIHRvIGEgcGFydGljdWxhciBzb2Z0d2FyZSBhbmQgdmVyc2lvbiwgdGhhdCBtYWtlcyBp dCBoYXJkIHRvIGRvLiAgSSAgdGhpbmsgeW91IHRhbGtlZCBhYm91dCB0aGlzIGFzIGFuIGlzc3Vl IGZvciBCbHVlIEJ1dHRvbisNCg0KQWdhaW4sIFJGQyA2NzQ5IGRlZmluZXMgbm8gY2xpZW50IGlu c3RhbmNlcyBvciBncm91cHMgb2YgY2xpZW50cywgdGhlcmVmb3JlIEkgYmVsaWV2ZSB0aGF0IGl0 4oCZcyBpbmFwcHJvcHJpYXRlIHRvIGRvIHNvIGhlcmUuICBXZSBkb27igJl0IG5lZWQgdG8gYm9p bCB0aGUgb2NlYW4uICBJZiBhIG5ldyBjaGFydGVyIGl0ZW0gaXMgYXBwcm92ZWQgdG8gZG8gd29y ayBvbiBjbGllbnQgaW5zdGFuY2VzIGFuZCBwcm90b2NvbCBlbGVtZW50cyB0byB1c2UgYW5kIGV4 cHJlc3MgdGhlbSwgdGhhdOKAmXMgdGhlIHRpbWUgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNv bnNpZGVyIHRoYXQgcG9zc2liaWxpdHkg4oCTIG5vdCBhcyBwYXJ0IG9mIER5bmFtaWMgQ2xpZW50 IFJlZ2lzdHJhdGlvbi4NCg0KNC4gIFdoYXQgaXMgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9r ZW4/IFdoeSBpcyBpcyB1c2VkPyBXaGF0IGlzIGl0cyBsaWZlLWN5Y2xlPyAgV2hlbiBpcyBpdCBp c3N1ZWQsIHdoZW4gaXMgaXQgY2hhbmdlZD8gV2hlbiBpcyBpdCBkZWxldGVkPw0KDQpTZWUgdGhl IHJlc3BvbnNlIGFib3ZlIGFib3ZlIGFuZCB0aGUgZGVmaW5pdGlvbiBpbiDCpzEuMjoNCg0KUmVn aXN0cmF0aW9uIEFjY2VzcyBUb2tlbjogQW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBpc3N1ZWQg YnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRocm91Z2ggdGhlIENsaWVudCBSZWdpc3RyYXRp b24gRW5kcG9pbnQgd2hpY2ggaXMgdXNlZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0ZSBp dHNlbGYgZHVyaW5nIHJlYWQsIHVwZGF0ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiBUaGlzIHRv a2VuIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgQ2xpZW50Lg0KDQpJZiB0aGlzIGNh biBiZSBjbGFyaWZpZWQsIEkgd2VsY29tZSB0ZXh0IHN1Z2dlc3Rpb25zLg0KDQpUaGUgbGF0dGVy IHBhcnQgb2YgMS4yIGRpZG4ndCBzZWVtIGxpa2UgdGVybWlub2xvZ3kgYnV0IHJhdGhlciBhcmNo aXRlY3R1cmUgb3IgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRoYXQgZGVzY3JpYmVzIHdoYXQg dGhlIHNwZWMgZG9lcy4gVGhlIHRoaXJkIHBvaW50IGRvZXNuJ3Qgc2VlbSB0byBmaXQgd2l0aCB0 aGUgb3RoZXIgdHdvIGV4Y2VwdCB0byBzYXkgdGhhdCB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24g ZW5kcG9pbnRzIHVzZSB0aGVpciBvd24gYWNjZXNzIHRva2VucyBjYWxsZWQgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbnMuDQoNCg0KQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludDogVGhlIE9B dXRoIDIuMCBFbmRwb2ludCB0aHJvdWdoIHdoaWNoDQoNCiAgICAgIGEgQ2xpZW50IGNhbiByZXF1 ZXN0IG5ldyByZWdpc3RyYXRpb24uICBUaGUgbWVhbnMgb2YgdGhlIENsaWVudA0KDQogICAgICBv YnRhaW5pbmcgdGhlIFVSTCBmb3IgdGhpcyBlbmRwb2ludCBhcmUgb3V0IG9mIHNjb3BlIGZvciB0 aGlzDQoNCiAgICAgIHNwZWNpZmljYXRpb24uDQoNCg0KDQogICBvICBDbGllbnQgQ29uZmlndXJh dGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIuMCBFbmRwb2ludCB0aHJvdWdoDQoNCiAgICAgIHdo aWNoIGEgc3BlY2lmaWMgQ2xpZW50IGNhbiBtYW5hZ2UgaXRzIHJlZ2lzdHJhdGlvbiBpbmZvcm1h dGlvbiwNCg0KICAgICAgcHJvdmlkZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIHRo ZSBDbGllbnQuICBUaGlzIFVSTCBmb3INCg0KICAgICAgdGhpcyBlbmRwb2ludCBpcyBjb21tdW5p Y2F0ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbg0KDQogICAgICBTZXJ2ZXIg aW4gdGhlIENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25zZS4NCg0KDQoNCiAgIG8gIFJlZ2lzdHJh dGlvbiBBY2Nlc3MgVG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVkIGJ5IHRo ZQ0KDQogICAgICBBdXRob3JpemF0aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGllbnQgUmVnaXN0 cmF0aW9uIEVuZHBvaW50DQoNCiAgICAgIHdoaWNoIGlzIHVzZWQgYnkgdGhlIENsaWVudCB0byBh dXRoZW50aWNhdGUgaXRzZWxmIGR1cmluZyByZWFkLA0KDQogICAgICB1cGRhdGUsIGFuZCBkZWxl dGUgb3BlcmF0aW9ucy4gIFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoIGENCg0KICAgICAg cGFydGljdWxhciBDbGllbnQuDQoNClRoaXMgc2VjdGlvbiBpcyBtZWFudCB0byBqdXN0IGludHJv ZHVjZSB0aGUgbmV3IHRlcm1zIHRoYXQgYXJlIHRoZW4gZXhwbGFpbmVkIGluIGdyZWF0ZXIgZGV0 YWlsIHRocm91Z2hvdXQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBZZXMsIGl0J3MgYSBiaXQg YXJjaGl0ZWN0dXJlLCBidXQgb25seSBpbiB0aGUgc2Vuc2UgdGhhdCB5b3UgbmVlZCB0byBkZWZp bmUgdGhlIHRlcm1zIHRoYXQgbWFrZSB1cCB5b3VyIGFyY2hpdGVjdHVyZS4gSG93IHdvdWxkIHlv dSBzdWdnZXN0IHRoYXQgaXQgY2hhbmdlPw0KDQpQcm9iYWJseSB0aGlzIGlzIG1vcmUgYSBtYXR0 ZXIgb2Ygc3R5bGUuICBCdXQsIHdoYXQgaGFwcGVuZWQgZm9yIG1lIGlzIEkgbmF0dXJhbGx5IHNr aXBwZWQgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24sIGFzIEkgd2Fzbid0IGV4cGVjdGluZyBwcm90 b2NvbCBjb21wb25lbnRzIHRvIGJlIHRoZXJlLiAgInRlcm1pbm9sb2d5IiBpcyBzb21ldGhpbmcg SSB0aGluayBwZW9wbGUgdGVuZCB0byB1c2UgYXMgYSBkaWN0aW9uYXJ5IHJhdGhlciB0aGFuIGFz IHByb3RvY29sIGNvbXBvbmVudCBkZXNjcmlwdGlvbi4gIE1heWJlIHRoZSBjaGFpcnMgY2FuIGFk dmlzZT8NCg0KSWYgd2UgZGlzdGluZ3Vpc2ggYmV0d2VlbiBmaXJzdCB0aW1lIHJlZ2lzdHJhdGlv biBvZiBhIHBhcnRpY3VsYXIgY2xpZW50IHNvZnR3YXJlIHBhY2thZ2UsIGl0IGlzIHBvc3NpYmxl IHRoYXQgc29tZXRoaW5ncyBsaWtlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgbmVnb3Rp YXRlIGluIG9yIG91dC1vZi1iYW5kIGF0IHRoYXQgdGltZS4gU3Vic2VxdWVudCByZWdpc3RyYXRp b25zIHNob3VsZCBvbmx5IGhhdmUgcGFyYW1ldGVycyBmb3IgaXRlbXMgdGhhdCBjb3VsZCBjaGFu Z2UgcGVyIGRlcGxveW1lbnQgKGxpa2UgdG9zX3VyaSkuICBJIHRoaW5rIHRva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kIGlzIG9uZSB0aGluZyB0aGF0IHNob3VsZCBub3QgYmUgbmVnb3RpYXRlZCBw ZXIgaW5zdGFuY2UuDQoNCldoZW4gc3Vic2VxdWVudCBpbnN0YW5jZXMgcmVnaXN0ZXIsIEkgaGF2 ZSB0byBhc2sgdGhlIHF1ZXN0aW9uLCBmb3IgZXhhbXBsZSB3aGVuIHdvdWxkIHRoaW5ncyBsaWtl ICJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCIgYmUgbmVnb3RpYXRlZCBvciBiZSBkaWZmZXJl bnQgZm9yIHRoZSBzYW1lIGNsaWVudCBzb2Z0d2FyZT8gU2hvdWxkIG5vdCBhbGwgaW5zdGFuY2Vz IHVzZSB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkknbSBjb25mdXNlZCBieSB0 aGlzIC0tIGFzIGZhciBhcyB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBpcyBjb25jZXJu ZWQsIGFsbCBpbnN0YW5jZXMgYXJlIHNlcGFyYXRlIGZyb20gZWFjaCBvdGhlci4gQWxsIHBhcmFt ZXRlcnMgY2hhbmdlIHBlciBpbnN0YW5jZS4gQW5kIGluc3RhbmNlLCB5b3Ugc2hvdWxkIGtlZXAg aW4gbWluZCwgaXMgZGVmaW5lZCBhcyBhbnkgb25lIGNvcHkgb2YgdGhlIGNsaWVudCBjb2RlIGNv bm5lY3RpbmcgdG8gYW55IG5ldyBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhhdCBwYWlyaW5nIGNy ZWF0ZXMgdGhlIGNsaWVudF9pZCwgYW5kIHRoZXJlZm9yZSB0aGUgaW5zdGFuY2UsIGFuZCB0aGVy ZWZvcmUgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4sIGFuZCB0aGVyZWZvcmUgdGhlIHJl Z2lzdHJhdGlvbiBpdHNlbGYgYXQgYSBjb25jZXB0dWFsIGxldmVsLiBTbyB0aGVyZSBpcyBubyB3 YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9yIGEgY2xpZW50IHRvIGFzayBmb3IgYSBwYXJ0 aWN1bGFyIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kLiBXaGVyZSBlbHNlIHdvdWxkIHRoZSBB UyBmaW5kIG91dCBhYm91dCBpdD8NCg0KV2Ugc3RpbGwgZGlzYWdyZWUgb24gdGhpcy4gSXQgaXMg bXkgYXNzZXJ0aW9uIHRoYXQgY2xpZW50cyBzaG91bGQgTkVWRVIgYXNrIGZvciBhIHBhcnRpY3Vs YXIgdG9rZW4gYXV0aCBtZXRob2QuIFNpbmNlIGl0IGlzIHRoZSBBUyB0aGF0IGlzIGF1dGhlbnRp Y2F0aW5nIHRoZSBjbGllbnQsIHRoZW4gaXQgaXMgdGhlIEFTJ3MgcmlnaHQgdG8gc2V0IHRoZSBh dXRoZW50aWNhdGlvbiBwb2xpY3kuICBUaGUgcm9sZSBvZiBkeW5hbWljIHJlZyBlbmRwb2ludCBp cyB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgZG8uICBNeSBhc3N1bXB0aW9uIGlz IHRoYXQgZHVyaW5nIHRoZSBmaXJzdCB0aW1lIGEgcGllY2Ugb2Ygc29mdHdhcmUgaXMgcmVnaXN0 ZXJlZCAodGhlIGZpcnN0IGluc3RhbmNlKSwgdGhlcmUgY291bGQgYmUgc29tZSBPT0IgZGlzY3Vz c2lvbiBieSBhbiBhZG1pbmlzdHJhdG9yIHRvIGFwcHJvdmUgdGhlIHBhcnRpY3VsYXIgYXV0aGVu dGljYXRpb24gdHlwZSBmb3IgdGhlIEFTIGluIHF1ZXN0aW9uLg0KDQpJIGhhdmVuJ3QgaGVhcmQg YSByZWFzb24ganVzdGlmeWluZyB0aGlzIHBhcmFtZXRlciBvdGhlciB0aGVuICJpdCBpcyBuZWVk ZWQiLiAgV2h5Pw0KDQpUaGUgcm9sZSBvZiB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gcHJvdG9j b2wgaXMgdHdvZm9sZDogaGFsZiBvZiB0aGF0IGlzIHRoZSBzZXJ2ZXIgaW5mb3JtaW5nIHRoZSBj bGllbnQgd2hhdCBpdCBtdXN0IGRvLiBCdXQgdGhlIG90aGVyIGhhbGYgaXMgdGhlIGNsaWVudCBp bmZvcm1pbmcgdGhlIHNlcnZlciB3aGF0IGl0ICpjYW4qIGRvLCBvciB3aGF0IGl0ICp3YW50cyog dG8gZG8uDQoNCkFuZCBhZ2FpbiwgdGhlcmUncyBubyB3YXkgdG8gZGlzdGluZ3Vpc2ggYSBmaXJz dCBpbnN0YW5jZSBmcm9tIGEgc3Vic2VxdWVudCBpbnN0YW5jZSB1bmxlc3MgeW91J3JlIGRvaW5n IHNvbWV0aGluZyBpbiBhZGRpdGlvbi4gTm90aGluZyBpcyBzdG9wcGluZyB0aGUgc2FtZSBhcHBs aWNhdGlvbiBmcm9tIHJlZ2lzdGVyaW5nIGEgbmV3IGluc3RhbmNlIG9mIGl0c2VsZiBmb3IgZXZl cnkgc2luZ2xlIHVzZXIgb3IgZXZlcnkgc2luZ2xlIHRva2VuIHRoYXQgaXQgd2FudHMgdG8gZ2V0 IGFjY2VzcyBmb3IuIFRoYXQncyBjb21wbGljYXRlZCBhbmQgd2FzdGVmdWwgYW5kIG5vdCBhIGdy ZWF0IGlkZWEsIHN1cmUsIGJ1dCAgdGhlcmUncyBubyB1c2VmdWwgd2F5IHRvIHByZXZlbnQgdGhh dCBraW5kIG9mIGJlaGF2aW9yIGlmIHlvdSBhbHNvIHdhbnQgb3BlbiByZWdpc3RyYXRpb24gb2Yg Y2xpZW50cy4NCg0KSSB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgaG93IHJlY29nbml6aW5nIHN1YnNl cXVlbnQgaW5zdGFuY2VzIGlzIGVhc2lseSBkb25lLg0KDQpBcyBJIG1lbnRpb25lZCBpbiB0aGUg b3RoZXIgdGhyZWFkLCBpZiBhIGRldmVsb3BlciBjaG9vc2VzIHRvIGxpbWl0IHRoZSBjYXBhYmls aXRpZXMgb2YgdGhlIGNsaWVudCBpdCBtdXN0IGRvIHNvIGJ5IGxvb2tpbmcgdG8gdGhlIGRldmVs b3BlciBvciBzdGFuZGFyZCBiZWhpbmQgdGhlIEFQSS4gIE90aGVyd2lzZSB0aGV5IGFyZSB0YWtp bmcgdGhlIGNoYW5jZS4gIFRoZXJlJ3Mgbm8gd2F5IGEgZGV2ZWxvcGVyIGNhbiBxdWVyeSBhbGwg dGhlIHBvdGVudGlhbCBkZXBsb3llcnMgdG8gYXNrIHdoYXQgYXV0aG4gdHlwZXMgd2lsbCB5b3Ug dXNlLiBBcyBJIHNhaWQsIHRoZSBuZXQgZWZmZWN0IGluIHRoZSBhYnNlbmNlIG9mIGFuIEFQSSBz dGFuZGFyZCBkaWN0YXRpbmcgd2hhdCBzaG91bGQgYmUgc3VwcG9ydGVkLCB0aGUgZGV2ZWxvcGVy IHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgYWxsIG1ldGhvZHMuDQoNCk15IHBvaW50IGhlcmUgaXMg dGhhdCBub25lIG9mIHRoaXMgaXMgaGVscGVkIGJ5IHRoZSBjbGllbnQgYXBwIHNheWluZyB3aGF0 IGl0IHN1cHBvcnRzLiBBIGRldmVsb3BlciB3aG8gdGFrZXMgdGhlIHJvdXRlIG9mIGxpbWl0aW5n IGltcGxlbWVudGF0aW9uIHRha2VzIHRoZSBjaGFuY2UgdGhhdCB0aGUgc2VydmVyIHdpbGwgbm90 IGFjY2VwdC4gIFNvIHdoeSBuZWdvdGlhdGUgd2l0aGluIHJlZ2lzdHJhdGlvbj8NCg0KQW5kIHRo ZXJlJ3Mgbm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNlIGZvciB0aGUgc2VydmVyIHRvIHRl bGwgdGhlIGNsaWVudCB3aGljaCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCB0byB1c2UuIEFs bCBpbnN0YW5jZXMgd2lsbCBwcm9iYWJseSBhc2sgZm9yIHRoZSBzYW1lIHRva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kIGZyb20gYWxsIGF1dGggc2VydmVycyB0aGV5IHRhbGsgdG8sIHJpZ2h0PyBB bmQgZWFjaCBBUyB3aWxsIHRlbGwgZWFjaCBpbnN0YW5jZSB0aGF0IHJlZ2lzdGVycyB3aXRoIGl0 IHRvIHVzZSBhIHBhcnRpY3VsYXIgYXV0aCBtZXRob2QuIFRoZXJlIGlzIG5vIHdheSB0byB0aWUg dG9nZXRoZXIgZGlmZmVyZW50IGluc3RhbmNlcyBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0aCBzZXJ2 ZXJzIHdpdGhvdXQgc3BlY2lmeWluZyBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBvdGhlciBtYWNo aW5lcnkuDQoNCldoaWNoIGlzIG5vdCB0byBzYXkgdGhhdCBpdCdzIG5vdCB1c2VmdWwgaW4gc29t ZSBjaXJjdW1zdGFuY2VzIHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIG9mIHRo ZSBzYW1lIGNvZGUgYWNyb3NzIChvciB3aXRoaW4pIGF1dGggc2VydmVycy4gVGhpcyBpcyB3aHks IHdpdGggQmx1ZSBCdXR0b24rLCB3ZSBzcGVjaWZpZWQgYSBzcGVjaWZpYyB0b2tlbiBmb3JtYXQg Zm9yIHRoZSBpbml0aWFsIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBjbGllbnRzIHVzZSB0byBjYWxs IHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgdGhlIGZpcnN0IHRpbWUsICBhcyB3ZWxsIGFzIGEg ZGlzY292ZXJ5IHByb3RvY29sIGFnYWluc3QgYSBjZW50cmFsaXplZCBzZXJ2ZXIgdGhhdCBoYW5k bGVzIHByZS1yZWdpc3RyYXRpb24uIEFsbCBvZiB0aGlzIG1hY2hpbmVyeSBpcywgaW4gbXkgb3Bp bmlvbiwgYSBzdHVwZW5kb3VzIG92ZXJraWxsIGZvciB0aGUgZ2VuZXJhbCBjYXNlLCB0aG91Z2gg aWYgc29tZSBmb2xrcyBmaW5kIHVzZSBmb3IgaXQgb3V0c2lkZSBvZiBCQisgdGhlbiBpdCdkIGJl IGEgZ29vZCB0aGluZyB0byBhYnN0cmFjdCBvdXQgYW5kIG1ha2UgaXRzIG93biBzcGVjIHRoYXQg ZXh0ZW5kcyB0aGUgRHluIFJlZyBzcGVjIGluIGEgZnVsbHkgY29tcGF0aWJsZSB3YXkuIEZ1cnRo ZXJtb3JlLCBldmVuIGluIEJsdWUgQnV0dG9uKyB3ZSBzcGVjaWZ5IHRoYXQgYWxsIGF1dGggc2Vy dmVycyBNVVNUIGFsc28gYWNjZXB0IG9wZW4gcmVnaXN0cmF0aW9uLCB3aXRob3V0IGFuIGluaXRp YWwgYWNjZXNzIHRva2VuLCB3aGVyZSB0aGUgY2xpZW50IHNpbXBseSBzaG93cyB1cCBhbmQgc2F5 cyAiaGV5LCBoZXJlIGFyZSBteSBwYXJhbWV0ZXJzLiIgVGhlIGF1dGggc2VydmVyIGhhcyBubyB3 YXkgdG8ga25vdyBpbiB0aGlzIGNhc2UgYW55IGtpbmQgb2Ygb3V0LW9mLWJhbmQgbmVnb3RpYXRp b24gZm9yIGRpZmZlcmVudCB0aGluZ3MuIEluIEJCKyB3ZSBhcmUgd3JpdGluZyB2ZXJ5IHNwZWNp ZmljIHBvbGljeSBndWlkZWxpbmVzIGFib3V0IGhvdyB0byBwcmVzZW50IHRoZSBVWCBhbmQgdGhp bmdzIHRvIHRoZSBlbmQgdXNlciBmb3IgYWxsIG9mIHRoZXNlIGRpZmZlcmVudCBjYXNlcy4gQnV0 IGFnYWluLCBhbGwgb2YgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUgQkIrIHVzZSBjYXNlLCBhbmQg SSBkb24ndCBzZWUgdmFsdWUgaW4gZHJhZ2dpbmcgaXQgaW4gdG8gdGhlIHJlZ2lzdHJhdGlvbiBz cGVjIG9uIGl0cyBvd24uIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBmYXIgdG9vIGxpbWl0aW5nLg0K DQpTZWUgbXkgcHJldmlvdXMgY29tbWVudHMgb24gZGlmZmVyZW50aWF0aW5nIGNsaWVudCBpbnN0 YW5jZXMgYmVpbmcgb3V0IG9mIHNjb3BlIHdpdGhvdXQgcmVjaGFydGVyaW5nIHRvIGRvIHRoaXMg bmV3IHdvcmsgYW5kIG9uIHdoYXQgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMuICBJ biBzaG9ydCwgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMgYW4gUkZDIDY3NTAgYmVh cmVyIHRva2VuIGlzc3VlZCB0byB0aGUgcGFydHkgcmVnaXN0ZXJpbmcgdGhlIGNsaWVudCwgZW5h YmxpbmcgaXQgdG8gc3Vic2VxdWVudGx5IHJldHJpZXZlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj bGllbnQgcmVnaXN0cmF0aW9uIGFuZCB0byBwb3RlbnRpYWxseSB1cGRhdGUgdGhlIHJlZ2lzdHJh dGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhhdCByZWdpc3RlcmVkIGNsaWVudC4gIEFnYWluLCBJ4oCZ bGwgd29yayB3aXRoIEp1c3RpbiB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIGlzIGFzIGNsZWFyIGFz IHBvc3NpYmxlIGluIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQpGaW5hbGx5LCB0aGVyZSBzZWVtcyB0 byBiZSBhbiBpbmNvbnNpc3RlbnQgc3R5bGUgYXBwcm9hY2ggd2l0aCBkcmFmdC1oYXJkam9uby1v YXV0aC1yZXNvdXJjZS1yZWc8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhhcmRqb25v LW9hdXRoLXJlc291cmNlLXJlZy0wMC50eHQ+IHdoaWNoIHVzZXMgRVRhZ3MuIFNob3VsZCB0aGlz IGRyYWZ0IGRvIHNvIGFzIHdlbGw/DQoNClRoYXQncyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24s IG5vdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIE5vYm9keSBoYXMsIHVudGlsIG5vdywgZXZlbiBt ZW50aW9uZWQgdGhlIHVzZSBvZiBFVGFncyBoZXJlLiBVTUEgKHdoZXJlIHRoZSByZXNvdXJjZSBy ZWdpc3RyYXRpb24gZHJhZnQgY29tZXMgZnJvbSkgdXNlcyBFVGFncywgaGVuY2UgdGhlaXIgaW5j bHVzaW9uIHRoZXJlLiBJIHBlcnNvbmFsbHkgZG9uJ3Qgc2VlIHRoZWlyIHV0aWxpdHkgaGVyZSwg dGhvdWdoLCBhbmQgSSB3b3VsZG4ndCB3YW50IHRvIGluY2x1ZGUgYSB3aG9sbHkgbmV3IG1lY2hh bmlzbSB0aGlzIGxhdGUuDQoNClllcy4gVGhvbWFzJyBkcmFmdCBpcyBub3QgYSBXRyBkb2N1bWVu dC4gQnV0IHRoYXQgZG9lc24ndCBtZWFuIGhlIGRvZXNuJ3QgaGF2ZSBhIHBvaW50LiBJdCdzIHdv cnRoIGRpc2N1c3NpbmcuDQoNCk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHRoZSBwb2ludCBvZiBhbiBF VGFnIGlzIHRoYXQgaXQgaXMgdXNlZnVsIGZvciBjaGFuZ2UgZGV0ZWN0aW9uIHdoZW4gdGhlcmUg YXJlIG11bHRpcGxlIHdyaXRlcnMgdG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlLiAgSW4gdGhlIGRl c2lnbiBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCwgdGhlcmUgc2hvdWxkIG9ubHkg YmUgb25lIHdyaXRlciAtLSB0aGUgY2xpZW50LiBUaGlzIGlzIGFuIGltcG9ydGFudCBvYnNlcnZh dGlvbi4NCg0KVGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdGhhdCBoYW5kbGUgdGhpcyAtLSBu YW1lbHksIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGFuZCB0aGUgY2xpZW50X2lkLiBN YW55IGluc3RhbmNlcyBpbmNsdWRlIHRoZSBjbGllbnRfaWQgaW4gc29tZSBmb3JtIGluIHRoZSBj bGllbnQgY29uZmlndXJhdGlvbiBlbmRwb2ludCdzIFVSTCBmb3Igc2FuaXR5IGNoZWNraW5nLCBh cyBkZXNjcmliZWQgaW4gwqc0LjEuDQoNCklmIGV2ZXJ5b25lIGFncmVlcywgSSdtIGluIGFncmVl bWVudC4gQnV0IGl0IHdpbGwgbGlrZWx5IG1lYW4gY2hhbmdlcyBmb3IgdGhlIHJlc291cmNlIHJl ZyBkcmFmdCBpZiBhZG9wdGVkLg0KDQpFVGFncyBzZWVtIGxpa2UgYW4gdW5uZWNlc3NhcnkgYWRk aXRpb24gKGFuZCBwb3RlbnRpYWwgY29tcGxpY2F0aW9uKSB0byB0aGUgc3BlY2lmaWNhdGlvbi4g IEl04oCZcyBhbHJlYWR5IHdvcmtpbmcgZmluZSBhcy1pcy4NCg0KU3BlY2lmaWMgaXRlbXM6DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCINCg0KVGhl cmUgaXMgc29tZSBjb25mdXNpb24gYXMgdG8gd2hldGhlciB0aGlzIGFwcGxpZXMgdG8gc2VydmVy IG9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFN1Z2dlc3QgcmVuYW1pbmcgcGFyYW1ldGVyIHRv ICJ0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QiDQoNClRoaXMgaXMgdGhlIGZpcnN0 IEkndmUgaGVhcmQgb2YgdGhpcyBwYXJ0aWN1bGFyIGNvbmZ1c2lvbi4gSSdtIGZpbmUgd2l0aCBl aXRoZXIgbmFtZSBidXQgYXQgdGhpcyBzdGFnZSBJIGRvbid0IHdhbnQgdG8gbWFrZSBzeW50YXgg Y2hhbmdlcyB3aXRob3V0IHZlcnksIHZlcnkgY29tcGVsbGluZyByZWFzb25zIHRvIGRvIHNvLg0K DQpUaGUgcXVlc3Rpb24gd2FzIHJhaXNlZCB0byBtZSBieSBzb21lIG5ldyBkZXZlbG9wZXJzLiBJ dCBzZWVtcyBvYnZpb3VzIHRvIHVzIGFzIGV4cGVyaWVuY2VkIE9BdXRoIHBlcnNvbnMsIGJ1dCB0 byBuZXcgZGV2ZWxvcGVycyBpdCBzZWVtcyB1bmNsZWFyLiAgQWxzbywgbm93IHRoYXQgeW91IGFy ZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRpb24gYXV0aGVudGljYXRpb24sIHRoZSB3aG9sZSB0aGlu ZyBnZXRzIHZlcnkgY29uZnVzaW5nLiBTbyBpdCBpcyB1c2VmdWwgZGlzYW1iaWd1YXRlIGFsbCB0 aGUgcGFyYW1ldGVycyB3aGVyZSBwb3NzaWJsZS4gIFRoYXQgc2FpZCwgSSB3b3VsZG4ndCBtaW5k IHNob3J0ZXIgbmFtZXMgKG1heWJlIG5vdCBxdWl0ZSBhcyBzaG9ydCBhcyB0aGUgSk9TRSBzdHVm ZiA7LSkNCg0KRmFpciBlbm91Z2gsIGJ1dCBhZ2FpbiwgSSBvbmx5IHdhbnQgdG8gZG8gc3ludGF4 IGNoYW5nZXMgaWYgdGhlIHJlc3Qgb2YgdGhlIFdHICpyZWFsbHkqIHdhbnRzIHRvLg0KDQpJIGFn cmVlIHdpdGggSnVzdGluIGhlcmUuICBJ4oCZbSBmaW5lIGNsYXJpZnlpbmcgdGhlIGRlc2NyaXB0 aW9uIG9mIHRoaXMgcGFyYW1ldGVyIHRvIHJlc29sdmUgdGhlIHBvdGVudGlhbCBhbWJpZ3VpdGll cyB0aGF0IHlvdSBjaXRlLCBQaGlsLiAgSeKAmW0gbm90IE9LIHJldmlzaW5nIHRoZSBzeW50YXgg d2l0aG91dCBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLg0KDQoqIEN1cnJlbnRseSwgdGhl IEFQSSBvbmx5IHN1cHBvcnRzIGEgc2luZ2xlIHZhbHVlIGluc3RlYWQgb2YgYW4gYXJyYXkuICBJ ZiB0aGUgcHVycG9zZSBpcyB0byBhbGxvdyB0aGUgY2xpZW50IHRvIGtub3cgd2hhdCBhdXRoIG1l dGhvZHMgaXQgc3VwcG9ydHMsIHRoaXMgc2hvdWxkIGJlIGFuIGFycmF5IGluZGljYXRlZCB3aGF0 IG1ldGhvZHMgdGhlIGNsaWVudCBzdXBwb3J0cyAtIG9yIGl0IHNob3VsZCBub3QgYmUgdXNlZC4N Cg0KSSB3b3VsZCByYXRoZXIgbGlrZSB0aGlzIHRvIGJlIGFuIGFycmF5LCBwZXJzb25hbGx5LCBh bmQgYnJvdWdodCBpdCB1cCB3aXRoIHRoZSBPcGVuSUQgQ29ubmVjdCB3b3JraW5nIGdyb3VwIGFi b3V0IHNpeCBtb250aHMgYWdvLiBCdXQgdGhlcmUgaXQgd2FzIGRlY2lkZWQgdGhhdCBhIHNpbmds ZSB2YWx1ZSB3YXMgc2ltcGxlciBhbmQgc3VmZmljaWVudCBmb3IgdGhlIHB1cnBvc2UuIFRoZSBJ RVRGIGRyYWZ0IGhhcyBpbmhlcml0ZWQgdGhpcyBkZWNpc2lvbi4gSSAqYmVsaWV2ZSogKHRob3Vn aCBhbSBub3QgMTAwJSBwb3NpdGl2ZSkgdGhhdCBJIGJyb3VnaHQgdXAgdGhpcyB2ZXJ5IGlzc3Vl IGluIHRoZSBXRyBoZXJlIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhbnkgdHJhY3Rpb24gb24gaXQsIHNv IHNpbmdsZSBpdCByZW1haW5zLg0KDQpJIGNhbiBnZXQgYmVoaW5kIG11bHRpcGxlIHZhbHVlcy4g SW4gdGhpcyBjYXNlLCBpdCBjaGFuZ2VzIHRoZSBtZWFuaW5nIG9mIHRoZSBwYXJhbWV0ZXIuIElu c3RlYWQgb2YgdGhlIGNsaWVudCBmb3JjaW5nIHRoZSBzZXJ2ZXIgdG8gdXNlIGEgcGFydGljdWxh ciBtZXRob2QsIHRoZSBjbGllbnQgaXMgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIgYWJvdXQgd2hhdCBt ZXRob2RzIGl0IGNhbiBwZXJmb3JtLiBUaGlzIGFsbG93cyB0aGUgc2VydmVyIHRvIGFzc2lnbiB0 aGUgYXBwcm9wcmlhdGUgbWV0aG9kIGJhc2VkIG9uIGl0cyBvd24gcG9saWN5Lg0KDQpBbHNvIG5v dGUgdGhhdCB0aGlzIGZpZWxkLCBsaWtlIGFsbCBvdGhlcnMgaW4gwqcyLCByZXByZXNlbnRzIHR3 byB0aGluZ3M6IHRoZSBjbGllbnQgdGVsbGluZyB0aGUgc2VydmVyICJJIHdhbnQgdG8gdXNlIHRo aXMgdmFsdWUgZm9yIHRoaXMgZmllbGQiLCBhbmQgdGhlIHNlcnZlciB0ZWxsaW5nIHRoZSBjbGll bnQgInRoaXMgaXMgdGhlIHZhbHVlIHlvdSBoYXZlIGZvciB0aGlzIGZpZWxkIi4gSXQncyBub3Qg ZXhhY3RseSBhIG5lZ290aWF0aW9uLCBtb3JlIGxpa2UgbWFraW5nIGEgcG9saXRlIHJlcXVlc3Qg dG8gYW4gYWJzb2x1dGUgZGljdGF0b3Igd2hvIGhhcyB0aGUgbGFzdCB3b3JkIGFueXdheS4gQnV0 IGF0IGxlYXN0IHRoaXMgZGljdGF0b3IgaXMgbmljZSBlbm91Z2ggdG8gdGVsbCB5b3Ugd2hhdCB0 aGVpciBkZWNpc2lvbiB3YXMgaW5zdGVhZCBvZiBqdXN0IGRlY2FwaXRhdGluZyB5b3UuDQoNClRo aXMgaXMgdGhlIGhlYXJ0IG9mIG15IG9iamVjdGlvbi4gVGhpcyBmdXp6aW5lc3MgaXMgaXMgZ29p bmcgdG8gbGVhZCB0byBpbnRlcm9wIGlzc3Vlcy4NCg0KVGhlcmUgaXMgbm8gZnV6emluZXNzIHRo YXQgSSBjYW4gc2VlIGhlcmUuIEl0J3MgcGFyYWxsZWxpc20gYmV0d2VlbiB3aGF0IGdvZXMgaW4g dG8gdGhlIGVuZHBvaW50IGFuZCB3aGF0IGNvbWVzIG91dCBvZiBpdC4gVGhlIHNlbWFudGljcyBm b3IgdGhlIHJlcXVlc3QgYW5kIHRoZSByZXNwb25zZSBhcmUgZGlmZmVyZW50LCBhbmQgZGlmZmVy ZW50aWFibGUgYnkgdGhlIGZhY3QgdGhhdCBvbmUgaXMgYSByZXF1ZXN0IGFuZCB0aGUgb3RoZXIg aXMgYSByZXNwb25zZS4NCg0KVGhlIGludGVyLW9wIGlzc3VlIEkgd291bGQgbGlrZSB0byBwb2lu dCBvdXQgaXMgdGhhdCB0aGUgc3BlYyBkb2VzIG5vdCBjdXJyZW50bHkgc3BlY2lmeSBpZiBwYXJ0 aWN1bGFyIGlucHV0IHZhbHVlcyBhcmUgc2luZ3VsYXIgb3IgbXVsdGlwbGUuICBJZiBhbiBpbXBs ZW1lbnRlciBhc3N1bWVzIHNpbmd1bGFyIGFuZCBjbGllbnRzIGFzc3VtZSBtdWx0aXBsZSwgd2Ug aGF2ZSBpc3N1ZXMuDQoNClRoZSBtdWx0aXBsZS9zaW5nbGUgZGlzY3Vzc2lvbiBhYm92ZSBnZXRz IHRvIHRoZSBoZWFydCBvZiB3aGF0IEkgKmRvKiBiZWxpZXZlIGlzIGEgZGVmaWNpZW5jeSBpbiB0 aGUgc3BlY2lmaWNhdGlvbiwgYXMgaXTigJlzIGN1cnJlbnRseSB3cml0dGVuLiAgVGhlIGF1dGhv cnMsIG15c2VsZiBpbmNsdWRlZCwgaGF2ZSBmYWlsZWQgdG8gbWFrZSBpdCAxMDAlIGNsZWFyIHRo YXQgZGlzY292ZXJ5IG9mIEF1dGhvcml6YXRpb24gU2VydmVyIGZ1bmN0aW9uYWxpdHkgaXMgb3V0 IG9mIHNjb3BlIGZvciB0aGlzIHNwZWNpZmljYXRpb24uICBJIHN0cm9uZ2x5IGJlbGlldmUgdGhh dCB3ZSBuZWVkIHRvIGFkZCBhIGNsZWFyIHN0YXRlbWVudCB0byB0aGlzIGVmZmVjdCBpbiB0aGUg aW50cm9kdWN0aW9uIHRvIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQpUaGUgcHVycG9zZSBvZiB0aGUg RHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gaXMgZm9yIHRoZSBjbGll bnQgdG8gcmVnaXN0ZXIgd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRvIGluZm9y bSBpdCBvZiBwcm9wZXJ0aWVzIG9mIHRoZSBjbGllbnQgdGhhdCB0aGUgQVMgbWF5IHdhbnQvbmVl ZCB0byBiZSBhd2FyZSBvZi4gIEl0ICppcyBub3QqIHRoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiBmb3IgaXQgdG8gYmUgdXNlZCBieSBjbGllbnRzIGluIGFueSBtYW5uZXIgdG8gZGlz Y292ZXIgZmVhdHVyZXMgb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgVGhhdCBzaG91bGQg YmUgZXhwbGljaXRseSBvdXQgb2Ygc2NvcGUuDQoNCkN1cnJlbnRseSwgY2xpZW50cyBhcmUgaW5z dHJ1Y3RlZCBieSBSRkMgNjc0OSB0byBkaXNjb3ZlciBpbmZvcm1hdGlvbiBhYm91dCBBdXRob3Jp emF0aW9uIFNlcnZlcnMgdGhleSBpbnRlcmFjdCB3aXRoIGJ5IGNvbnN1bHRpbmcgdGhlIOKAnHNl cnZpY2UgZG9jdW1lbnRhdGlvbuKAnSAoUkZDIDY3NDksIFNlY3Rpb25zIDMuMSBhbmQgMy4yKS4g IFRoZXkgY2FuIGFsc28gbGVhcm4gaW5mb3JtYXRpb24gYWJvdXQgQXV0aG9yaXphdGlvbiBTZXJ2 ZXJzIGluIHNwZWNpZmljIGNvbnRleHRzIHRocm91Z2ggZGlzY292ZXJ5IHByb3RvY29scyBzdWNo IGFzIE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSAoaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl bmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sKSBhbmQgVU1BIERpc2NvdmVyeSAoVEJEKS4N Cg0KSSBzdXNwZWN0IHRoYXQgYXQgc29tZSBwb2ludCwgc29tZW9uZSBpbiB0aGUgT0F1dGggd29y a2luZyBncm91cCB3aWxsIHByb3Bvc2UgZGV2ZWxvcGluZyBhIGdlbmVyaWMgT0F1dGggZGlzY292 ZXJ5IG1lY2hhbmlzbSwgd2hpY2ggd2lsbCBsZWFkIHRvIGEgcmVjaGFydGVyaW5nIHRvIGluY2x1 ZGUgdGhpcyB3b3JrIGluIHRoZSB3b3JraW5nIGdyb3Vw4oCZcyBzZXQgb2YgZGVsaXZlcmFibGVz LiAgSSB3b3VsZCBzdXBwb3J0IGRvaW5nIHRoaXMgd29yayBhbmQgdGhlIG5lY2Vzc2FyeSByZWNo YXJ0ZXJpbmcgdG8gZG8gc28uDQoNClRoYXQgYmVpbmcgc2FpZCwgSSBzdHJvbmdseSBvcHBvc2Ug dHJ5aW5nIHRvIHNob2Vob3JuIHBpZWNlbWVhbCBhc3BlY3RzIG9mIGRpc2NvdmVyeSBpbnRvIHRo ZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbi4gIEl0IGlzIGRpc3Rp bmN0IGZ1bmN0aW9uYWxpdHkgYW5kIGRlc2VydmVzIGZpcnN0LWNsYXNzIGFuZCBzZXBhcmFibGUg dHJlYXRtZW50IGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgRGlzY292ZXJ5IGlzIGZvciBwb3RlbnRp YWwgY2xpZW50cyB0byBsZWFybiBwcm9wZXJ0aWVzIG9mIHRoZSBBUyBiZWZvcmUgcmVnaXN0cmF0 aW9uLiAgUmVnaXN0cmF0aW9uIGlzIGZvciBwb3RlbnRpYWwgY2xpZW50cyB0byBpbmZvcm0gdGhl IEFTIG9mIGl0cyBwcm9wZXJ0aWVzLCBjcmVhdGluZyBhIHJlZ2lzdGVyZWQgY2xpZW50LiAgRGlz Y292ZXJ5IHNlbmRzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBBUyB0byB0aGUgQ2xpZW50LiAgUmVn aXN0cmF0aW9uIHNlbmRzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBDbGllbnQgdG8gdGhlIEFTLiAg VGhhdOKAmXMgYSBjbGVhbiBzZXBhcmF0aW9uLiAgV2Ugc2hvdWxkIHN0cm9uZ2x5IHJlc2lzdCBt dWRkeWluZyB0aGUgdHdvIGZ1bmN0aW9ucy4NCg0KT0F1dGggMi4wIGlzIGEgc3VjY2VzcyBiZWNh dXNlIGl0IGRpZG7igJl0IHRyeSB0byBib2lsIHRoZSBvY2Vhbi4gIEl0IHNwZWNpZmllZCBob3cg dG8gZG8gb25lIHRoaW5nIHdlbGwgaW4gYSBzaW1wbGUsIHdlYi1mcmllbmRseSBtYW5uZXIuICBX ZSBzaG91bGQgZG8gdGhlIHNhbWUg4oCTIGZvY3VzaW5nIG9uIHNwZWNpZnlpbmcgaW50ZXJvcGVy YWJsZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24sIHdoaWxlIG1ha2luZyBpdCBjbGVhciB0 aGF0IHRoaXMgaXMgZGlzdGluY3QgZnJvbSBkaXNjb3ZlcnkgYWJvdXQgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgcHJvcGVydGllcywgYW5kIG1ha2luZyBpdCBjbGVhciB0aGF0IGRpc2NvdmVyeSBpcyBv dXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29yay4NCg0KSSBhcG9sb2dpemUgYXQgdGhpcyBwb2ludCBv biBiZWhhbGYgb2YgbXlzZWxmIGFuZCB0aGUgb3RoZXIgc3BlYyBlZGl0b3JzIGZvciBub3QgYmVp bmcgMTAwJSBjbGVhciB0aGF0IGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IGlzIGV4cGxpY2l0bHkg b3V0IG9mIHNjb3BlIGZvciBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24uICBJZiB3ZSBoYWQg ZG9uZSBzbywgSeKAmW0gc3VyZSB0aGF0IG1hbnkgb2YgdGhlIGN1cnJlbnQgcXVlc3Rpb25zIGFu ZCBjb25mdXNpb25zIHdvdWxkIG5vdCBoYXZlIGFyaXNlbi4gIEkgdGhpbmsgd2XigJlkIGFzc3Vt ZWQgdGhhdCB0aGlzIHdhcyBvYnZpb3VzLCBidXQgZnJvbSB0aGUgY3VycmVudCBkaXNjdXNzaW9u cywgaXTigJlzIGFwcGFyZW50IHRoYXQgaXTigJlzIG5vdCBvYnZpb3VzLiAgSSB3aWxsIHBlcnNv bmFsbHkgY29tbWl0IHRvIGNsYXJpZnlpbmcgdGhlIHNwZWNpZmljYXRpb24gYXQgdGhpcyBwb2lu dCB0byBlbGltaW5hdGUgdGhpcyBwb3RlbnRpYWwgcG9pbnQgb2YgY29uZnVzaW9uLg0KDQpHZXR0 aW5nIGJhY2sgdG8gdGhlIHNwZWNpZmljcywgdGhlIG9ubHkgdXNlZnVsIHB1cnBvc2Ugb2YgYSBt dWx0aS12YWx1ZWQg4oCcdG9rZW5fZW5kcG9pbnRfY2xpZW50X2F1dGhfbWV0aG9k4oCdIG1lbWJl ciB3b3VsZCBiZSB0byBlbmFibGUgdGhlIGNsaWVudCB0byBkaXNjb3ZlciBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhlIEFTIGFmdGVy IHRoZSByZWdpc3RyYXRpb24gaGFkIGJlZW4gcGVyZm9ybWVkLiAgQnV0IHRoYXQgaXMgYSBkaXNj b3ZlcnkgZnVuY3Rpb24sIGFuZCBzbyBzaG91bGQgYmUgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHdv cmsg4oCTIG5vdCB0aGlzIHNwZWNpZmljYXRpb24uICBXZSBzaG91bGQgcmVzaXN0IHNob2Vob3Ju aW5nIGluIGJpdHMgb2YgZGlzY292ZXJ5IGludG8gdGhpcyBzcGVjaWZpY2F0aW9uLiAgSXQgKmlz KiBhIHdvcnRod2hpbGUgdG9waWMsIGJ1dCBkZXNlcnZlcyBmdWxsIGNvbnNpZGVyYXRpb24gYnkg dGhlIHdvcmtpbmcgZ3JvdXAgaW4gaXRzIG93biByaWdodC4gIFRoZXJlZm9yZSwgdGhpcyBtZW1i ZXIgbXVzdCByZW1haW4gc2luZ2xlLXZhbHVlZCwgYW5kIGJlIGNsZWFybHkgc3BlY2lmaWVkIGFz IHRoZSBtZXRob2QgYnkgd2hpY2ggYSBjbGllbnQgaW5mb3JtcyB0aGUgQVMgd2hpY2ggdG9rZW4g ZW5kcG9pbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIGl0IHdpbGwgdXNlLiAgQW55dGhpbmcgZWxz ZSB3b3VsZCBiZSBzY29wZSBjcmVlcCwgYW5kIHJlc3VsdCBpbiBhbiB1bm5lY2Vzc2FyaWx5IGNv bXBsaWNhdGVkIHNwZWNpZmljYXRpb24gYW5kIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQgY2xp ZW50cy4NCg0KKiBUaGVyZSBpcyBubyBhdXRobiBtZXRob2QgZm9yICJjbGllbnRfc2VjcmV0X3Nh bWwiIG9yICJwcml2YXRlX2tleV9zYW1sIi4NCg0KTm9ib2R5IGhhcyByZWFsbHkgYXNrZWQgdGhh dCB0aGVzZSB0d28gYmUgaW5jbHVkZWQgb3Igc3BlY2lmaWVkLiBUaGUgZXh0ZW5zaW9uIG1lY2hh bmlzbSAodXNpbmcgYW4gYWJzb2x1dGUgVVJJKSB3b3VsZCBhbGxvdyBzb21lb25lIGVsc2UgdG8g ZGVmaW5lIHRoZXNlLiBJcyB0aGUgZGVmaW5pdGlvbiBpbiB0aGUgU0FNTCBBc3NlcnRpb24gZHJh ZnQgc3VmZmljaWVudCBmb3IgdGhlaXIgdXNlPw0KDQpJIHRoaW5rIHRoaXMgaXMgY29taW5nIGZy b20gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIEpXVCBiZWFyZXIgZHJhZnQgYW5kIGEgU0FNTCBi ZWFyZXIgZHJhZnQuICBUaGUgdHJ1dGggaXMgeW91IGFyZSBkZWZpbmluZyBhbiBhdXRoZW50aWNh dGlvbiB0aGF0IGlzbid0IGV2ZW4gZGVmaW5lZC4NCg0KVGhlcmUgYXJlIG5vIHByb2ZpbGVzIHJl ZmVyZW5jZWQgb3IgZGVmaW5lZCBmb3IgImNsaWVudF9zZWNyZXRfand0IiBvciAicHJpdmF0ZV9r ZXlfand0Ii4gTmVpdGhlciBvZiB0aGUgSldUIG9yIFNBTUwgQmVhcmVyIGRyYWZ0cyByZWZlcmVu Y2VkIGNvdmVyIHRoZXNlIHR5cGVzIG9mIGZsb3dzLiBUaGV5IG9ubHkgY292ZXIgYmVhcmVyIGZs b3dzLiAgImNsaWVudF9zZWNyZXRfand0IiBhbmQgInByaXZhdGVfa2V5X2p3dCIgc2VlbSB0byBo YXZlIHNvbWUgbWVhbmluZyB3aXRoaW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJIG5vdGUgdGhhdCBP SURDIGRvZXMgbm90IGZ1bGx5IGRlZmluZSB0aGVzZSBlaXRoZXIuDQoNClRoZSBKV1QgYXNzZXJ0 aW9uIGRyYWZ0IGRvZXMgc2F5IGhvdyB0byB1c2UgYSBKV1QgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbiwgYW5kIHRoZSBEeW5SZWcgdGV4dCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIGEgY2xpZW50 IHNpZ25pbmcgc2FpZCBKV1Qgd2l0aCBpdHMgb3duIHNlY3JldCBzeW1tZXRyaWNhbGx5IHZzLiBh IGNsaWVudCB1c2luZyBpdHMgb3duIHByaXZhdGUga2V5LCBhc3ltbWV0cmljYWxseS4NCg0KQWN0 dWFsbHkgbXkgaW50ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1bWVzIHRoZSBKV1Qg QmVhcmVyIGlzIGEgYmVhcmVyIHRva2VuLiAgVGhlIGFzc3VtcHRpb24gaXMgdGhhdCBpZiBhIGNs aWVudCBoYXMgdGhlIGFzc2VydGlvbiBpdCBoYXMgdGhlIHJpZ2h0IHRvIHByZXNlbnQgaXQuICBJ T1cuIFRoZSBKV1QgQmVhcmVyIERyYWZ0IGlzIG1vc3QgZGVmaW5pdGl2ZWx5IG5vdCBhIEpXVCBI b0sgRHJhZnQuICA6LSkNCg0KUmVnYXJkbGVzcywgeW91IGFyZSBpbnRyb2R1Y2luZyBhIG5ldyBw cm9maWxlIHdoaWNoIGlzIHVuZGVmaW5lZC4NCg0KSSB0aGluayBJIHNlZSB0aGUgcG9pbnQgdGhh dCB5b3UncmUgbWFraW5nIG5vdywgbGV0IG1lIHRyeSB0byByZS1zdGF0ZSBpdDoNCg0KV2hpbGUg dGhlIGJhc2ljcyBvZiAiaG93IHRvIHByZXNlbnQgYSBKV1QgYXMgYSBjbGllbnQgY3JlZGVudGlh bCIgaXMgZGVmaW5lZCBoZXJlOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1v YXV0aC1qd3QtYmVhcmVyLTA1Lmh0bWwjcmZjLnNlY3Rpb24uMi4yICwgaXQncyBub3QgY29tcGxl dGVseSBzcGVjaWZpZWQgaW4gdGhhdCBpdCBkb2Vzbid0IGZ1bGx5IHJlc3RyaWN0IHRoZSBzaWdu YXR1cmUgc2VjcmV0IHNvdXJjZSwgdGhlIGF1ZGllbmNlIGNsYWltLCBhbmQgb3RoZXIgdGhpbmdz IHRoYXQgdGhlIEFTIHdvdWxkIG5lZWQgdG8gY2hlY2sgYW5kIHZhbGlkYXRlLiBSaWdodD8gVGhl IGR5bmFtaWMgcmVnaXN0cmF0aW9uIGRyYWZ0IGNhbiBkZWZpbmUgdGhvc2UgY2FzZXMgaW4gZ3Jl YXRlciBkZXRhaWwgaWYgbmVlZGVkICh0aG91Z2ggSSB0aGluayBpdCBkb2VzIHNvIHN1ZmZpY2ll bnRseSBhcy1pcywgSSB3ZWxjb21lIG1vcmUgY2xhcml0eSkuDQoNCkknZCBiZSBPSyB3aXRoIGFk ZGluZyB0aGUgU0FNTCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwgb24gdGhlIEpXVCBi aXRzLCBvciBkcm9wcGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50cyB0byBkbyBhbnkg b2YgdGhvc2UgYWN0aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpXVCBzdHVmZiBpcyBh bHJlYWR5IGluIHVzZSBhbmQgZnVuY3Rpb25pbmcgYW5kIGl0J2QgYmUgYSBzaGFtZSB0byBsZWF2 ZSBpdCBvdXQuDQoNCkkgZ3Vlc3MgdGhlbiB0aGUgbWlzdGFrZSB0aGUgSldUIEJlYXJlciBhbmQg U0FNTCBCZWFyZXIgZHJhZnRzIGF1dGhvcnMgbWFkZSBpcyB0aGV5IGFzc3VtZWQgZXZlcnlvbmUg aGFkIHRoZSBzYW1lIGRlZmluaXRpb24gb2YgYmVhcmVyIHRva2VuLiAgVG8gbWUgYSBiZWFyZXIg dG9rZW4gb3BhcXVlIHRvIHRoZSBjbGllbnQuIEl0IHRoZXJlZm9yZSBjYW5ub3QgZG8gYW55IHNp Z25hdHVyZSB3b3JrIHdpdGggcmVnYXJkcyB0byB0aGUgdG9rZW4gaXRzZWxmLiAgTm93LCB0aGF0 J3Mgbm90IHRvIHNheSBhIHByb29mIGRpZG4ndCBvY2N1ciBiZXR3ZWVuIHRoZSBjbGllbnQgYW5k IHRoZSB0b2tlbiBpc3N1ZXIsIGJ1dCB3aGVuIHRoZSBjbGllbnQgd2llbGRzIHRoZSB0b2tlbiwg aXQgaXMgaGFuZGxpbmcgYW4gb3BhcXVlIHN0cmluZy4NCg0KVGhlIGNvbmNlcHQgb2YgY2xpZW50 X3NlY3JldF9qd3Qgc3VnZ2VzdHMgYW4gSG9LIHByb2ZpbGUuICBUaGVyZWZvcmUgb2YgY291cnNl IHRoZSBiZWFyZXIgZHJhZnRzIGFyZSBhIGxpdHRsZSB1bmRlcnNwZWNpZmllZCB3aGVuIGl0IGNv bWVzIHRvIEhvSyBwcm9maWxlcy4NCg0KU28gZm9yIGV4YW1wbGUsIHlvdSBuZWVkIGEgZHJhZnQg bGlrZSB0aGUgTUFDIGRyYWZ0IGZvciB0aGlzLg0KDQpJJ20gaGF2aW5nIHRyb3VibGUgb3ZlcmFs bCBoZXJlLiBJdCBzZWVtcyB0aGUgYXV0aG4gdHlwZXMgc3VnZ2VzdCBPTkxZIHN0cm9uZyBhdXRo ZW50aWNhdGlvbiBmb3IgY2xpZW50cywgeWV0IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nl c3MgdGhlIGN1cnJlbnQgZHJhZnQgaXNuJ3QgYWJsZSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgaW5z dGFuY2VzIG9mIHRoZSBzYW1lIHNvZnR3YXJlIChldmVuIGluIGEgc2VsZi1hc3NlcnRlZCB3YXkp LiAgSWYgeW91IGhhdmVuJ3QgYXV0aGVudGljYXRlZCB0aGUgc29mdHdhcmUgYXQgYWxsLCB3aHkg aGF2ZSBzdHJvbmcgY2xpZW50IGF1dGg/DQoNClRoZXJlIGlzIG5vIGF1dGhlbnRpY2F0aW9uIG1l dGhvZCBkZWZpbmVkIGZvciAiY2xpZW50X2JlYXJlcl9zYW1sIiBvciAiY2xpZW50X2JlYXJlcl9q d3QiIG9yICJjbGllbnRfYmVhcmVyX3JlZiIuICBTaW5jZSB0aGUgYmVhcmVyIHNwZWNzIHNheSB0 aGlzIGlzIGFjY2VwdGFibGUsICB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBzaG91bGQg YWNjZXB0IHRoZXNlLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBiaXQgLS0gd2hlcmUgYXJl IHRoZXNlIGRlZmluZWQgaW4gUkZDNjc1MD8gSSBkb24ndCBldmVuIGtub3cgd2hhdCBjbGllbnRf YmVhcmVyX3JlZiB3b3VsZCByZWZlciB0by4NCg0KNjc1MCBzYXlzIHlvdSBjYW4gdXNlIGEgYmVh cmVyIGFzc2VydGlvbiAoZS5nLiBvYnRhaW5lZCBmcm9tIGFuIElEUCkgYW5kIHdpZWxkIGl0IGFz IGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbi4gIFRoZSBjbGllbnQgaXMgTk9UIGNyZWF0aW5n IG9yIG1vZGlmeWluZyB0aGUgYXNzZXJ0aW9uLiBUaGUgY2xpZW50IGlzIHNpbXBseSBwYXNzaW5n IG9uZSBpdCBwcmV2aW91c2x5IG9idGFpbmVkLg0KDQpXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBp cyBub3QgYmVhcmVyLiBJdCBpcyBob2xkZXIgb2Yga2V5LiBWZXJ5IHZlcnkgZGlmZmVyZW50Lg0K DQpBIHBvc3NpYmxlIHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlIGNsaWVudF9zZWNyZXRfand0IGFu ZCBwcml2YXRlX2tleV9qd3QgYW5kIGRlZmluZSB0aG9zZSBhcyByZWdpc3RlciBleHRlbnNpb25z IHNpbmNlIHRoZXNlIHByb2ZpbGVzIGFyZSBub3QgZGVmaW5lZC4NCg0KVGhhdCdzIHBvc3NpYmxl LCBidXQgdGhleSBhcmUgaW4gYWN0aXZlIHVzZSBhbHJlYWR5Lg0KDQpUaGF0IG1heSBiZSB0cnVl LiBCdXQgdGhlbiB5b3UgbmVlZCB0byB3cml0ZSBhbm90aGVyIGRyYWZ0IHNvIHRoZSByZXN0IG9m IHVzIGNhbiBpbXBsZW1lbnQgaXQgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuICBNZSBJIHByZWZl ciBub3QgdG8gZ3Vlc3Mgd2hhdCB5b3UgYXJlIGRvaW5nLg0KDQpUaGlzIG11Y2ggSSBhZ3JlZSB3 aXRoLg0KDQpKdXN0aW4sIEpvaG4sIGFuZCBJIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGFuZCBhZ3Jl ZSB3aXRoIHlvdXIgc3VnZ2VzdGlvbiwgUGhpbC4gIFNpbmNlIHRoZXkgYXJlIG5vdCBjb21wbGV0 ZWx5IHNwZWNpZmllZCwgd2Ugd2lsbCByZW1vdmUgdGhlIGNsaWVudF9zZWNyZXRfand0IGFuZCBw cml2YXRlX2tleV9qd3QgbWV0aG9kcyBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCBhZGQgYSBy ZWdpc3RyeSwgZW5hYmxpbmcgc3BlY2lmaWNhdGlvbiB0aGF0IGRvIGZ1bGx5IHNwZWNpZnkgdGhl c2UgYW5kIG90aGVyIHRva2VuIGVuZHBvaW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMsIGluY2x1 ZGluZyBwb3RlbnRpYWwgbWV0aG9kcyB1c2luZyBTQU1MIGFzc2VydGlvbnMsIHRvIHJlZ2lzdGVy IHRoZW0gaW4gdGhlIHJlZ2lzdHJ5LCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYmFrZSB0aGVtIGlu dG8gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uLg0KDQpBYm91 dCAidG9zX3VyaSIgYW5kICJwb2xpY3lfdXJpIg0KDQpUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0 b3NfdXJpIGFuZCBwb2xpY3lfdXJpIGlzIHVuY2xlYXIuICBDYW4gd2UgY2xhcmlmeSBvciBjb21i aW5lIHRoZW0/DQoNClRlcm1zIG9mIHNlcnZpY2UgYW5kIHBvbGljeSBhcmUgdHdvIGRpZmZlcmVu dCBkb2N1bWVudHMuIE9uZSBpcyBzb21ldGhpbmcgdGhhdCBhIHVzZXIgYWNjZXB0cyAoZ2VuZXJh bGx5IGRlc2NyaWJpbmcgd2hhdCB0aGUgdXNlciB3aWxsIGRvKSwgb25lIGlzIGEgc3RhdGVtZW50 IG9mIHdoYXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIgKGluIHRoaXMgY2FzZSwgdGhlIGNsaWVudCkg d2lsbCBkby4gTW9yZSBpbXBvcnRhbnRseSwgd2UgdXNlZCB0byBoYXZlIG9ubHkgb25lLCBhbmQg c2V2ZXJhbCBwZW9wbGUgYXNrZWQgZm9yIHRoZW0gdG8gYmUgc3BsaXQuDQoNClNldmVyYWwgZGV2 ZWxvcGVycyB3ZXJlIGNvbmZ1c2VkIGJ5IHRoaXMuIEluIHBhcnRpY3VsYXIgdGhleSBjb3VsZG4n dCBmaWd1cmUgb3V0IHdoaWNoIHdhcyB1c2VkIGZvciB3aGF0LiAgSnVzdCBwYXNzaW5nIGFsb25n IHRoZSBmZWVkYmFjay4NCg0KT0ssIHRoZSBkaXN0aW5jdGlvbiB0aGF0IEkgc2VlIGlzIHRoYXQg dGhlIFRPUyBpcyBjb250cmFjdHVhbCwgdGhlIFBvbGljeSBpcyBhIHN0YXRlbWVudC4gUmUtcmVh ZGluZyB0aGUgZGVmaW5pdGlvbnMgaW4gdGhlcmUgcmlnaHQgbm93LCB0aGF0IGNhbiBiZSBtYWRl IG11Y2ggY2xlYXJlci4gKEl0IGV2ZW4gbG9va3MgbGlrZSBzb21lIE9JREMgdGV4dCBsZWFrZWQg aW50byB0aGUgZGVmaW5pdGlvbiBvZiBwb2xpY3lfdXJpIGFuZCB0aGF0IGhhZG4ndCBiZWVuIGNh dWdodCB5ZXQuKQ0KDQpJIHN1cHBvcnQgY2xhcmlmeWluZyB0aGUgbGFuZ3VhZ2Ugb24gdGhlc2Ug ZGVmaW5pdGlvbnMsIGFuZCB3aWxsIHdvcmsgd2l0aCBKdXN0aW4gdG8gZG8gc28uDQoNCkFsc28s IGFyZW4ndCB0aGVzZSByZWFsbHkgVVJJcyBvciBhcmUgdGhleSBtZWFudCB0byBiZSBVUkxzPw0K DQpUaGVyZSB3YXMgYWxyZWFkeSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgb24gdGhlIGxpc3Q6IFRo ZSBJRVRGIGlzIGFwcGFyZW50bHkgdHJ5aW5nIHRvIGRlcHJlY2F0ZSBVUkwgaW4gZmF2b3Igb2Yg VVJJIGluIG5ldyBzcGVjcy4gU28gaW4gcHJhY3RpY2UgdGhleSdsbCBuZWFybHkgYWx3YXlzIGJl IFVSTHMsIGJ1dCBzaW5jZSBhbGwgVVJMcyBhcmUgVVJJcyB3ZSdyZSBub3QgdGVjaG5pY2FsbHkg aW5jb3JyZWN0IGluIGZvbGxvd2luZyB0aGUgbmV3IHBvbGljeS4gQW5kIGl0IG1ha2VzIHRoZSBJ RVNHIGxlc3MgbWFkIGF0IHVzLCB3aGljaCBpcyBhIHBsdXMuDQoNCkFyZy4gTmljZS4gIFRoZW4g dGhlIHRleHQgc2hvdWxkIHNheSB0aGUgdmFsdWUgcGFzc2VkIG11c3QgcmVzb2x2ZSB0byBhIHZh bGlkIHdlYiBwYWdlLCBkb2N1bWVudCwgd2hhdGV2ZXIuDQoNClRoYXQncyBmYWlyLCBhbmQgaXQn cyBzb21ldGhpbmcgdGhhdCB0aGUgQVMgY2FuIGV2ZW4gY2hlY2sgaWYgaXQgd2FudHMgdG8uDQoN CkFncmVlZCBvbiB0aGlzIGNsYXJpZmljYXRpb24uDQoNCkFib3V0ICJqd2tzX3VyaSINCg0KQSBu b3JtYXRpdmUgcmVmZXJlbmNlIGZvciBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWIta2V5LTA5IGlzIG5lZWRlZC4NCg0KWWVzLCB5b3UncmUgY29ycmVj dCwgSSdsbCBhZGQgdGhhdC4NCg0KU2hvdWxkIGJlIFVSTCBpbnN0ZWFkIG9mIFVSST8NCg0KU2Vl IGFib3ZlLiA6KQ0KDQpBZ3JlZWQgb24gYWRkaW5nIHRoaXMgcmVmZXJlbmNlLg0KDQpTZWN0aW9u IDIuMQ0KDQpJbiB0aGUgdGFibGUgdXJuOmlldGY6cGFyYW1zOm9hdXRoOmdyYW50LXR5cGU6and0 LWJlYXJlcg0KaXMgbWlzc2luZy4NCg0KSXQncyB0aGVyZSBpbiB0aGUgY29weSBvZiAtMTAgSSdt IHJlYWRpbmcgb2ZmIG9mIGlldGYub3JnPGh0dHA6Ly9pZXRmLm9yZy8+IHJpZ2h0IG5vdyDigKYg Pw0KJw0KU29ycnkgSSBtZWFudDogdXJuOmlldGY6cGFyYW1zOm9hdXRoOmdyYW50LXR5cGU6c2Ft bC1iZWFyZXINCg0KQWgsIHRoYXQgbWFrZXMgbW9yZSBzZW5zZS4gSWYgdGhlIFdHIHdhbnRzIHRv IGFkZCBpbiBTQU1MIHN1cHBvcnQgdG8gcGFyYWxsZWwgdGhlIEpXVCBzdXBwb3J0LCBJJ2QgYmUg T0sgd2l0aCB0aGF0Lg0KDQrigJxBcyBzdWNoLCBhIHNlcnZlciBzdXBwb3J0aW5nIHRoZXNlIGZp ZWxkcyBTSE9VTEQgdGFrZSBzdGVwcyB0byBlbnN1cmUgdGhhdCBhIGNsaWVudCBjYW5ub3QgcmVn aXN0ZXIgaXRzZWxmIGludG8gYW4gaW5jb25zaXN0ZW50IHN0YXRlLuKAnQ0KDQpXZSBtYXkgd2Fu dCB0byBkZWZpbmUgbW9yZSBkZXRhaWxlZCBIVFRQIGVycm9yIHJlc3BvbnNlLiBFLmcuIDQwMCBz dGF0dXMgY29kZSArIGRlZmluZWQgZXJyb3IgY29kZSAo4oCcaW52YWxpZF9jbGllbnRfbWV0YWRh dGHigJ0pPw0KDQpJJ2QgYmUgZmluZSB3aXRoIGRlZmluaW5nIGEgbW9yZSBleHBsaWNpdCBlcnJv ciBzdGF0ZSBpbiB0aGlzIGNhc2UuIEkgdGhpbmsgaXQgd291bGQgaGVscCBpbnRlcm9wIGZvciB0 aGUgc2VydmVycyB0aGF0IHdhbnQgdG8gZW5mb3JjZSBncmFudC10eXBlIGFuZCByZXNwb25zZS10 eXBlIHJlc3RyaWN0aW9ucywgYnV0IHNlcnZlcnMgdGhhdCBjYW4ndCBvciBkb24ndCBjYXJlIGFi b3V0IHJlc3RyaWN0aW5nIGdyYW50cyB0eXBlcyBhbmQgd2hhdG5vdCBkb24ndCBoYXZlIHRvIGRv IGFueXRoaW5nIHNwZWNpYWwuDQoNCkkgKnRoaW5rKiB0aGF0IHRoaXMgZ29lcyBhd2F5IHdpdGgg dGhlIGRlbGV0aW9uIG9mIGNsaWVudF9zZWNyZXRfand0IGFuZCBwcml2YXRlX2tleV9qd3QgaW4g ZmF2b3Igb2YgdGhlIHJlZ2lzdHJ54oCmICBJ4oCZbGwgZG8gYSBjb25zaXN0ZW5jeSBjaGVjayBh bmQgdmVyaWZ5IHRoYXQgd2hlbiB0aGUgc3BlYyBpcyB1cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQpT ZWN0aW9uIDIuMg0KDQpNYXkgd2FudCB0byBhZGQ6DQoNCldoZW4g4oCcI+KAnSBsYW5ndWFnZSB0 YWcgaXMgbWlzc2luZywgKGUuZy4g4oCcI2Vu4oCdIGlzIG1pc3NpbmcgaW4g4oCcY2xpZW50X25h bWXigJ0sIGluc3RlYWQgb2Yg4oCcY2xpZW50X25hbWUjZW7igJ0pIHRoZSBPQXV0aCBzZXJ2ZXIg bWF5IHVzZSBpbnRlcnByZXQgdGhlIGxhbmd1YWdlIHVzZWQgYmFzZWQgb24gc2VydmVyIGNvbmZp Z3VyYXRpb24gb3IgaGV1cmlzdGljcy4NCg0KVGhhdCBzZWVtcyBpbmNvbnNpc3RlbnQgd2l0aCB3 aGF0IHdlIGFscmVhZHkgaGF2ZToNCg0KSWYgYW55IGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNl bnQgd2l0aG91dCBhIGxhbmd1YWdlIHRhZywgcGFydGllcyB1c2luZyBpdCBNVVNUIE5PVCBtYWtl IGFueSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgbGFuZ3VhZ2UsIGNoYXJhY3RlciBzZXQsIG9yIHNj cmlwdCBvZiB0aGUgc3RyaW5nIHZhbHVlLCBhbmQgdGhlIHN0cmluZyB2YWx1ZSBNVVNUIGJlIHVz ZWQgYXMtaXMgd2hlcmV2ZXIgaXQgaXMgcHJlc2VudGVkIGluIGEgdXNlciBpbnRlcmZhY2UuDQoN CldoaWNoIGlzIHRvIHNheSwgdHJlYXQgaXQgYXMgYSByYXcgYnl0ZS12YWx1ZS1zdHJpbmcgYW5k IGRvbid0IHRyeSB0byBnZXQgZmFuY3kuDQoNCkkgd2lsbCBkaXNjdXNzIHdpdGggb3VyIGRldmVs b3BlcnMuIEknbSBub3Qgc3VyZSB0aGUgYXMtaXMgd29ya3MuDQoNCklzIGl0IHRoZSBpbnRlbnQg dGhhdCB3aGVuIHRoZSBjbGllbnQgaGFzIGxvY2FsaXplZCAiY2xpZW50X25hbWUiIGZvciBleGFt cGxlLCBpdCBzaG91bGQgcGFzcyBhbGwgbGFuZ3VhZ2UgdmFyaWF0aW9ucyBpbiBhIEpTT04gYXJy YXk/DQoNCk9yLCBzaG91bGQgcGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIGJlIHRvIGluZGljYXRl IHdoaWNoIGludGVyZmFjZSBsYW5ndWFnZSB0aGUgY2xpZW50IHdpc2hlcyB0byB1c2U/ICBUaGVu IGl0IG9ubHkgcGFzc2VzIGEgc2luZ2xlIHZhbHVlIGZvciB0aGF0IHJlZ2lzdHJhdGlvbj8NCg0K DQpObywgdGhlIGNsaWVudCBzaG91bGQgcGFzcyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNlcGFy YXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhpcyBpbiBpdHMgZXhhbXBsZToNCg0KDQogICAiY2xp ZW50X25hbWUiOiAiTXkgRXhhbXBsZSIsDQoNCiAgICJjbGllbnRfbmFtZSNqYS1KcGFuLUpQIjoN Cg0KICAgICAi44Kv44Op44Kk44Ki44Oz44OI5ZCNIiwNClNob3VsZCB3ZSBhZGQgdGhhdCB0byBh dCBsZWFzdCBvbmUgb2YgdGhlIGV4YW1wbGVzIGluIER5blJlZz8gKFRoZSBsYW5ndWFnZSB0YWdz IGFyZSBhIGxhdGUgYWRkaXRpb24sIHNvIHRoZSBleGFtcGxlcyBkb24ndCByZWZsZWN0IGl0LikN Cg0KQW4gZXhhbXBsZSB3b3VsZCBkZWZpbml0ZWx5IGhlbHAuDQpJZiB0aGUgY2xpZW50IHBhc3Nl cyBvbmx5IGEgc2luZ2xlIHVuYWRvcm5lZCBmaWVsZCwgdGhlIEFTIGNhbid0IG1ha2UgYW55IGFz c3VtcHRpb24gYWJvdXQgd2hhdCBsYW5ndWFnZSBpdCBpcy4gVGhpbmsgb2YgdGhpcyBhcyB0aGUg aW50ZXJuYXRpb25hbGl6ZWQgdmFsdWUgb2YgdGhlIGZpZWxkIHdoaWxlIHRoZSBsYW5ndWFnZSB0 YWdzIGFyZSB0aGUgbG9jYWxpemVkIHZlcnNpb25zIG9mIHRoZSBmaWVsZC4gVGhpcyBpcyB3aHkg d2UgcmVjb21tZW5kIHRoYXQgdGhlIGJhcmUtdmFsdWUgYWx3YXlzIGJlIHNlbnQgYnkgdGhlIGNs aWVudCwgc28gdGhhdCBpbiB0aGUgbGFjayBvZiBhbnl0aGluZyBtb3JlIHNwZWNpZmljLCB0aGUg QVMgY2FuIGF0IGxlYXN0IGRvICpzb21ldGhpbmcqIHdpdGggaXQuDQoNClBhc3NpbmcgaW4gYSAi ZGVmYXVsdCIgbGFuZ3VhZ2UgZmllbGQgKGxpa2UgZGVmYXVsdF9sb2NhbGUgb3IgdGhlIGxpa2Up IGlzIG9ubHkgZ29pbmcgdG8gbGVhZCB0byBwYWluIGZvciBpbXBsZW1lbnRvcnMgb2YgYm90aCBj bGllbnRzIGFuZCBzZXJ2ZXJzLCBhbmQgaXQncyBnb2luZyB0byBodXJ0IHRoZSBpbnRlcm9wZXJh YmlsaXR5IG9mIHRoZSBodW1hbi1yZWFkYWJsZSBmaWVsZHMuDQoNCkkgdGhpbmsgd2hhdCBJIG1l YW50IGlzIHNpbmNlIHlvdSBhcmUgYWxsb3dpbmcgZWFjaCBjbGllbnQgdG8gcmVnaXN0ZXIgZGlm ZmVyZW50IHRoaW5ncywgQU5EIHRoZSBjbGllbnQgbGlrZWx5IGFscmVhZHkga25vd3MgdGhlIHVz ZXIncyBwcmVmZXJyZWQgbGFuZ3VhZ2UsIHdoeSB3b3VsZG4ndCB0aGUgY2xpZW50IGp1c3QgcGFz cyB0ZXh0IHZhbHVlcyBpbiBvbmUgbGFuZ3VhZ2UgYW5kIGFub3RoZXIgcGFyYW1ldGVyIGluZGlj YXRpbmcgcHJlZmVycmVkIGxhbmd1YWdlIGluIHRoZSBjYXNlIG9mIGFueSBzZXJ2aWNlIGdlbmVy YXRlZCB0ZXh0Lg0KDQpJcyB0aGUgcmVhc29uIHlvdSBhcmUgcGFzc2luZyBtdWx0aXBsZSBsb2Nh bGl6YXRpb25zIGlzIHNvIHRoYXQgeW91IGNhbiB1c2UgdGhlIHByZWZlcnJlZCBsYW5ndWFnZSBv ZiB0aGUgcmVzb3VyY2Ugb3duZXIgcmF0aGVyIHRoZW4gdGhlIGNsaWVudCB1c2VyPyBJIHdvbmRl ciBpZiB0aGF0IGlzIGNvcnJlY3QuICBJZiB0aGUgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgYXJlIGlu IGZhY3QgZGlmZmVyZW50LCB3aGF0IHdvdWxkIHRoZSB1c2VyIG9mIHRoZSBjbGllbnQgYXBwIGV4 cGVjdD8NCg0KLS0tLT4gYW55IG11bHRpLWxpbmd1YWwgcGVvcGxlIGhhdmUgYW55IG9waW5pb25z IGhlcmU/DQoNCldpdGhvdXQgc3BlY2lmaWMgcHJvcG9zZWQgdGV4dCBjaGFuZ2VzIHRvIHJldmll dywgaXTigJlzIGhhcmQgdG8ga25vdyB3aGF0IHRvIHRoaW5rIGFib3V0IHRoaXMgY29tbWVudC4g IFVubGVzcyBhIHNwZWNpZmljIHByb3Bvc2VkIHRleHQgY2hhbmdlIGlzIHNlbnQgdG8gdGhlIGxp c3Qgd2l0aCBjbGVhciByYXRpb25hbGUgZm9yIHdoeSBpdOKAmXMgYmV0dGVyIHRoYW4gd2hhdOKA mXMgdGhlcmUgbm93IGFuZCByZXZpZXdlZCBieSB0aGUgd29ya2luZyBncm91cCwgSSBkb27igJl0 IGJlbGlldmUgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgc3BlY2lmaWNhdGlvbiBpbiByZXNwb25zZSB0 byB0aGlzIGNvbW1lbnQuDQoNClNlY3Rpb24gMw0KDQpFeGlzdGluZyB0ZXh0Og0KDQrigJxJbiBv cmRlciB0byBzdXBwb3J0IG9wZW4gcmVnaXN0cmF0aW9uIGFuZCBmYWNpbGl0YXRlIHdpZGVyIGlu dGVyb3BlcmFiaWxpdHksIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50IFNIT1VMRCBh bGxvdyBpbml0aWFsIHJlZ2lzdHJhdGlvbiByZXF1ZXN0cyB3aXRoIG5vIGF1dGhlbnRpY2F0aW9u LiAgVGhlc2UgcmVxdWVzdHMgTUFZIGJlIHJhdGUtbGltaXRlZCBvciBvdGhlcndpc2UgbGltaXRl ZCB0byBwcmV2ZW50IGEgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIG9uIHRoZSBDbGllbnQgUmVn aXN0cmF0aW9uIEVuZHBvaW50LuKAnQ0KDQpJIHdvdWxkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoZSBm aXJzdCDigJxTSE9VTETigJ0gdG8g4oCcTUFZ4oCdLiAgIEluIG1vc3QgY2xvdWQgc2VydmljZXMs IHRoZSBmaXJzdCBjbGllbnQgaXMgcmVnaXN0ZXJlZCBieSBhIGh1bWFuIHVzZXIuIFRoZW4sIG90 aGVyIGNsaWVudHMgY2FuIGJlIGZ1cnRoZXIgdXNlZCB0byBhdXRvbWF0ZSBvdGhlciBjbGllbnQg cmVnaXN0cmF0aW9uLiAgU28sIHRoZSBmaXJzdCByZXF1ZXN0IHdvdWxkIHR5cGljYWxseSBjb21l IHdpdGggYW4gYXV0aGVudGljYXRlZCB1c2VyIGlkZW50aXR5Lg0KDQpJIHRoaW5rIHRoZSB3ZWln aHQgb2YgIlNIT1VMRCIgaXMgYXBwcm9wcmlhdGUgaGVyZSwgYmVjYXVzZSBJIGJlbGlldmUgdGhh dCB0dXJuaW5nIG9mZiBvcGVuIHJlZ2lzdHJhdGlvbiBhdCB0aGUgQVMgKHdoaWNoIGlzIHdoYXQg dGhpcyBpcyB0YWxraW5nIGFib3V0KSByZWFsbHkgb3VnaHQgdG8gYmUgdGhlIGV4Y2VwdGlvbiBy YXRoZXIgdGhhbiB0aGUgcnVsZS4NCg0KSSB0aGluayB5b3UgYXJlIHJlYWRpbmcgaXQgd3Jvbmcg LS0gYSBkb3VibGUtbmVnYXRpdmUgaXNzdWUuIFRoZSBlbmQgb2YgdGhlIHNlbnRlbmNlIGlzICJu byBhdXRoZW50aWNhdGlvbiIuICBZb3UgYXJlIGltcGx5aW5nIHRoYXQgTk8gQXV0aGVudGljYXRp b24gdXMgd2hhdCBzaG91bGQgbm9ybWFsbHkgYmUgZG9uZS4gSSB0aGluayB5b3UgaW50ZW5kIGFu b255bW91cyBhdXRoZW50aWNhdGlvbiB0byBiZSB0aGUgZXhjZXB0aW9uIHJhdGhlciB0aGFuIHRo ZSBydWxlIGRvbid0IHlvdT8NCg0KTm8sIEkgdGhpbmsgdGhhdCBhbm9ueW1vdXMgYXV0aGVudGlj YXRpb24gc2hvdWxkIGJlIHRoZSBydWxlLiBPcGVuIHJlZ2lzdHJhdGlvbiBzaG91bGQgYmUgZGVm YXVsdC4NCg0KSSBkaXNhZ3JlZS4gIEFnYWluLCAgdGhlIHNwZWMgc2VlbXMgY29udHJhZGljdG9y eS4gSXQgc3VnZ2VzdHMgc3Ryb25nIGNsaWVudCBhdXRoIG1ldGhvZHMgYW5kIGF0IHRoZSBzYW1l IHRpbWUgYW5vbnltb3VzIHJlZ2lzdHJhdGlvbi4gIFllcyB5b3UgZ2FpbiB1bmlxdWVuZXNzLCBi dXQgdGhhdCdzIGFib3V0IGl0Lg0KDQpPbiB0aGUgZmxpcCBzaWRlLCB0aGUgZWFybGllciBwYXJh Z3JhcGg6DQoNCuKAnFRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50IE1BWSBhY2NlcHQg YW4gaW5pdGlhbCBhdXRob3JpemF0aW9uIGNyZWRlbnRpYWwgaW4gdGhlIGZvcm0gb2YgYW4gT0F1 dGggMi4wIFtSRkM2NzQ5XSBhY2Nlc3MgdG9rZW4gaW4gb3JkZXIgdG8gbGltaXQgcmVnaXN0cmF0 aW9uIHRvIG9ubHkgcHJldmlvdXNseSBhdXRob3JpemVkIHBhcnRpZXMuIFRoZSBtZXRob2QgYnkg d2hpY2ggdGhpcyBhY2Nlc3MgdG9rZW4gaXMgb2J0YWluZWQgYnkgdGhlIHJlZ2lzdHJhbnQgaXMg Z2VuZXJhbGx5IG91dC1vZi1iYW5kIGFuZCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uLuKAnQ0KDQpJIHRlbmQgdG8gdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGNoYW5n ZSB0aGlzIOKAnE1BWeKAnSB0byDigJxTSE9VTETigJ0uDQoNClRoYXQgYWNjZXNzIHRva2VuIHdv dWxkIGNhcnJ5IGEgaHVtYW4gdXNlciBhdXRoZW50aWNhdGVkIGlkZW50aXR5IHNvbWVob3cuIElu IHNvbWUgY2FzZXMsIGl0IGNhbiBiZSBhIHB1cmUgYXV0aGVudGljYXRlZCB1c2VyIGFzc2VydGlv biB0b2tlbi4NCg0KQWdhaW4sIGRpc2FncmVlLCBmb3IgdGhlIHNhbWUgcmVhc29uaW5nIGFzIGFi b3ZlLg0KDQpTYW1lIHJlYXNvbmluZy4NCg0KSSBhZ3JlZSB3aXRoIEp1c3RpbiBoZXJlLiAgVGhl IGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgb3BlbiByZWdpc3RyYXRpb25zIGFyZSBlbmFibGVkLiAg VGhlIGV4Y2VwdGlvbiBjYXNlIGlzIHRoYXQgc3BlY2lmaWMgcGVybWlzc2lvbnMgYXJlIHJlcXVp cmVkIHRvIHBlcmZvcm0gZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uLg0KDQpBYm91dCBzZWN0 aW9uIDQuMzoNCg0KDQpJZiB0aGUgY2xpZW50IGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc2VydmVy LCB0aGUgc2VydmVyIE1VU1QgcmVzcG9uZA0KDQogICB3aXRoIEhUVFAgNDAxIFVuYXV0aG9yaXpl ZCwgYW5kIHRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIHVzZWQgdG8NCg0KICAgbWFrZSB0 aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQuDQoNCklmIHRoZSBDbGll bnQgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzZXJ2ZXIsIHNob3VsZG4ndCBpdCByZXR1cm4gYSAi NDA0IE5vdCBGb3VuZCI/DQoNCklmIHJldm9raW5nIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2VuLCBpcyBpdCBib3VuZCB0byBhIHNpbmdsZSBjbGllbnQgcmVnaXN0cmF0aW9uPyAgVGhpcyBp cyBub3QgY2xlYXIuICBXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJlZ2lzdHJhdGlvbiBh Y2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJlc3Bv bnNlIGluIHNlY3Rpb24gNS4xLg0KDQpUaGUgbGFuZ3VhZ2UgYWJvdXQgdGhlIDQwMSBoZXJlIChh bmQgaW4gb3RoZXIgbmVhcmJ5IHNlY3Rpb25zKSBpcyBzcGVjaWZpY2FsbHkgc28gdGhhdCB5b3Ug dHJlYXQgYSBtaXNzaW5nIGNsaWVudCBhbmQgYSBiYWQgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biB0aGUgc2FtZSB3YXkuIFlvdSBzZWUsIHJldHVybmluZyBhIDQwNCBoZXJlIGFjdHVhbGx5IGlu ZGljYXRlcyB0aGluZ3Mgd2VyZSBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGUuIE5hbWVseSwgdGhh dCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgc3RpbGwgdmFsaWQgYnV0IHRoZSBj bGllbnQgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgYXR0YWNoZWQgdG8g ZG9lc24ndCBleGlzdCBhbnltb3JlLiBUaGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbiBt ZWFudCB0byBiZSB0aWVkIHRvIGEgY2xpZW50J3MgaW5zdGFuY2UgKG9yIHJlZ2lzdHJhdGlvbiks IHNvIGl0J3MgYWN0dWFsbHkgbW9yZSBzZW5zaWJsZSB0byBhY3QgYXMgdGhvdWdoIHRoZSByZWdp c3RyYXRpb24gYWNjZXNzIHRva2VuIGlzbid0IHZhbGlkIGFueW1vcmUuIEluIGF0IGxlYXN0IHNv bWUgaW1wbGVtZW50YXRpb25zIChzcGVjaWZpY2FsbHkgb3VycyBhdCBNSVRSRSB0aGF0J3MgYnVp bHQgb24gU0VDT0FVVEggaW4gSmF2YSksIHlvdSdkIG5ldmVyIGJlIGFibGUgdG8gcmVhY2ggdGhl IDQwNCBzdGF0ZSBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0aGUgaW5ib3VuZCB0 b2tlbi4NCg0KU2luY2UgdGhlIGludGVudCBvZiB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tl biBpcyB0aGF0IGl0J3MgYm91bmQgdG8gYSBzaW5nbGUgaW5zdGFuY2UsIGl0cyBsaWZlY3ljbGUg aXMgZ2VuZXJhbGx5IHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBiZWdpbnMgYXQgdGhlIGlzc3VhbmNl IG9mIGEgbmV3IGNsaWVudF9pZCB3aXRoIHRoYXQgaW5zdGFuY2UuIFRoYXQgdG9rZW4gbWlnaHQg YmUgcmV2b2tlZCBhbmQgYSBuZXcgb25lIGlzc3VlZCBvbiBSZWFkIGFuZCBVcGRhdGUgcmVxdWVz dHMgdG8gdGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50IChhbmQgdGhlIGNsaWVudCBu ZWVkcyB0byBiZSBwcmVwYXJlZCBmb3IgdGhhdCAtLSBzYW1lIGFzIHRoZSBjbGllbnRfc2VjcmV0 KSwgYW5kIGl0IHdpbGwgYmUgcmV2b2tlZCB3aGVuIHRoZSBjbGllbnQgaXMgZGVsZXRlZCBlaXRo ZXIgd2l0aCBhIERlbGV0ZSBjYWxsIHRvIHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2lu dCBvciBzb21ldGhpbmcgaGFwcGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwgdGhlIGNsaWVudC4N Cg0KU2hvdWxkIHdlIGFkZCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgdG8gdGhlIGRlZmluaXRpb24g aW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdtIHZlcnkgb3BlbiB0byBj b25jcmV0ZSBzdWdnZXN0aW9ucyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9uJ3QgdGhpbmsgaXQncyBh cyBjbGVhciBhcyB3ZSdkIGxpa2UuDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGxvb2sgYXQgaXQuDQoN CkZvciBzZWN1cml0eSByZWFzb25zLCBpdOKAmXMgZ2VuZXJhbGx5IG5vdCBnb29kIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4g4oCcbm90IGZvdW5k4oCdIGFuZCDigJx1bmF1dGhvcml6ZWTigJ0gZXJy b3JzIGluIHJlc3BvbnNlcywgYXMgdGhhdCBjYW4gcHJvdmlkZSB0aGUgYXR0YWNrZXIgYW4gb3Jh Y2xlIHRvIHByb2JlIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIGVudGl0eSBleGlzdHMgIEkgZG9u4oCZ dCB0aGluayBhIGNoYW5nZSBpcyBjYWxsZWQgZm9yIGhlcmUuDQoNCkFib3V0IHNlY3Rpb24gNS4x Og0KSXMgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiB1bmlxdWU/ICBPciBpcyBpdCBzaGFyZWQg YnkgbXVsdGlwbGUgaW5zdGFuY2VzPyAgIElmIHNoYXJlZCwgdGhlbiByZWdpc3RyYXRpb25fYWNj ZXNzX3Rva2VuIGNhbid0IGJlIHJldm9rZWQgb24gZGVsZXRlIG9mIGNsaWVudC4NCg0KVGhlIHJl Z2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMgdW5pcXVlIHRvIGEgcmVnaXN0ZXJlZCBjbGllbnQs IGluIHRoZSBSRkMgNjc0OSBzZW5zZSBvZiDigJxjbGllbnTigJ0uICBBZ2FpbiwgaWYgd2Ugd2Fu dCB0byBkbyB3b3JrIG9uIOKAnGNsaWVudCBpbnN0YW5jZXPigJ0sIHdlIG5lZWQgdG8gcmVjaGFy dGVyIGFuZCB0YWtlIHRoaXMgZGlzdGluY3Qgd29yayBpdGVtIHVwIGV4cGxpY2l0bHkuDQoNClN1 Z2dlc3QgcmVuYW1lIOKAnGV4cGlyZXNfYXTigJ0gdG8g4oCcY2xpZW50X3NlY3JldF9leHBpcmVz X2F04oCdLA0KDQpTdWdnZXN0IHRvIHJlbmFtZSDigJxpc3N1ZWRfYXTigJ0gdG8g4oCcaWRfaXNz dWVkX2F04oCdDQoNCldoaWxlIEkgZG8gbGlrZSB0aGUgc3VnZ2VzdGlvbiBvZiBjaGFuZ2luZyB0 aGVzZSB0byBjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXQgYW5kIGNsaWVudF9pZF9pc3N1ZWRfYXQs IGFuZCBJIHRoaW5rIHRoZXNlIGFyZSBtb3JlIGNsZWFyIGFuZCByZWFkYWJsZSwNCg0KDQpJIGRv bid0IHdhbnQgdG8gY2hhbmdlIHRoZSBzeW50YXggZHVyaW5nIGxhc3QgY2FsbCB1bmxlc3MgdGhl cmUgaXMgYSBjbGVhciBuZWVkIGFuZCBhIGNsZWFyIGNvbnNlbnN1cyBmb3IgZG9pbmcgc28uDQoN ClRoYXQncyB3aHkgd2UgYXJlIGhhdmluZyBsYXN0IGNhbGwuIFRvIGNvbmZpcm0gY29uc2Vuc3Vz IG9uIHRoZSBkcmFmdC4NCg0KU2FtZSByZWFzb25pbmcgYXMgZWFybGllci4gWW91IG5vdyBoYXZl IG11bHRpcGxlIHRva2VucyAocmVnaXN0cmF0aW9uIGFjY2VzcyBhbmQgY2xpZW50KSBpbiBwbGF5 LiBUaGUgc3BlYyBuZWVkcyB0byBiZSBjbGVhciB3aGljaCBvbmUgaXQgaXMgdGFsa2luZyBhYm91 dC4NCg0KSSdtIGZpbmUgd2l0aCB0aGUgc3VnZ2VzdGVkIGNoYW5nZSBidXQgSSB3b3VsZCBsaWtl IG1vcmUgZmVlZGJhY2sgZnJvbSBvdGhlciBwZW9wbGUgYmVmb3JlIG1vdmluZyBmb3J3YXJkIHdp dGggaXQuIFRoZXJlJ3MgYSBsb3Qgb2YgdmFsdWUgaW4gImp1c3QgcGljayBhIG5hbWUgYW5kIHNo aXAgaXQiIGFzIHdlbGwgdGhvdWdoLCBhbmQgSSBkb24ndCB3YW50IHRvIGRldm9sdmUgaW50byBi aWtlIHNoZWRkaW5nLiAoSSdtIG5vdCBhY2N1c2luZyB5b3Ugb2YgYmlrZSBzaGVkZGluZyBxdWl0 ZSB5ZXQsIGJ0dywganVzdCBhZnJhaWQgb2YgZ2V0dGluZyBpbnRvIGEgbG9uZyBkZWJhdGUgb24g bmFtZXMuKQ0KDQpBZ2FpbiwgdGhpcyB3YXMgYSBwcm9ibGVtIHJhaXNlZCBieSBwZW9wbGUgbmV3 IHRvIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGV5IGZvdW5kIGl0IGNvbmZ1c2luZy4gSSB0ZW5kIHRv IGFncmVlLiBXZSdyZSBub3QgdGFsa2luZyBhYm91dCB3aGF0IGNvbG91ciB0byBwYWludCB0aGUg c2hlZC4gV2UncmUgdGFsa2luZyBhYm91dCB3aGV0aGVyIHRoZSBiaWtlIHNoZWQgaXMgYSBob3Vz ZS4gIDotKQ0KDQpJJ20gbm90IHRvbyBmdXNzZWQgYWJvdXQgd2hldGhlciB5b3UgY2FsbCBpdCAi Y2xfc2VjX2V4cGlyeSIgb3IgImNsaWVudF9zZWNyZXRfZXhwaXJlc19hdCIuDQoNCklmIHRoZSBk ZWZpbml0aW9ucyBvZiDigJxleHBpcmVzX2F04oCdIG9yIOKAnGlzc3VlZF9hdOKAnSBhcmUgdW5j bGVhciwgd2Ugc2hvdWxkIGNsYXJpZnkgdGhlbS4gIElmIHlvdSBiZWxpZXZlIHRoYXQgdGhpcyBp cyB0aGUgY2FzZSBQaGlsLCBjYW4geW91IHN1cHBseSBwcm9wb3NlZCBhbHRlcm5hdGl2ZSBkZWZp bml0aW9uIHRleHQgdGhhdCBpcyBjbGVhcmVyPyAgVGhhdCBiZWluZyBzYWlkLCBJIGJlbGlldmUg dGhhdCBhdCB0aGlzIHBvaW50IHdlIHNob3VsZCBzdGljayB3aXRoIHRoZSBleGlzdGluZyBwcm90 b2NvbCBlbGVtZW50IG5hbWVzIHVubGVzcyBvdmVyd2hlbG1pbmcgd29ya2luZyBncm91cCBzZW50 aW1lbnQgZW1lcmdlcyB0byBjaGFuZ2UgdGhlbS4gIFRoZXkgYXJlIGFscmVhZHkgd29ya2luZyBm aW5lIGFzLWlzIGluIHByb2R1Y3Rpb24gZGVwbG95bWVudHMuDQoNClNlY3Rpb24gNw0KDQpXaGVu IGEgY2xpZW50X3NlY3JldCBleHBpcmVzIGlzIGl0IHRoZSBpbnRlbnQgdGhhdCBjbGllbnRzIGRv IGFuIHVwZGF0ZSBvciByZWZyZXNoIHRvIGdldCBhIG5ldyBjbGllbnQgc2VjcmV0Pw0KDQpZZXMs IHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gZWl0aGVyIGNhbGwgdGhlIHJlYWQgb3IgdXBkYXRl IG1ldGhvZHMgb24gdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGVuZHBvaW50IHRvIGdldCBpdHMg bmV3IHNlY3JldC4gQXMgZGlzY3Vzc2VkIGFib3ZlLCBJJ20gbm90IHN1cmUgdGhhdCdzIGFzIGNs ZWFyIGFzIGl0IG5lZWRzIHRvIGJlLCBhbmQgSSB3ZWxjb21lIHN1Z2dlc3Rpb25zIG9uIGhvdyB0 byBjbGFyaWZ5IHRoaXMuDQoNCkVpdGhlciBpcyBhIHJlYXNvbmFibGUgYmVoYXZpb3Igb24gdGhl IGJlaGFsZiBvZiBjbGllbnRzLCBkZXBlbmRpbmcgdXBvbiBjb250ZXh0LiAgSSBzdXBwb3J0IGFk ZGluZyB0ZXh0IHRvIGNsYXJpZnkgdGhpcy4NCg0KQWdhaW4sIHRoYW5rcyBmb3IgdGhlIHZlcnkg dGhvcm91Z2ggcmVhZCB0aHJvdWdoLiBIYXZlIHlvdSBpbXBsZW1lbnRlZCBhbnkgb2YgdGhlIHNw ZWMgeWV0LCBlaXRoZXIgYXMtaXMgb3Igd2l0aCBhbnkgb2YgeW91ciBzdWdnZXN0ZWQgY2hhbmdl cz8NCg0KWWVzLiBNdWNoIG9mIHRoZSBmZWVkYmFjayBpcyBjb21pbmcgZnJvbSBvdXIgZGV2ZWxv cG1lbnQgY29tbXVuaXR5Lg0KDQpBaCwgdmVyeSBjb29sLiBEZXZlbG9wZXIgZXhwZXJpZW5jZSBp cyB0aGUgbW9zdCB2YWx1YWJsZSBmZWVkYmFjaywgaW4gbXkgb3Bpbmlvbi4gSWYgeW91IGNhbid0 IGFjdHVhbGx5IGJ1aWxkIHRoZSBibGFzdGVkIHRoaW5nLCB3aGF0IGdvb2QgaXMgaXQ/IDopDQoN CkdsYWQgdG8gaGVhciB0aGF0IHlvdeKAmXJlIHdvcmtpbmcgd2l0aCBkZXZlbG9wZXJzIGJ1aWxk aW5nIHRoZSBzcGVjLiAgUGxlYXNlIHRoYW5rIHRoZW0gZm9yIHRoZSBmZWVkYmFjay4NCg0KIC0t IEp1c3Rpbg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K --_000_4E1F6AAD24975D4BA5B16804296739436773435CTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDEx IDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcMDAyN0NvdXJpZXIgTmV3XDAwMjciOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBs ZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZmVl ZGJhY2ssIFBoaWwuJm5ic3A7IFNvcnJ5IGZvciB0aGUgZGVsYXllZCByZXNwb25zZSDigJMgSSB3 YXMgcHJldHR5IGZ1bGx5IGVuZ2FnZWQgYXQgdGhlIEV1cm9wZWFuIElkZW50aXR5IENvbmZlcmVu Y2UgKHdoZXJlDQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xMDI2Ij5PQXV0 aCAyLjAgd29uIHRoZSBhd2FyZCBmb3IgYmVzdCBuZXcgc3RhbmRhcmQ8L2E+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PikuJm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIw NTAiPk15IGZlZWRiYWNrIG9uIHRoZSBwb2ludHMgcmFpc2VkIGlzIGlubGluZSBpbiBncmVlbuKA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+KFBlcmhhcHMgaWYgYW55IG9mIHlvdSByZXBseSB0byB0aGlzIHRocmVhZCwg eW91IGNvdWxkIGFsc28gY2hvb3NlIGEgZGlzdGluY3QNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5jb2xvcg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5mb3IgeW91ciBpbmxpbmUgcmVwbGllcywgc28gdGhhdCBp dCB3aWxsIGJlIGVhc2lseSBldmlkZW50IHdobyBzYWlkIHdoYXQuJm5ic3A7IEFzIGl0IGlzLCBq dXN0IHRoZSBiYWNrLWFuZC1mb3J0aCBiZXR3ZWVuIFBoaWwgYW5kIEp1c3RpbiBpcyBhbHJlYWR5 IHZlcnkgZGlmZmljdWx0IHRvIGZvbGxvdy4mbmJzcDsNCiBUaGFua3MuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBI dW50PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMTI6NTQgUE08YnI+ DQo8Yj5Ubzo8L2I+IFJpY2hlciwgSnVzdGluIFAuPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRm Lm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBMYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+SnVzdGluLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5UaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBNb3JlIGNvbW1lbnRzIGJlbG93Li4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QlRXLiBJJ20g aGFwcHkgdG8gY29udHJpYnV0ZSB0ZXh0LiBKdXN0IHdhbnQgdG8gZ2V0IHRvIHNvbWUgcm91Z2gg YWdyZWVtZW50IGZpcnN0LiAmbmJzcDtGb3IgZXhhbXBsZSwgSSB0aGluayB3ZSBuZWVkIHRvIGhh dmUgYSBhd2F5IHRvIHJlY29nbml6ZSB0d28gcGllY2VzIG9mIHNvZnR3YXJlIGFzIGJlaW5nIHRo ZSBzYW1lIChldmVuIGlmIHNlbGYtYXNzZXJ0ZWQpLiAmbmJzcDtPbmNlDQogZGVmaW5lZCwgSSBj YW4gcHV0IHRvZ2V0aGVyIHNvbWUgaW50cm8gdGV4dCwgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5k ZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPk9uIDIwMTMtMDUtMTYsIGF0IDU6MTYgQU0sIFJpY2hlciwgSnVzdGluIFAuIHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTWF5 IDE1LCAyMDEzLCBhdCAxMDozMCBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDt3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5PbiAyMDEzLTA1LTE1LCBhdCA1OjUzIFBNLCBSaWNoZXIsIEp1 c3RpbiBQLiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5QaGlsLCBtYW55 IHRoYW5rcyBmb3IgdGhlIGV4dHJlbWVseSB0aG9yb3VnaCByZXZpZXchIEl0IGlzIHZlcnkgdXNl ZnVsIGluZGVlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5NeSBjb21tZW50cyBhbmQgcmVzcG9uc2VzIHRvIGVhY2ggcG9pbnQgYXJlIGlubGluZS4mbmJz cDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIE1heSAxNSwgMjAx MywgYXQgNDozMCBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBzZWVtcyB1bmZvcnR1bmF0ZSB0 aGF0IEkgaGF2ZSBub3QgZ290dGVuIGEgY2hhbmNlIHRvIGdldCBpbnRvIHRoaXMgbGV2ZWwgb2Yg ZGV0YWlsIG11Y2ggZWFybGllci4gQnV0IHRoZW4sIEkgZ3Vlc3MgdGhhdCdzIHdoYXQgTEMgcmV2 aWV3IGlzIGZvciEgTXkgYXBvbG9naWVzIGZvciBub3QgZ2V0dGluZyBtYW55IG9mIHRoZXNlIGNv bmNlcm5zIHRvIHRoZSBXRyBtdWNoDQogZWFybGllci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxpPk92ZXJhbGwgJm5ic3A7PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkg dGhpbmsgZHluYW1pYyByZWdpc3RyYXRpb24gaXMgYSBjcml0aWNhbCBwYXJ0IG9mIHRoZSBPQXV0 aCBmcmFtZXdvcmsgbm93IHRoYXQgd2UgYXJlIHN0YXJ0aW5nIHRvIGNvbnNpZGVyIGhvdyBpbmRp dmlkdWFsIGNsaWVudCBhcHBsaWNhdGlvbnMgc2hvdWxkIG9wZXJhdGUgd2hlbiB0aGVyZSBpcyBv bmUgb3IgbW9yZSBkZXBsb3ltZW50cyBvZiBhIHBhcnRpY3VsYXINCiByZXNvdXJjZSBBUEkuIFdl J3ZlIG1vdmVkIGZyb20gdGhlIHNpbXBsZSB1c2UgY2FzZSBvZiBhIHNpbmdsZSBBUEkgcHJvdmlk ZXIgbGlrZSBGYWNlYm9vayBvciBGbGlja3IgYW5kIG1vdmVkIG9uIHRvIHN0YW5kYXJkcyBiYXNl ZCwgb3BlbiBzb3VyY2UgYmFzZWQsIGFuZCBjb21tZXJjaWFsIGJhc2VkIGRlcGxveW1lbnRzIHdo ZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBzZXJ2aWNlIGVuZHBvaW50cyBhbmQgbWFueSBjbGllbnRz IHRvIG1hbmFnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5UaGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBpcyBhY3R1YWxseSBkZWFsaW5nIHdpdGgg YSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBtYWRlIG1vcmUgY2xl YXIgaW4gZWFybHkgcGFydCBvZiB0aGUgc3BlYzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4xLiAmbmJzcDtIb3cgaXMgYSBuZXcgY2xpZW50IGFwcGxpY2F0 aW9uIHJlY29nbml6ZWQgZm9yIHRoZSBmaXJzdCB0aW1lIHdoZW4gZGVwbG95ZWQgYWdhaW5zdCBh IHBhcnRpY3VsYXIgU1AgZW5kcG9pbnQ/ICZuYnNwO1Nob3VsZCBjbGllbnRzIGFjdHVhbGx5IGFz c2VydCBhbiBhcHBsaWNhdGlvbl9pZCBVVUlEIHRoYXQgbmV2ZXIgY2hhbmdlcyBhbmQgcG9zc2li bHkgYSB2ZXJzaW9uDQogaWQgdGhhdCBkb2VzIGNoYW5nZSB3aXRoIHZlcnNpb25zPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SW4gdGhlIGdl bmVyYWwgY2FzZSwgd2h5IGlzIGFueSByZWNvZ25pdGlvbiByZXF1aXJlZD8gSWYgeW91J3JlIGRv aW5nIHRoaW5ncyBhcyBwYXJ0IG9mIGEgbGFyZ2VyIHByb3RvY29sIGVjb3N5c3RlbSwgbGlrZSBC bHVlIEJ1dHRvbiYjNDM7IG9yIGEgcGFydGljdWxhciBPcGVuSUQgQ29ubmVjdCBwcm92aWRlciwg dGhlbiB5b3UgY2FuIGRlZmluZSBzZW1hbnRpY3MgZm9yIHR5aW5nDQogdG9nZXRoZXIgY2xhc3Nl cyBvZiBjbGllbnRzIChzZWUgYmVsb3cgZm9yIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlzIHZlcnkg cG9pbnQpLiBCdXQgaW4gZ2VuZXJhbCwgYSBjbGllbnQgaXMganVzdCBnb2luZyB0byBzaG93IHVw IGFzIGEgbmV3IGluc3RhbmNlIHRvIHRoZSBBUyBhbmQgZ2V0IGlzc3VlZCBhIG5ldywgdW5pcXVl IGNsaWVudF9pZCwgYW5kIHRoYXQncyB0aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRoaW5r IHdlIGhhdmUgdG8gZGVmaW5lIG1vcmUgY2xlYXJseSB3aGF0IGFuICZxdW90O2luc3RhbmNlJnF1 b3Q7IGlzLiBGb3IgbWUsIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgYW5kIHRoZXJlIGFyZSBpbnN0 YW5jZXMgb2YgdGhhdCBhcHBsaWNhdGlvbi4gJm5ic3A7SXQgaXMgdXNlZnVsIHRvIHVuZGVyc3Rh bmQgdGhhdCBhIGNsaWVudCBhcHBsaWNhdGlvbiByZXByZXNlbnRzIGEgc2V0IG9mDQogY29kZSB0 aGF0IHNob3VsZCBiZWhhdmUgaW4gYSBjb25zaXN0ZW50IHdheS4gJm5ic3A7SXQgc2VlbXMgdG8g bWUgdGhlIGZpcnN0IHRpbWUgYSBuZXcgYXBwbGljYXRpb24gc2hvd3MgdXAgaXMgdmVyeSBkaWZm ZXJlbnQgZnJvbSB0aGUgc3Vic2VxdWVudCBpbnN0YW5jZXMgdGhhdCByZWdpc3Rlci4gRm9yIGV4 YW1wbGUsIGFmdGVyIHRoZSBmaXJzdCByZWdpc3RyYXRpb24sIHN1YnNlcXVlbnQgaW5zdGFuY2Vz IGRvbid0IG5lZWQgc3BlY2lhbCByZXZpZXcNCiBvciBhcHByb3ZhbCB0byB0aGUgc2FtZSBkZWdy ZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkJ1dCB3aXRob3V0IG90aGVyIG1lY2hhbmlzbXMgdG8gdGllIHRoaW5ncyB0b2dl dGhlciwgdGhlcmUncyBubyB3YXkgZm9yIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGtub3cg aWYgYW55IGNsaWVudCBpbnN0YW5jZSBpcyB0aWVkIHRvIGFueSBvdGhlciBjbGllbnQgaW5zdGFu Y2UuIFRoZXJlZm9yZSwgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYW4gQVMsIHRoZQ0KIGZpcnN0 IGluc3RhbmNlIG9mIGFuIGFwcGxpY2F0aW9uIChpLmUuLCBwYXJ0aWN1bGFyIGNvbmZpZ3VyYXRp b24gb2YgYSBzZXQgb2YgY29kZSkgdG8gcmVnaXN0ZXIgaXMgbm8gZGlmZmVyZW50IHRvIHN1YnNl cXVlbnQgaW5zdGFuY2VzIG9mIHRoYXQgc2FtZSBhcHBsaWNhdGlvbi4gSG93IHdlcmUgeW91IGVu dmlzaW9uaW5nIGFuIEFTIGtub3dpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZmlyc3Qg YW5kIHN1YnNlcXVlbnQgaW5zdGFuY2VzDQogb2YgYW4gYXBwbGljYXRpb24sIHNwZWNpZmljYWxs eT8gSWYgdGhlcmUncyBhbiAmcXVvdDthcHBsaWNhdGlvbl9pZCZxdW90OyBsaWtlIHlvdSBtZW50 aW9uIGFib3ZlLCBJIHRoaW5rIGl0IHJhaXNlcyBtb3JlIHF1ZXN0aW9ucyB0aGFuIGl0IHJlc29s dmVzOiBXaG8gaXNzdWVzIHRoZSBhcHBsaWNhdGlvbl9pZCwgc29tZSBzZXJ2ZXIgb3IgdGhlIGFw cGxpY2F0aW9uIGl0c2VsZj8gSXMgaXQgdmFsaWRhdGVkIGF0IGFsbD8gU2hvdWxkIGl0IGJlIGNv bnNpZGVyZWQNCiBzZWNyZXQ/IFdoYXQgaGFwcGVucyB3aGVuIHNvbWVvbmUgc2ltcGx5IHN0ZWFs cyBhbiBhcHBsaWNhdGlvbl9pZD8gRG9lcyBhbiBBUyBoYXZlIHRvIGRvIGFueXRoaW5nIHRvIGNo ZWNrIHdpdGggYW55IG90aGVyIEFTIHRvIHNlZSBpZiB0aGUgYXBwbGljYXRpb25faWQgaGFzIGFs cmVhZHkgYmVlbiB1c2VkIGVsc2V3aGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5JIGRvIGFncmVlIHRoYXQgYSBkaXNjdXNzaW9uIG9mICZxdW90O2lu c3RhbmNlIHZzLiBhcHBsaWNhdGlvbiZxdW90OyB3b3VsZCBiZSBoZWxwZnVsIGluIGNsZWFyaW5n IHRoaXMgdXAsIEknbGwgbWFrZSBhIG5vdGUgdG8gYWRkIHRleHQgdG8gdGhhdCBlZmZlY3QuIChX ZSBoYWQgdG8gZG8gc29tZXRoaW5nIHNpbWlsYXIgZm9yIEJCJiM0MzspPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsg aXQgaXMgc2ltcGxlIGVub3VnaCB0byBhdCBsZWFzdCBhZGQgYSBzZWxmIGdlbmVyYXRlZCBVVUlE IGZvciB0aGUgYXBwbGljYXRpb24gSUQuICZuYnNwO1Rob3VnaCBJIHdvdWxkIGFsbG93IGZvciBj YXNlcyB3aGVyZSB0aGUgYXBwbGljYXRpb24gSUQgaXMgYXNzaWduZWQgd2hlbiB0aGUgY2xpZW50 IGRldmVsb3BlciBhbmQgdGhlIEFQSXMgb3duZXIgZG8gYSBmb3JtYWwNCiBhc3NpZ25tZW50IG9m IGFwcGxpY2F0aW9uIElEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JbiBhIHNlbnNlIHRoaXMgaXMganVzdCBhIGxvd2VyIHRlY2ggd2F5IG9mIGRvaW5n IGl0IHRoYW4gd2hhdCB5b3UgZGVzY3JpYmVkIGFzIHRoZSBpbml0aWFsIGNsaWVudCBjcmVkZW50 aWFsIGluIEJsdWUgQnV0dG9uJiM0Mzsgd2hlcmUgeW91IGVuY29kZWQgZXh0cmEgY2xhaW1zIGlu dG8gdGhlIGluaXRpYWwgYXBwIGNyZWRlbnRpYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hhdCB0aGUgVVVJRCBkb2VzIGlzIGxpbmsgbXVsdGlwbGUg aW5zdGFuY2VzIG9mIGEgY2xpZW50IGFwcCB0b2dldGhlciBhcyB0aGUgc2FtZSAmcXVvdDt0aGlu ZyZxdW90OyB0aGF0IHNob3VsZCBoYXZlIHNpbWlsYXIgaGV1cmlzdGljcy9iZWhhdmlvdXJzLiAm bmJzcDtUaGlzIGlzIHZlcnkgdXNlZnVsIGlmIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gcmV2b2tl IGFjY2VzcyB0byBhIHNldCBvZg0KIGNsaWVudHMgaWRlbnRpZmllZCBieSBhcHBsaWNhdGlvbiBp ZCAob3IgYSB2ZXJzaW9uIG9mIHRoYXQgYXBwKS48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDBCMDUwIj5XaGlsZSBJ4oCZbSBzeW1wYXRoZXRpYyB0byB0aGUgT0F1dGggd29ya2luZyBn cm91cCBldmVudHVhbGx5IGRvaW5nIHdvcmsgb24gZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gaW5z dGFuY2VzIG9mIGFuIE9BdXRoIGNsaWVudCwgSeKAmWxsIG5vdGUgdGhhdCBpbiBSRkMgNjc0OSBv cg0KIFJGQyA2NzUwIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYSBjbGllbnQgaW5zdGFuY2Uu Jm5ic3A7IFRoZXJlIGFyZSBvbmx5IGNsaWVudHMsIHdoaWNoIGFyZSBpZGVudGlmaWVkIGJ5IGNs aWVudF9pZCB2YWx1ZXMuJm5ic3A7IElmIHdlIHdhbnQgdG8gZG8gd29yayBvbiBjbGllbnQgaW5z dGFuY2VzLCB3ZSBzaG91bGQgcmVjaGFydGVyIHRvIGFkZCB0aGlzIG5ldyB3b3JrIGFzIGEgd29y a2luZyBncm91cCBkZWxpdmVyYWJsZS4mbmJzcDsgV2Ugc2hvdWxkIG5vdCB0cnkNCiB0byBzaG9l aG9ybiBiaXRzIGFuZCBwaWVjZXMgb2YgaXQgaW50byB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24g c3BlYywgYW55IG1vcmUgdGhhbiB3ZSBzaG91bGQgaGF2ZSB0cmllZCB0byBzaG9laG9ybiBpdCBp bnRvIFJGQyA2NzQ5IG9yIFJGQyA2NzUwLiZuYnNwOyBPYXV0aC1keW4tcmVnIGlzIHRoZXJlIHRv IHJlZ2lzdGVyIGNsaWVudHMgYXMgZGVmaW5lZCBpbiBSRkMgNjc0OS4mbmJzcDsgSXTigJlzIG5v dCB0aGUgcmlnaHQgcGxhY2UgdG8gZXh0ZW5kIHdoYXQNCiBhbiBPQXV0aCBjbGllbnQgaXMgaW4g bmV3IHdheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjIuICZuYnNwO0hvdyBhcmUgY2xpZW50IGNyZWRlbnRpYWxzIG1hbmFnZWQu IEFyZSB3ZSBhc3N1bWluZyBjbGllbnQgY3JlZGVudGlhbHMgaGF2ZSBhIGxpbWl0ZWQgbGlmZXRp bWUgb3Igcm90YXRpb24gcG9saWN5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5UaGUgaW50ZW50IHdhcyB0aGF0IGNsaWVudF9zZWNyZXQgY291bGQgYmUg cm90YXRlZCwgYXMgaW5kaWNhdGVkIGJ5IHRoZSBleHBpcmVzX2F0IG1lbWJlciBvZiB0aGUgcmVz cG9uc2UuIElmIGEgY2xpZW50J3Mgc2VjcmV0IGV4cGlyZXMsIGl0IGNhbGxzIHRoZSByZWFkIG9w ZXJhdGlvbiBvbiB0aGUgQ2xpZW50IENvbmZpZ3VyYXRpb24gRW5kcG9pbnQgKMKnNC4yKSB0bw0K IGdldCBpdHMgbmV3IGNsaWVudF9zZWNyZXQuIElmIHRoaXMgaXMgdW5jbGVhciBpbiB0aGUgY3Vy cmVudCB0ZXh0ICh3aGljaCBJIHN1c3BlY3QgaXQgbWF5IGJlIGFmdGVyIG11bHRpcGxlIHJlZmFj dG9yaW5ncyksIHRoZW4gSSB3ZWxjb21lIHN1Z2dlc3Rpb25zIGFuZCBzcGVjaWZpYyB0ZXh0IGFz IHRvIGhvdyB0byBtYWtlIHRoYXQgY2xlYXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5Tb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNo b3VsZCB0aGlzIGJlIHVwIGluIHRoZSBpbnRyb2R1Y3RvcnkgdGV4dCwgc29tZXdoZXJlIGVsc2Us IG9yIGhhdmUgaXRzIG93biBzZWN0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSdt IHN0YXJ0aW5nIHRvIHRoaW5rIGNyZWRlbnRpYWwgbWFuYWdlbWVudCBpcyBhIGtleSBwYXJ0IG9m IHRoZSBkcmFmdC4gSXQgbWF5IGJlIHdvcnRoIGludHJvZHVjaW5nIGEgc3BlY2lmaWMgc2VjdGlv biBvdXRsaW5nIHRoZSByZWdpc3RyYXRpb24gbGlmZS1jeWNsZSwgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiB1c2FnZSwgYW5kIGNsaWVudCB0b2tlbiB1c2FnZQ0KIGFuZCBib290c3RyYXBwaW5n LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBC MDUwIj5JIHRoaW5rIHRoYXQgYWRkaW5nIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHdvdWxkIGJlIGZp bmUsIGFzIGl0IGNvdWxkIGhlbHAgZGV2ZWxvcGVycyB1bmRlcnN0YW5kIHRoZSB3b3JrZmxvdyBv ZiByZWdpc3RlcmluZywgdXNpbmcsIGFuZCB1cGRhdGluZyByZWdpc3RlcmVkIGNsaWVudHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ib3cgZG9lcyBhIGNsaWVu dCBhdXRoZW50aWNhdGUgdGhlIGZpcnN0IHRpbWUgYW5kIHN1YnNlcXVlbnQgdGltZXMgdG8gdGhl IHJlZ2lzdHJhdGlvbiBzZXJ2aWNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBpcyBhIHNlcGFyYXRlIHF1ZXN0aW9uIGFsbCB0b2dl dGhlciwgYXMgaXQgZG9lcyBub3QgaW52b2x2ZSB0aGUgY2xpZW50X3NlY3JldCBvciBjbGllbnRf aWQgYXQgYWxsLiBSYXRoZXIsIHRoZSBmaXJzdCB0aW1lIHRoZSBjbGllbnQgc2hvd3MgdXAgdG8g dGhlIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlLCBpdCBtYXkgZWl0aGVyOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyAtIE5vdCBhdXRoZW50aWNhdGUgYXQgYWxsICh0aGlzIGlzIHRoZSB0cnVlIHB1 YmxpYywgb3BlbiByZWdpc3RyYXRpb24sIGFuZCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHNlcnZl cnMgZG8gdGhpcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDstIEF1dGhlbnRpY2F0ZSB1c2lu ZyBhbiBPQXV0aCAyLjAgdG9rZW4gKHdoaWNoIEFUTSBtZWFucyBhIGJlYXJlciB0b2tlbikuIEhv dyB0aGUgY2xpZW50IGdldHMgdGhhdCBiZWFyZXIgdG9rZW4gYW5kIHdoYXQgdGhlIGJlYXJlciB0 b2tlbiBtZWFucyB0byB0aGUgQVMgYmV5b25kICZxdW90O3RoaXMgY2xpZW50IGlzIGF1dGhvcml6 ZWQgdG8gcmVnaXN0ZXImcXVvdDsgaXMgb3V0IG9mDQogc2NvcGUgZm9yIHRoZSBzcGVjLCBieSBk ZXNpZ24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U3Vi c2VxdWVudCB0aW1lcyB0aGF0IHRoZSBzYW1lIHJlZ2lzdGVyZWQgY2xpZW50IChieSB3aGljaCB3 ZSBtZWFuIHRoZSBzYW1lIGluc3RhbmNlIG9mIGEgY2xpZW50IHdpdGggYSBwYXJ0aWN1bGFyIGNs aWVudF9pZCkgc2hvd3MgdXAgYXQgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCAoYWN0dWFsbHks IHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludCksDQogaXQgdXNlcyBpdHMgUmVnaXN0 cmF0aW9uIEFjY2VzcyBUb2tlbiB0aGF0IGl0IHdhcyBpc3N1ZWQgb24gaW5pdGlhbCByZWdpc3Ry YXRpb24uIFRoaXMgaXMgYW4gT0F1dGggMi4wIEJlYXJlciB0b2tlbiB0aGF0IGlzIHVuaXF1ZSB0 byB0aGUgY2xpZW50IGluc3RhbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvbWV0aGluZyBsaWtlIHRoaXMg c2hvdWxkIGJlIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T0ssIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBy ZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGNhbiBiZSBleHBhbmRlZCwgYnV0IEkgdGhpbmsgdGhh dCB0aGUgcmVzdCBvZiBpdCBpcyBhbHJlYWR5IGluIHRoZXJlIGluIMKnMy4gSSdkIHdlbGNvbWUg c3VnZ2VzdGlvbnMgb24gd2hpY2ggYml0cyBvZiB0aGlzIGNvdWxkIGJlIG1hZGUgY2xlYXJlci48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5TZWUgdGhlIGRpc2N1c3Npb24g b24gd2hhdCB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBpcyBpbiB0aGUgdGhyZWFkIOKA nENsaWVudCBDcmVkZW50aWFsIEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9r ZW4gLSBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMTDigJ0uJm5ic3A7DQogSSB3aWxsIHdvcmsg d2l0aCBKdXN0aW4gdG8gYXBwbHkgdGhlc2UgY2xhcmlmaWNhdGlvbnMgdG8gdGhlIHNwZWNpZmlj YXRpb24uJm5ic3A7IFRoaXMgbWF5IGdvIGludG8gdGhlIHByb3Bvc2VkIGNyZWRlbnRpYWwgbWFu YWdlbWVudCBvdmVydmlldyBzZWN0aW9uIGRpc2N1c3NlZCBhYm92ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjMuICZuYnNwO0hvdyBpcyB2ZXJzaW9uaW5n IG9mIGNsaWVudHMgbWFuYWdlZD8gU2hvdWxkIGVhY2ggbmV3IHZlcnNpb24gb2YgYSBjbGllbnQg cmVxdWlyZSBhIGNoYW5nZSBpbiBjbGllbnQgcmVnaXN0cmF0aW9uIGluY2x1ZGluZyBwb3NzaWJs eSBjaGFuZ2luZyBjbGllbnRfaWQgYW5kIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWw/IEkgZG9u J3QgaGF2ZSBhIHN0cm9uZyBmZWVsaW5nLA0KIGJ1dCBpdCBpcyBzb21ldGhpbmcgdGhhdCBpbXBs ZW1lbnRvcnMgc2hvdWxkIGNvbnNpZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBpcyB1cCB0byB0aGUg QVMsIHJlYWxseSwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnkgZ2xvYmFsIHBvbGljeSB3b3Vs ZCBldmVyIGZseSBoZXJlLiBFc3BlY2lhbGx5IGlmIHlvdSBjb25zaWRlciB0aGF0IHRoZSBlbnRp cmUgbm90aW9uIG9mICZxdW90O3ZlcnNpb24mcXVvdDsgaXMgbW9yZSBmbHVpZCB0aGVzZSBkYXlz IHRoYW4gaXQgZXZlciBoYXMgYmVlbi4gSSB3b3VsZG4ndA0KIG1pbmQgYWRkaW5nIGEgZGlzY3Vz c2lvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaWYgaXQgbWVyaXRzIG1lbnRpb25p bmcgdGhvdWdoLCBzbyB0aGF0IHdlIGNhbiBoZWxwIGJvdGggY2xpZW50IGRldmVsb3BlcnMgYW5k IHNlcnZlciBkZXZlbG9wZXJzIGluc3RpdHV0ZSByZWFzb25hYmx5IGdvb2QgcG9saWN5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JIGd1ZXNzIHRoZSBpc3N1ZSBpcyB0aGF0IHdoZW4gYSBjbGllbnQgdXBncmFkZXMgaXQgbWF5 IGhhdmUgYWNjZXNzIHRvIHRoZSBvbGQgY3JlZGVudGlhbHMuIFdoYXQgaXMgdGhlIGludGVudCB0 aGVuIG9mIHJlZ2lzdHJhdGlvbi4gJm5ic3A7U2luY2UgeW91IGhhdmUgYW4gdXBkYXRlIGFyZSBj bGllbnRzIGV4cGVjdGVkIHRvIHVwZGF0ZSAvcmUtcmVnaXN0ZXIgb3Igbm90Pw0KICZuYnNwO0kn bSBub3Qgc3VyZSB0aGlzIGlzIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBidXQgbW9yZSBwYXJ0 IG9mIHRoZSB3aG9sZSBjaGFuZ2UgbWFuYWdlbWVudCBmdW5jdGlvbiBkeW5hbWljIHJlZ2lzdHJh dGlvbiBzdXBwb3J0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SWYgeW91ciB1cGdyYWRlZCB2ZXJzaW9uIG9mIHRoZSBjbGll bnQgc3RpbGwgaGFzIGFjY2VzcyB0byBpdHMgb2xkIGNyZWRlbnRpYWxzLCB3aHkgd291bGRuJ3Qg aXQganVzdCB1c2UgdGhvc2U/IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIGZvciBmb3JjaW5nIGEgcmUt cmVnaXN0cmF0aW9uLiBOb3IgZG8gSSBzZWUgYW55IHdheSB0aGF0IGFuIEFTIHdvdWxkIGV2ZW4g YmUgYWJsZQ0KIHRvIHRlbGwgdGhhdCBhIGNsaWVudCBoYWQgYmVlbiB1cGdyYWRlZC4gQW4gdXBn cmFkZWQgY2xpZW50IGFsd2F5cyBoYXMgdGhlICpvcHRpb24qIG9mIHJlLXJlZ2lzdGVyaW5nIGl0 c2VsZiBhbmQgZ2V0dGluZyBhIG5ldyBjbGllbnRfaWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsgdGhlIGNvbmNlcm4gaGVyZSBpcyB0aGF0IHJvdGF0 aW9uIG9mIGNsaWVudCBjcmVkZW50aWFsIGlzIG5vdCBzb21ldGhpbmcgZGlzY3Vzc2VkIGJlZm9y ZS4gQmVmb3JlIHdlIHB1dCBpdCBpbiB0aGUgc3BlYyB3ZSBzaG91bGQgY29uc2lkZXIgdGhlIHJl YXNvbnMgZm9yIGRvaW5nIGl0IGFuZCB3aGF0IHByb2JsZW1zIGl0IHNvbHZlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRoaW5rIHRoaXMgbWF5IGJl IGp1c3QgYSBjYXNlIG9mIGxldHRpbmcgcGVvcGxlIGV4Y2hhbmdlIGNyZWRlbnRpYWxzIGZvciB3 aGF0ZXZlciByZWFzb24gdGhleSBmZWVsIGlzIGFwcHJvcHJpYXRlLiAmbmJzcDtUaGUgdmVyc2lv biB1cGdyYWRlIHRoaW5nIHN1Z2dlc3RzIHRoYXQgd2hlbiBhIGNsaWVudCBpcyB1cGdyYWRlZCBp dCBzaG91bGQgZ28gdG8gdGhlIHJlZ2lzdHJhdGlvbg0KIHNlcnZlciB0byAmcXVvdDtyZS1yZWdp c3RlciZxdW90Oy4gJm5ic3A7RGVwZW5kaW5nIG9uIHRoZSBwb2xpY3kgb2YgdGhlIHNlcnZlciwg aXQgbWF5IChvciBtYXkgbm90KSByZWNlaXZlIGEgbmV3IGNsaWVudF9pZCBhbmQvb3IgbmV3IGNy ZWRlbnRpYWwuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPk9uZSBvZiB0aGUgYmVzdCBiZW5lZml0cyBJIGNhbiB0aGluayBvZiBpcyBpZiB5b3Ug ZGlzY292ZXIgYSB2ZXJzaW9uIG9mIGEgY2xpZW50IGhhcyBhIHByb2JsZW0sIGJlaW5nIGFibGUg dG8gc2VsZWN0IGEgZ3JvdXAgb2YgY2xpZW50cyBieSBzb2Z0d2FyZSBhbmQgdmVyc2lvbiBpcyBp bXBvcnRhbnQuIFRodXMgaWYgY2xpZW50X2lkIGRvZXNuJ3QgdHJhY2UgdG8gYQ0KIHBhcnRpY3Vs YXIgc29mdHdhcmUgYW5kIHZlcnNpb24sIHRoYXQgbWFrZXMgaXQgaGFyZCB0byBkby4gJm5ic3A7 SSAmbmJzcDt0aGluayB5b3UgdGFsa2VkIGFib3V0IHRoaXMgYXMgYW4gaXNzdWUgZm9yIEJsdWUg QnV0dG9uJiM0Mzs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5BZ2Fpbiwg UkZDIDY3NDkgZGVmaW5lcyBubyBjbGllbnQgaW5zdGFuY2VzIG9yIGdyb3VwcyBvZiBjbGllbnRz LCB0aGVyZWZvcmUgSSBiZWxpZXZlIHRoYXQgaXTigJlzIGluYXBwcm9wcmlhdGUgdG8gZG8gc28g aGVyZS4mbmJzcDsgV2UgZG9u4oCZdCBuZWVkIHRvIGJvaWwgdGhlIG9jZWFuLiZuYnNwOw0KIElm IGEgbmV3IGNoYXJ0ZXIgaXRlbSBpcyBhcHByb3ZlZCB0byBkbyB3b3JrIG9uIGNsaWVudCBpbnN0 YW5jZXMgYW5kIHByb3RvY29sIGVsZW1lbnRzIHRvIHVzZSBhbmQgZXhwcmVzcyB0aGVtLCB0aGF0 4oCZcyB0aGUgdGltZSBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgdGhhdCBwb3Nz aWJpbGl0eSDigJMgbm90IGFzIHBhcnQgb2YgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj40LiAmbmJzcDtXaGF0IGlzIHRoZSByZWdpc3Ry YXRpb24gYWNjZXNzIHRva2VuPyBXaHkgaXMgaXMgdXNlZD8gV2hhdCBpcyBpdHMgbGlmZS1jeWNs ZT8gJm5ic3A7V2hlbiBpcyBpdCBpc3N1ZWQsIHdoZW4gaXMgaXQgY2hhbmdlZD8gV2hlbiBpcyBp dCBkZWxldGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+U2VlIHRoZSByZXNwb25zZSBhYm92ZSBhYm92ZSBhbmQgdGhlIGRlZmluaXRpb24g aW4gwqcxLjI6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJlZ2lzdHJhdGlvbiBBY2Nlc3Mg VG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVkIGJ5IHRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50IHdoaWNo IGlzIHVzZWQgYnkgdGhlIENsaWVudCB0byBhdXRoZW50aWNhdGUgaXRzZWxmIGR1cmluZyByZWFk LCB1cGRhdGUsIGFuZCBkZWxldGUNCiBvcGVyYXRpb25zLiBUaGlzIHRva2VuIGlzIGFzc29jaWF0 ZWQgd2l0aCBhIHBhcnRpY3VsYXIgQ2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPklmIHRoaXMgY2FuIGJlIGNsYXJpZmllZCwgSSB3ZWxjb21lIHRleHQgc3VnZ2VzdGlv bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgbGF0dGVyIHBhcnQgb2YgMS4yIGRpZG4ndCBz ZWVtIGxpa2UgdGVybWlub2xvZ3kgYnV0IHJhdGhlciBhcmNoaXRlY3R1cmUgb3IgcGFydCBvZiB0 aGUgaW50cm9kdWN0aW9uIHRoYXQgZGVzY3JpYmVzIHdoYXQgdGhlIHNwZWMgZG9lcy4gVGhlIHRo aXJkIHBvaW50IGRvZXNuJ3Qgc2VlbSB0byBmaXQgd2l0aCB0aGUgb3RoZXIgdHdvIGV4Y2VwdCB0 byBzYXkgdGhhdA0KIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBlbmRwb2ludHMgdXNlIHRoZWly IG93biBhY2Nlc3MgdG9rZW5zIGNhbGxlZCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2Vucy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzO29ycGhh bnM6IDI7dGV4dC1hbGlnbjotd2Via2l0LWF1dG87d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkNsaWVudCBSZWdpc3RyYXRpb24g RW5kcG9pbnQ6IFRoZSBPQXV0aCAyLjAgRW5kcG9pbnQgdGhyb3VnaCB3aGljaDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYSBDbGllbnQgY2FuIHJlcXVlc3QgbmV3IHJlZ2lzdHJhdGlvbi4m bmJzcDsgVGhlIG1lYW5zIG9mIHRoZSBDbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG9idGFpbmluZyB0aGUgVVJMIGZvciB0aGlzIGVuZHBvaW50IGFyZSBvdXQgb2Ygc2NvcGUgZm9y IHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm bmJzcDsgbyZuYnNwOyBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIu MCBFbmRwb2ludCB0aHJvdWdoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGljaCBhIHNw ZWNpZmljIENsaWVudCBjYW4gbWFuYWdlIGl0cyByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24sPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlZCBieSB0aGUgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgdG8gdGhlIENsaWVudC4mbmJzcDsgVGhpcyBVUkwgZm9yPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGlzIGVuZHBvaW50IGlzIGNvbW11bmljYXRlZCB0byB0aGUgY2xpZW50IGJ5 IHRoZSBBdXRob3JpemF0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2ZXIgaW4g dGhlIENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFJl Z2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVk IGJ5IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg dGhyb3VnaCB0aGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd2hpY2ggaXMgdXNlZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0ZSBp dHNlbGYgZHVyaW5nIHJlYWQsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1cGRhdGUsIGFu ZCBkZWxldGUgb3BlcmF0aW9ucy4mbmJzcDsgVGhpcyB0b2tlbiBpcyBhc3NvY2lhdGVkIHdpdGgg YTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFydGljdWxhciBDbGllbnQuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlRoaXMgc2VjdGlvbiBpcyBtZWFudCB0byBqdXN0IGludHJvZHVjZSB0aGUgbmV3IHRl cm1zIHRoYXQgYXJlIHRoZW4gZXhwbGFpbmVkIGluIGdyZWF0ZXIgZGV0YWlsIHRocm91Z2hvdXQg dGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBZZXMsIGl0J3MgYSBiaXQgYXJjaGl0ZWN0dXJlLCBi dXQgb25seSBpbiB0aGUgc2Vuc2UgdGhhdCB5b3UgbmVlZCB0byBkZWZpbmUgdGhlDQogdGVybXMg dGhhdCBtYWtlIHVwIHlvdXIgYXJjaGl0ZWN0dXJlLiBIb3cgd291bGQgeW91IHN1Z2dlc3QgdGhh dCBpdCBjaGFuZ2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+UHJvYmFibHkgdGhpcyBpcyBtb3JlIGEgbWF0dGVyIG9mIHN0eWxlLiAmbmJz cDtCdXQsIHdoYXQgaGFwcGVuZWQgZm9yIG1lIGlzIEkgbmF0dXJhbGx5IHNraXBwZWQgdGhlIHRl cm1pbm9sb2d5IHNlY3Rpb24sIGFzIEkgd2Fzbid0IGV4cGVjdGluZyBwcm90b2NvbCBjb21wb25l bnRzIHRvIGJlIHRoZXJlLiAmbmJzcDsmcXVvdDt0ZXJtaW5vbG9neSZxdW90OyBpcyBzb21ldGhp bmcgSSB0aGluayBwZW9wbGUNCiB0ZW5kIHRvIHVzZSBhcyBhIGRpY3Rpb25hcnkgcmF0aGVyIHRo YW4gYXMgcHJvdG9jb2wgY29tcG9uZW50IGRlc2NyaXB0aW9uLiAmbmJzcDtNYXliZSB0aGUgY2hh aXJzIGNhbiBhZHZpc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SWYgd2UgZGlzdGluZ3Vpc2ggYmV0d2VlbiBmaXJz dCB0aW1lIHJlZ2lzdHJhdGlvbiBvZiBhIHBhcnRpY3VsYXIgY2xpZW50IHNvZnR3YXJlIHBhY2th Z2UsIGl0IGlzIHBvc3NpYmxlIHRoYXQgc29tZXRoaW5ncyBsaWtlIGF1dGhlbnRpY2F0aW9uIG1l dGhvZCBjYW4gYmUgbmVnb3RpYXRlIGluIG9yIG91dC1vZi1iYW5kIGF0IHRoYXQgdGltZS4gU3Vi c2VxdWVudCByZWdpc3RyYXRpb25zDQogc2hvdWxkIG9ubHkgaGF2ZSBwYXJhbWV0ZXJzIGZvciBp dGVtcyB0aGF0IGNvdWxkIGNoYW5nZSBwZXIgZGVwbG95bWVudCAobGlrZSB0b3NfdXJpKS4gJm5i c3A7SSB0aGluayB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCBpcyBvbmUgdGhpbmcgdGhhdCBz aG91bGQgbm90IGJlIG5lZ290aWF0ZWQgcGVyIGluc3RhbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldoZW4g c3Vic2VxdWVudCBpbnN0YW5jZXMgcmVnaXN0ZXIsIEkgaGF2ZSB0byBhc2sgdGhlIHF1ZXN0aW9u LCBmb3IgZXhhbXBsZSB3aGVuIHdvdWxkIHRoaW5ncyBsaWtlICZxdW90O3Rva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kJnF1b3Q7IGJlIG5lZ290aWF0ZWQgb3IgYmUgZGlmZmVyZW50IGZvciB0aGUg c2FtZSBjbGllbnQgc29mdHdhcmU/IFNob3VsZCBub3QgYWxsIGluc3RhbmNlcw0KIHVzZSB0aGUg c2FtZSBhdXRoZW50aWNhdGlvbiBtZXRob2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkknbSBjb25mdXNlZCBieSB0aGlzIC0tIGFzIGZhciBhcyB0aGUgZHluYW1pYyByZWdp c3RyYXRpb24gc3BlYyBpcyBjb25jZXJuZWQsIGFsbCBpbnN0YW5jZXMgYXJlIHNlcGFyYXRlIGZy b20gZWFjaCBvdGhlci4gQWxsIHBhcmFtZXRlcnMgY2hhbmdlIHBlciBpbnN0YW5jZS4gQW5kIGlu c3RhbmNlLCB5b3Ugc2hvdWxkIGtlZXAgaW4gbWluZCwgaXMgZGVmaW5lZCBhcw0KIGFueSBvbmUg Y29weSBvZiB0aGUgY2xpZW50IGNvZGUgY29ubmVjdGluZyB0byBhbnkgbmV3IGF1dGhvcml6YXRp b24gc2VydmVyLiBUaGF0IHBhaXJpbmcgY3JlYXRlcyB0aGUgY2xpZW50X2lkLCBhbmQgdGhlcmVm b3JlIHRoZSBpbnN0YW5jZSwgYW5kIHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0 b2tlbiwgYW5kIHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGl0c2VsZiBhdCBhIGNvbmNlcHR1 YWwgbGV2ZWwuIFNvIHRoZXJlIGlzDQogbm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNlIGZv ciBhIGNsaWVudCB0byBhc2sgZm9yIGEgcGFydGljdWxhciB0b2tlbl9lbmRwb2ludF9hdXRoX21l dGhvZC4gV2hlcmUgZWxzZSB3b3VsZCB0aGUgQVMgZmluZCBvdXQgYWJvdXQgaXQ/DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPldlIHN0aWxsIGRpc2FncmVlIG9uIHRoaXMuIEl0IGlzIG15IGFzc2VydGlvbiB0aGF0 IGNsaWVudHMgc2hvdWxkIE5FVkVSIGFzayBmb3IgYSBwYXJ0aWN1bGFyIHRva2VuIGF1dGggbWV0 aG9kLiBTaW5jZSBpdCBpcyB0aGUgQVMgdGhhdCBpcyBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50 LCB0aGVuIGl0IGlzIHRoZSBBUydzIHJpZ2h0IHRvIHNldCB0aGUgYXV0aGVudGljYXRpb24NCiBw b2xpY3kuICZuYnNwO1RoZSByb2xlIG9mIGR5bmFtaWMgcmVnIGVuZHBvaW50IGlzIHRvIGluZm9y bSB0aGUgY2xpZW50IHdoYXQgaXQgbXVzdCBkby4gJm5ic3A7TXkgYXNzdW1wdGlvbiBpcyB0aGF0 IGR1cmluZyB0aGUgZmlyc3QgdGltZSBhIHBpZWNlIG9mIHNvZnR3YXJlIGlzIHJlZ2lzdGVyZWQg KHRoZSBmaXJzdCBpbnN0YW5jZSksIHRoZXJlIGNvdWxkIGJlIHNvbWUgT09CIGRpc2N1c3Npb24g YnkgYW4gYWRtaW5pc3RyYXRvciB0byBhcHByb3ZlIHRoZSBwYXJ0aWN1bGFyDQogYXV0aGVudGlj YXRpb24gdHlwZSBmb3IgdGhlIEFTIGluIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgaGF2ZW4ndCBoZWFyZCBhIHJlYXNvbiBqdXN0aWZ5 aW5nIHRoaXMgcGFyYW1ldGVyIG90aGVyIHRoZW4gJnF1b3Q7aXQgaXMgbmVlZGVkJnF1b3Q7LiAm bmJzcDtXaHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHJvbGUgb2YgdGhlIGR5bmFtaWMgcmVnaXN0cmF0 aW9uIHByb3RvY29sIGlzIHR3b2ZvbGQ6IGhhbGYgb2YgdGhhdCBpcyB0aGUgc2VydmVyIGluZm9y bWluZyB0aGUgY2xpZW50IHdoYXQgaXQgbXVzdCBkby4gQnV0IHRoZSBvdGhlciBoYWxmIGlzIHRo ZSBjbGllbnQgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIgd2hhdCBpdCAqY2FuKiBkbywgb3Igd2hhdCBp dCAqd2FudHMqDQogdG8gZG8uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+QW5kIGFnYWluLCB0aGVyZSdzIG5vIHdheSB0byBkaXN0aW5ndWlzaCBh IGZpcnN0IGluc3RhbmNlIGZyb20gYSBzdWJzZXF1ZW50IGluc3RhbmNlIHVubGVzcyB5b3UncmUg ZG9pbmcgc29tZXRoaW5nIGluIGFkZGl0aW9uLiBOb3RoaW5nIGlzIHN0b3BwaW5nIHRoZSBzYW1l IGFwcGxpY2F0aW9uIGZyb20gcmVnaXN0ZXJpbmcgYSBuZXcgaW5zdGFuY2Ugb2YgaXRzZWxmDQog Zm9yIGV2ZXJ5IHNpbmdsZSB1c2VyIG9yIGV2ZXJ5IHNpbmdsZSB0b2tlbiB0aGF0IGl0IHdhbnRz IHRvIGdldCBhY2Nlc3MgZm9yLiBUaGF0J3MgY29tcGxpY2F0ZWQgYW5kIHdhc3RlZnVsIGFuZCBu b3QgYSBncmVhdCBpZGVhLCBzdXJlLCBidXQgJm5ic3A7dGhlcmUncyBubyB1c2VmdWwgd2F5IHRv IHByZXZlbnQgdGhhdCBraW5kIG9mIGJlaGF2aW9yIGlmIHlvdSBhbHNvIHdhbnQgb3BlbiByZWdp c3RyYXRpb24gb2YgY2xpZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRoaW5rIHdlJ3ZlIGRpc2N1c3NlZCBob3cgcmVj b2duaXppbmcgc3Vic2VxdWVudCBpbnN0YW5jZXMgaXMgZWFzaWx5IGRvbmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXMgSSBtZW50aW9uZWQgaW4gdGhl IG90aGVyIHRocmVhZCwgaWYgYSBkZXZlbG9wZXIgY2hvb3NlcyB0byBsaW1pdCB0aGUgY2FwYWJp bGl0aWVzIG9mIHRoZSBjbGllbnQgaXQgbXVzdCBkbyBzbyBieSBsb29raW5nIHRvIHRoZSBkZXZl bG9wZXIgb3Igc3RhbmRhcmQgYmVoaW5kIHRoZSBBUEkuICZuYnNwO090aGVyd2lzZSB0aGV5IGFy ZSB0YWtpbmcgdGhlIGNoYW5jZS4gJm5ic3A7VGhlcmUncw0KIG5vIHdheSBhIGRldmVsb3BlciBj YW4gcXVlcnkgYWxsIHRoZSBwb3RlbnRpYWwgZGVwbG95ZXJzIHRvIGFzayB3aGF0IGF1dGhuIHR5 cGVzIHdpbGwgeW91IHVzZS4gQXMgSSBzYWlkLCB0aGUgbmV0IGVmZmVjdCBpbiB0aGUgYWJzZW5j ZSBvZiBhbiBBUEkgc3RhbmRhcmQgZGljdGF0aW5nIHdoYXQgc2hvdWxkIGJlIHN1cHBvcnRlZCwg dGhlIGRldmVsb3BlciB3aWxsIGhhdmUgdG8gaW1wbGVtZW50IGFsbCBtZXRob2RzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk15IHBvaW50IGhlcmUgaXMg dGhhdCBub25lIG9mIHRoaXMgaXMgaGVscGVkIGJ5IHRoZSBjbGllbnQgYXBwIHNheWluZyB3aGF0 IGl0IHN1cHBvcnRzLiBBIGRldmVsb3BlciB3aG8gdGFrZXMgdGhlIHJvdXRlIG9mIGxpbWl0aW5n IGltcGxlbWVudGF0aW9uIHRha2VzIHRoZSBjaGFuY2UgdGhhdCB0aGUgc2VydmVyIHdpbGwgbm90 IGFjY2VwdC4gJm5ic3A7U28gd2h5IG5lZ290aWF0ZQ0KIHdpdGhpbiByZWdpc3RyYXRpb24/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5BbmQgdGhlcmUncyBubyB3YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9yIHRoZSBzZXJ2 ZXIgdG8gdGVsbCB0aGUgY2xpZW50IHdoaWNoIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIHRv IHVzZS4gQWxsIGluc3RhbmNlcyB3aWxsIHByb2JhYmx5IGFzayBmb3IgdGhlIHNhbWUgdG9rZW5f ZW5kcG9pbnRfYXV0aF9tZXRob2QgZnJvbSBhbGwgYXV0aCBzZXJ2ZXJzDQogdGhleSB0YWxrIHRv LCByaWdodD8gQW5kIGVhY2ggQVMgd2lsbCB0ZWxsIGVhY2ggaW5zdGFuY2UgdGhhdCByZWdpc3Rl cnMgd2l0aCBpdCB0byB1c2UgYSBwYXJ0aWN1bGFyIGF1dGggbWV0aG9kLiBUaGVyZSBpcyBubyB3 YXkgdG8gdGllIHRvZ2V0aGVyIGRpZmZlcmVudCBpbnN0YW5jZXMgYWNyb3NzIChvciB3aXRoaW4p IGF1dGggc2VydmVycyB3aXRob3V0IHNwZWNpZnlpbmcgYSBzaWduaWZpY2FudCBhbW91bnQgb2Yg b3RoZXIgbWFjaGluZXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1s ZWZ0Oi41aW4iPg0KV2hpY2ggaXMgbm90IHRvIHNheSB0aGF0IGl0J3Mgbm90IHVzZWZ1bCBpbiBz b21lIGNpcmN1bXN0YW5jZXMgdG8gdGllIHRvZ2V0aGVyIGRpZmZlcmVudCBpbnN0YW5jZXMgb2Yg dGhlIHNhbWUgY29kZSBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0aCBzZXJ2ZXJzLiBUaGlzIGlzIHdo eSwgd2l0aCBCbHVlIEJ1dHRvbiYjNDM7LCB3ZSBzcGVjaWZpZWQgYSBzcGVjaWZpYyB0b2tlbiBm b3JtYXQgZm9yIHRoZSBpbml0aWFsIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBjbGllbnRzDQogdXNl IHRvIGNhbGwgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCB0aGUgZmlyc3QgdGltZSwgJm5ic3A7 YXMgd2VsbCBhcyBhIGRpc2NvdmVyeSBwcm90b2NvbCBhZ2FpbnN0IGEgY2VudHJhbGl6ZWQgc2Vy dmVyIHRoYXQgaGFuZGxlcyBwcmUtcmVnaXN0cmF0aW9uLiBBbGwgb2YgdGhpcyBtYWNoaW5lcnkg aXMsIGluIG15IG9waW5pb24sIGEgc3R1cGVuZG91cyBvdmVya2lsbCBmb3IgdGhlIGdlbmVyYWwg Y2FzZSwgdGhvdWdoIGlmIHNvbWUgZm9sa3MgZmluZA0KIHVzZSBmb3IgaXQgb3V0c2lkZSBvZiBC QiYjNDM7IHRoZW4gaXQnZCBiZSBhIGdvb2QgdGhpbmcgdG8gYWJzdHJhY3Qgb3V0IGFuZCBtYWtl IGl0cyBvd24gc3BlYyB0aGF0IGV4dGVuZHMgdGhlIER5biBSZWcgc3BlYyBpbiBhIGZ1bGx5IGNv bXBhdGlibGUgd2F5LiBGdXJ0aGVybW9yZSwgZXZlbiBpbiBCbHVlIEJ1dHRvbiYjNDM7IHdlIHNw ZWNpZnkgdGhhdCBhbGwgYXV0aCBzZXJ2ZXJzIE1VU1QgYWxzbyBhY2NlcHQgb3BlbiByZWdpc3Ry YXRpb24sIHdpdGhvdXQNCiBhbiBpbml0aWFsIGFjY2VzcyB0b2tlbiwgd2hlcmUgdGhlIGNsaWVu dCBzaW1wbHkgc2hvd3MgdXAgYW5kIHNheXMgJnF1b3Q7aGV5LCBoZXJlIGFyZSBteSBwYXJhbWV0 ZXJzLiZxdW90OyBUaGUgYXV0aCBzZXJ2ZXIgaGFzIG5vIHdheSB0byBrbm93IGluIHRoaXMgY2Fz ZSBhbnkga2luZCBvZiBvdXQtb2YtYmFuZCBuZWdvdGlhdGlvbiBmb3IgZGlmZmVyZW50IHRoaW5n cy4gSW4gQkImIzQzOyB3ZSBhcmUgd3JpdGluZyB2ZXJ5IHNwZWNpZmljIHBvbGljeSBndWlkZWxp bmVzDQogYWJvdXQgaG93IHRvIHByZXNlbnQgdGhlIFVYIGFuZCB0aGluZ3MgdG8gdGhlIGVuZCB1 c2VyIGZvciBhbGwgb2YgdGhlc2UgZGlmZmVyZW50IGNhc2VzLiBCdXQgYWdhaW4sIGFsbCBvZiB0 aGlzIGlzIHNwZWNpZmljIHRvIHRoZSBCQiYjNDM7IHVzZSBjYXNlLCBhbmQgSSBkb24ndCBzZWUg dmFsdWUgaW4gZHJhZ2dpbmcgaXQgaW4gdG8gdGhlIHJlZ2lzdHJhdGlvbiBzcGVjIG9uIGl0cyBv d24uIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBmYXIgdG9vIGxpbWl0aW5nLjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+U2VlIG15 IHByZXZpb3VzIGNvbW1lbnRzIG9uIGRpZmZlcmVudGlhdGluZyBjbGllbnQgaW5zdGFuY2VzIGJl aW5nIG91dCBvZiBzY29wZSB3aXRob3V0IHJlY2hhcnRlcmluZyB0byBkbyB0aGlzIG5ldyB3b3Jr IGFuZCBvbiB3aGF0IHRoZSByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuDQogaXMuJm5ic3A7IElu IHNob3J0LCB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBpcyBhbiBSRkMgNjc1MCBiZWFy ZXIgdG9rZW4gaXNzdWVkIHRvIHRoZSBwYXJ0eSByZWdpc3RlcmluZyB0aGUgY2xpZW50LCBlbmFi bGluZyBpdCB0byBzdWJzZXF1ZW50bHkgcmV0cmlldmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNs aWVudCByZWdpc3RyYXRpb24gYW5kIHRvIHBvdGVudGlhbGx5IHVwZGF0ZSB0aGUgcmVnaXN0cmF0 aW9uIGluZm9ybWF0aW9uIGZvciB0aGF0DQogcmVnaXN0ZXJlZCBjbGllbnQuJm5ic3A7IEFnYWlu LCBJ4oCZbGwgd29yayB3aXRoIEp1c3RpbiB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIGlzIGFzIGNs ZWFyIGFzIHBvc3NpYmxlIGluIHRoZSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RmluYWxseSwgdGhlcmUgc2VlbXMgdG8gYmUgYW4g aW5jb25zaXN0ZW50IHN0eWxlIGFwcHJvYWNoIHdpdGgmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTAwLnR4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzQ0MDA4ODtiYWNrZ3JvdW5kOndo aXRlIj5kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWc8L3NwYW4+PC9hPiZuYnNwO3do aWNoDQogdXNlcyBFVGFncy4gU2hvdWxkIHRoaXMgZHJhZnQgZG8gc28gYXMgd2VsbD88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYXQncyBh biBpbmRpdmlkdWFsIHN1Ym1pc3Npb24sIG5vdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIE5vYm9k eSBoYXMsIHVudGlsIG5vdywgZXZlbiBtZW50aW9uZWQgdGhlIHVzZSBvZiBFVGFncyBoZXJlLiBV TUEgKHdoZXJlIHRoZSByZXNvdXJjZSByZWdpc3RyYXRpb24gZHJhZnQgY29tZXMgZnJvbSkgdXNl cyBFVGFncywgaGVuY2UgdGhlaXIgaW5jbHVzaW9uIHRoZXJlLg0KIEkgcGVyc29uYWxseSBkb24n dCBzZWUgdGhlaXIgdXRpbGl0eSBoZXJlLCB0aG91Z2gsIGFuZCBJIHdvdWxkbid0IHdhbnQgdG8g aW5jbHVkZSBhIHdob2xseSBuZXcgbWVjaGFuaXNtIHRoaXMgbGF0ZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVzLiBUaG9t YXMnIGRyYWZ0IGlzIG5vdCBhIFdHIGRvY3VtZW50LiBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gaGUg ZG9lc24ndCBoYXZlIGEgcG9pbnQuIEl0J3Mgd29ydGggZGlzY3Vzc2luZy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbmUgY291bGQgYXJndWUg dGhhdCB0aGUgcG9pbnQgb2YgYW4gRVRhZyBpcyB0aGF0IGl0IGlzIHVzZWZ1bCBmb3IgY2hhbmdl IGRldGVjdGlvbiB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSB3cml0ZXJzIHRvIGEgcGFydGljdWxh ciByZXNvdXJjZS4gJm5ic3A7SW4gdGhlIGRlc2lnbiBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBl bmRwb2ludCwgdGhlcmUgc2hvdWxkIG9ubHkgYmUNCiBvbmUgd3JpdGVyIC0tIHRoZSBjbGllbnQu IFRoaXMgaXMgYW4gaW1wb3J0YW50IG9ic2VydmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBhcmUgb3RoZXIg bWVjaGFuaXNtcyB0aGF0IGhhbmRsZSB0aGlzIC0tIG5hbWVseSwgdGhlIHJlZ2lzdHJhdGlvbiBh Y2Nlc3MgdG9rZW4gYW5kIHRoZSBjbGllbnRfaWQuIE1hbnkgaW5zdGFuY2VzIGluY2x1ZGUgdGhl IGNsaWVudF9pZCBpbiBzb21lIGZvcm0gaW4gdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGVuZHBv aW50J3MgVVJMIGZvciBzYW5pdHkgY2hlY2tpbmcsDQogYXMgZGVzY3JpYmVkIGluIMKnNC4xLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPklmIGV2ZXJ5b25lIGFncmVlcywgSSdtIGluIGFncmVlbWVudC4gQnV0IGl0IHdpbGwgbGlr ZWx5IG1lYW4gY2hhbmdlcyBmb3IgdGhlIHJlc291cmNlIHJlZyBkcmFmdCBpZiBhZG9wdGVkLjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkVUYWdzIHNlZW0gbGlrZSBhbiB1 bm5lY2Vzc2FyeSBhZGRpdGlvbiAoYW5kIHBvdGVudGlhbCBjb21wbGljYXRpb24pIHRvIHRoZSBz cGVjaWZpY2F0aW9uLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSB3b3JraW5nIGZpbmUgYXMtaXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PGk+U3Bl Y2lmaWMgaXRlbXM6PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLS0tLS0tLS0tLS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj4mcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21l dGhvZCZxdW90OzwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5UaGVyZSBpcyBzb21lIGNvbmZ1c2lvbiBhcyB0byB3aGV0aGVyIHRoaXMgYXBwbGllcyB0 byBzZXJ2ZXIgb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAmbmJzcDtTdWdnZXN0IHJlbmFtaW5n IHBhcmFtZXRlciB0byAmcXVvdDt0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlRoaXMgaXMgdGhlIGZpcnN0IEkndmUgaGVhcmQgb2YgdGhpcyBwYXJ0aWN1bGFyIGNvbmZ1c2lv bi4gSSdtIGZpbmUgd2l0aCBlaXRoZXIgbmFtZSBidXQgYXQgdGhpcyBzdGFnZSBJIGRvbid0IHdh bnQgdG8gbWFrZSBzeW50YXggY2hhbmdlcyB3aXRob3V0IHZlcnksIHZlcnkgY29tcGVsbGluZyBy ZWFzb25zIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHF1ZXN0aW9uIHdhcyByYWlzZWQgdG8g bWUgYnkgc29tZSBuZXcgZGV2ZWxvcGVycy4gSXQgc2VlbXMgb2J2aW91cyB0byB1cyBhcyBleHBl cmllbmNlZCBPQXV0aCBwZXJzb25zLCBidXQgdG8gbmV3IGRldmVsb3BlcnMgaXQgc2VlbXMgdW5j bGVhci4gJm5ic3A7QWxzbywgbm93IHRoYXQgeW91IGFyZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRp b24gYXV0aGVudGljYXRpb24sDQogdGhlIHdob2xlIHRoaW5nIGdldHMgdmVyeSBjb25mdXNpbmcu IFNvIGl0IGlzIHVzZWZ1bCBkaXNhbWJpZ3VhdGUgYWxsIHRoZSBwYXJhbWV0ZXJzIHdoZXJlIHBv c3NpYmxlLiAmbmJzcDtUaGF0IHNhaWQsIEkgd291bGRuJ3QgbWluZCBzaG9ydGVyIG5hbWVzICht YXliZSBub3QgcXVpdGUgYXMgc2hvcnQgYXMgdGhlIEpPU0Ugc3R1ZmYgOy0pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+RmFpciBlbm91Z2gsIGJ1dCBhZ2FpbiwgSSBvbmx5IHdhbnQgdG8gZG8gc3ludGF4IGNoYW5n ZXMgaWYgdGhlIHJlc3Qgb2YgdGhlIFdHICpyZWFsbHkqIHdhbnRzIHRvLjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgYWdyZWUgd2l0aCBKdXN0aW4gaGVyZS4mbmJzcDsg SeKAmW0gZmluZSBjbGFyaWZ5aW5nIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIHBhcmFtZXRlciB0 byByZXNvbHZlIHRoZSBwb3RlbnRpYWwgYW1iaWd1aXRpZXMgdGhhdCB5b3UgY2l0ZSwgUGhpbC4m bmJzcDsgSeKAmW0gbm90IE9LIHJldmlzaW5nDQogdGhlIHN5bnRheCB3aXRob3V0IGEgY29tcGVs bGluZyByZWFzb24gdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+KiBDdXJyZW50bHksIHRoZSBBUEkgb25seSBzdXBwb3J0cyBhIHNpbmdsZSB2YWx1 ZSBpbnN0ZWFkIG9mIGFuIGFycmF5LiAmbmJzcDtJZiB0aGUgcHVycG9zZSBpcyB0byBhbGxvdyB0 aGUgY2xpZW50IHRvIGtub3cgd2hhdCBhdXRoIG1ldGhvZHMgaXQgc3VwcG9ydHMsIHRoaXMgc2hv dWxkIGJlIGFuIGFycmF5IGluZGljYXRlZCB3aGF0IG1ldGhvZHMgdGhlIGNsaWVudCBzdXBwb3J0 cw0KIC0gb3IgaXQgc2hvdWxkIG5vdCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3b3VsZCByYXRoZXIgbGlrZSB0aGlzIHRv IGJlIGFuIGFycmF5LCBwZXJzb25hbGx5LCBhbmQgYnJvdWdodCBpdCB1cCB3aXRoIHRoZSBPcGVu SUQgQ29ubmVjdCB3b3JraW5nIGdyb3VwIGFib3V0IHNpeCBtb250aHMgYWdvLiBCdXQgdGhlcmUg aXQgd2FzIGRlY2lkZWQgdGhhdCBhIHNpbmdsZSB2YWx1ZSB3YXMgc2ltcGxlciBhbmQgc3VmZmlj aWVudCBmb3IgdGhlDQogcHVycG9zZS4gVGhlIElFVEYgZHJhZnQgaGFzIGluaGVyaXRlZCB0aGlz IGRlY2lzaW9uLiBJICpiZWxpZXZlKiAodGhvdWdoIGFtIG5vdCAxMDAlIHBvc2l0aXZlKSB0aGF0 IEkgYnJvdWdodCB1cCB0aGlzIHZlcnkgaXNzdWUgaW4gdGhlIFdHIGhlcmUgYnV0IGRpZG4ndCBy ZWNlaXZlIGFueSB0cmFjdGlvbiBvbiBpdCwgc28gc2luZ2xlIGl0IHJlbWFpbnMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkg Y2FuIGdldCBiZWhpbmQgbXVsdGlwbGUgdmFsdWVzLiBJbiB0aGlzIGNhc2UsIGl0IGNoYW5nZXMg dGhlIG1lYW5pbmcgb2YgdGhlIHBhcmFtZXRlci4gSW5zdGVhZCBvZiB0aGUgY2xpZW50IGZvcmNp bmcgdGhlIHNlcnZlciB0byB1c2UgYSBwYXJ0aWN1bGFyIG1ldGhvZCwgdGhlIGNsaWVudCBpcyBp bmZvcm1pbmcgdGhlIHNlcnZlciBhYm91dCB3aGF0IG1ldGhvZHMNCiBpdCBjYW4gcGVyZm9ybS4g VGhpcyBhbGxvd3MgdGhlIHNlcnZlciB0byBhc3NpZ24gdGhlIGFwcHJvcHJpYXRlIG1ldGhvZCBi YXNlZCBvbiBpdHMgb3duIHBvbGljeS48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWxzbyBub3RlIHRoYXQgdGhpcyBmaWVs ZCwgbGlrZSBhbGwgb3RoZXJzIGluIMKnMiwgcmVwcmVzZW50cyB0d28gdGhpbmdzOiB0aGUgY2xp ZW50IHRlbGxpbmcgdGhlIHNlcnZlciAmcXVvdDtJIHdhbnQgdG8gdXNlIHRoaXMgdmFsdWUgZm9y IHRoaXMgZmllbGQmcXVvdDssIGFuZCB0aGUgc2VydmVyIHRlbGxpbmcgdGhlIGNsaWVudCAmcXVv dDt0aGlzIGlzIHRoZSB2YWx1ZSB5b3UgaGF2ZSBmb3INCiB0aGlzIGZpZWxkJnF1b3Q7LiBJdCdz IG5vdCBleGFjdGx5IGEgbmVnb3RpYXRpb24sIG1vcmUgbGlrZSBtYWtpbmcgYSBwb2xpdGUgcmVx dWVzdCB0byBhbiBhYnNvbHV0ZSBkaWN0YXRvciB3aG8gaGFzIHRoZSBsYXN0IHdvcmQgYW55d2F5 LiBCdXQgYXQgbGVhc3QgdGhpcyBkaWN0YXRvciBpcyBuaWNlIGVub3VnaCB0byB0ZWxsIHlvdSB3 aGF0IHRoZWlyIGRlY2lzaW9uIHdhcyBpbnN0ZWFkIG9mIGp1c3QgZGVjYXBpdGF0aW5nIHlvdS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBpcyB0 aGUgaGVhcnQgb2YgbXkgb2JqZWN0aW9uLiBUaGlzIGZ1enppbmVzcyBpcyBpcyBnb2luZyB0byBs ZWFkIHRvIGludGVyb3AgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBpcyBubyBmdXp6aW5lc3MgdGhhdCBJ IGNhbiBzZWUgaGVyZS4gSXQncyBwYXJhbGxlbGlzbSBiZXR3ZWVuIHdoYXQgZ29lcyBpbiB0byB0 aGUgZW5kcG9pbnQgYW5kIHdoYXQgY29tZXMgb3V0IG9mIGl0LiBUaGUgc2VtYW50aWNzIGZvciB0 aGUgcmVxdWVzdCBhbmQgdGhlIHJlc3BvbnNlIGFyZSBkaWZmZXJlbnQsIGFuZCBkaWZmZXJlbnRp YWJsZSBieSB0aGUNCiBmYWN0IHRoYXQgb25lIGlzIGEgcmVxdWVzdCBhbmQgdGhlIG90aGVyIGlz IGEgcmVzcG9uc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGludGVyLW9wIGlzc3VlIEkgd291bGQgbGlrZSB0byBwb2lu dCBvdXQgaXMgdGhhdCB0aGUgc3BlYyBkb2VzIG5vdCBjdXJyZW50bHkgc3BlY2lmeSBpZiBwYXJ0 aWN1bGFyIGlucHV0IHZhbHVlcyBhcmUgc2luZ3VsYXIgb3IgbXVsdGlwbGUuICZuYnNwO0lmIGFu IGltcGxlbWVudGVyIGFzc3VtZXMgc2luZ3VsYXIgYW5kIGNsaWVudHMgYXNzdW1lIG11bHRpcGxl LCB3ZSBoYXZlDQogaXNzdWVzLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAi PlRoZSBtdWx0aXBsZS9zaW5nbGUgZGlzY3Vzc2lvbiBhYm92ZSBnZXRzIHRvIHRoZSBoZWFydCBv ZiB3aGF0IEkgKjxiPmRvPC9iPiogYmVsaWV2ZSBpcyBhIGRlZmljaWVuY3kgaW4gdGhlIHNwZWNp ZmljYXRpb24sIGFzIGl04oCZcyBjdXJyZW50bHkgd3JpdHRlbi4mbmJzcDsgVGhlIGF1dGhvcnMs DQogbXlzZWxmIGluY2x1ZGVkLCBoYXZlIGZhaWxlZCB0byBtYWtlIGl0IDEwMCUgY2xlYXIgdGhh dCBkaXNjb3Zlcnkgb2YgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgZnVuY3Rpb25hbGl0eSBpcyBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi4mbmJzcDsgSSBzdHJvbmdseSBiZWxpZXZl IHRoYXQgd2UgbmVlZCB0byBhZGQgYSBjbGVhciBzdGF0ZW1lbnQgdG8gdGhpcyBlZmZlY3QgaW4g dGhlIGludHJvZHVjdGlvbiB0byB0aGUgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPlRoZSBwdXJw b3NlIG9mIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBpcyBm b3IgdGhlIGNsaWVudCB0byByZWdpc3RlciB3aXRoIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBh bmQgdG8gaW5mb3JtIGl0IG9mIHByb3BlcnRpZXMgb2YgdGhlDQogY2xpZW50IHRoYXQgdGhlIEFT IG1heSB3YW50L25lZWQgdG8gYmUgYXdhcmUgb2YuJm5ic3A7IEl0ICo8Yj5pcyBub3Q8L2I+KiB0 aGUgcHVycG9zZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gZm9yIGl0IHRvIGJlIHVzZWQgYnkgY2xp ZW50cyBpbiBhbnkgbWFubmVyIHRvIGRpc2NvdmVyIGZlYXR1cmVzIG9mIHRoZSBBdXRob3JpemF0 aW9uIFNlcnZlci4mbmJzcDsgVGhhdCBzaG91bGQgYmUgZXhwbGljaXRseSBvdXQgb2Ygc2NvcGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDBCMDUwIj5DdXJyZW50bHksIGNsaWVudHMgYXJlIGluc3RydWN0ZWQgYnkgUkZDIDY3NDkg dG8gZGlzY292ZXIgaW5mb3JtYXRpb24gYWJvdXQgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIHRoZXkg aW50ZXJhY3Qgd2l0aCBieSBjb25zdWx0aW5nIHRoZSDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPnNlcnZpY2UNCiBkb2N1bWVudGF0aW9uPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj7igJ0gKFJGQyA2NzQ5LCBTZWN0aW9u cyAzLjEgYW5kIDMuMikuJm5ic3A7IFRoZXkgY2FuIGFsc28gbGVhcm4gaW5mb3JtYXRpb24gYWJv dXQgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIGluIHNwZWNpZmljIGNvbnRleHRzIHRocm91Z2ggZGlz Y292ZXJ5IHByb3RvY29scyBzdWNoIGFzIE9wZW5JRA0KIENvbm5lY3QgRGlzY292ZXJ5ICg8YSBo cmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8w Lmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVj cy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWw8L3NwYW4+PC9hPikgYW5kIFVNQSBE aXNjb3ZlcnkgKFRCRCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5JIHN1c3BlY3QgdGhhdCBhdCBzb21lIHBvaW50LCBz b21lb25lIGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHdpbGwgcHJvcG9zZSBkZXZlbG9waW5n IGEgZ2VuZXJpYyBPQXV0aCBkaXNjb3ZlcnkgbWVjaGFuaXNtLCB3aGljaCB3aWxsIGxlYWQgdG8g YSByZWNoYXJ0ZXJpbmcNCiB0byBpbmNsdWRlIHRoaXMgd29yayBpbiB0aGUgd29ya2luZyBncm91 cOKAmXMgc2V0IG9mIGRlbGl2ZXJhYmxlcy4mbmJzcDsgSSB3b3VsZCBzdXBwb3J0IGRvaW5nIHRo aXMgd29yayBhbmQgdGhlIG5lY2Vzc2FyeSByZWNoYXJ0ZXJpbmcgdG8gZG8gc28uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUw Ij5UaGF0IGJlaW5nIHNhaWQsIEkgc3Ryb25nbHkgb3Bwb3NlIHRyeWluZyB0byBzaG9laG9ybiBw aWVjZW1lYWwgYXNwZWN0cyBvZiBkaXNjb3ZlcnkgaW50byB0aGUgRHluYW1pYyBDbGllbnQgUmVn aXN0cmF0aW9uIHNwZWNpZmljYXRpb24uJm5ic3A7IEl0IGlzIGRpc3RpbmN0IGZ1bmN0aW9uYWxp dHkNCiBhbmQgZGVzZXJ2ZXMgZmlyc3QtY2xhc3MgYW5kIHNlcGFyYWJsZSB0cmVhdG1lbnQgYnkg dGhlIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IERpc2NvdmVyeSBpcyBmb3IgcG90ZW50aWFsIGNsaWVu dHMgdG8gbGVhcm4gcHJvcGVydGllcyBvZiB0aGUgQVMgYmVmb3JlIHJlZ2lzdHJhdGlvbi4mbmJz cDsgUmVnaXN0cmF0aW9uIGlzIGZvciBwb3RlbnRpYWwgY2xpZW50cyB0byBpbmZvcm0gdGhlIEFT IG9mIGl0cyBwcm9wZXJ0aWVzLCBjcmVhdGluZyBhIHJlZ2lzdGVyZWQgY2xpZW50LiZuYnNwOw0K IERpc2NvdmVyeSBzZW5kcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQVMgdG8gdGhlIENsaWVudC4m bmJzcDsgUmVnaXN0cmF0aW9uIHNlbmRzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBDbGllbnQgdG8g dGhlIEFTLiZuYnNwOyBUaGF04oCZcyBhIGNsZWFuIHNlcGFyYXRpb24uJm5ic3A7IFdlIHNob3Vs ZCBzdHJvbmdseSByZXNpc3QgbXVkZHlpbmcgdGhlIHR3byBmdW5jdGlvbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5P QXV0aCAyLjAgaXMgYSBzdWNjZXNzIGJlY2F1c2UgaXQgZGlkbuKAmXQgdHJ5IHRvIGJvaWwgdGhl IG9jZWFuLiZuYnNwOyBJdCBzcGVjaWZpZWQgaG93IHRvIGRvIG9uZSB0aGluZyB3ZWxsIGluIGEg c2ltcGxlLCB3ZWItZnJpZW5kbHkgbWFubmVyLiZuYnNwOyBXZSBzaG91bGQgZG8gdGhlIHNhbWUN CiDigJMgZm9jdXNpbmcgb24gc3BlY2lmeWluZyBpbnRlcm9wZXJhYmxlIGR5bmFtaWMgY2xpZW50 IHJlZ2lzdHJhdGlvbiwgd2hpbGUgbWFraW5nIGl0IGNsZWFyIHRoYXQgdGhpcyBpcyBkaXN0aW5j dCBmcm9tIGRpc2NvdmVyeSBhYm91dCBBdXRob3JpemF0aW9uIFNlcnZlciBwcm9wZXJ0aWVzLCBh bmQgbWFraW5nIGl0IGNsZWFyIHRoYXQgZGlzY292ZXJ5IGlzIG91dCBvZiBzY29wZSBmb3IgdGhp cyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwQjA1MCI+SSBhcG9sb2dpemUgYXQgdGhpcyBwb2ludCBvbiBiZWhhbGYgb2Yg bXlzZWxmIGFuZCB0aGUgb3RoZXIgc3BlYyBlZGl0b3JzIGZvciBub3QgYmVpbmcgMTAwJSBjbGVh ciB0aGF0IGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IGlzIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3Bl IGZvcg0KIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbi4mbmJzcDsgSWYgd2UgaGFkIGRvbmUg c28sIEnigJltIHN1cmUgdGhhdCBtYW55IG9mIHRoZSBjdXJyZW50IHF1ZXN0aW9ucyBhbmQgY29u ZnVzaW9ucyB3b3VsZCBub3QgaGF2ZSBhcmlzZW4uJm5ic3A7IEkgdGhpbmsgd2XigJlkIGFzc3Vt ZWQgdGhhdCB0aGlzIHdhcyBvYnZpb3VzLCBidXQgZnJvbSB0aGUgY3VycmVudCBkaXNjdXNzaW9u cywgaXTigJlzIGFwcGFyZW50IHRoYXQgaXTigJlzIG5vdCBvYnZpb3VzLiZuYnNwOyBJIHdpbGwg cGVyc29uYWxseQ0KIGNvbW1pdCB0byBjbGFyaWZ5aW5nIHRoZSBzcGVjaWZpY2F0aW9uIGF0IHRo aXMgcG9pbnQgdG8gZWxpbWluYXRlIHRoaXMgcG90ZW50aWFsIHBvaW50IG9mIGNvbmZ1c2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPkdldHRpbmcgYmFjayB0byB0aGUgc3BlY2lmaWNzLCB0aGUgb25seSB1c2VmdWwg cHVycG9zZSBvZiBhIG11bHRpLXZhbHVlZCDigJw8L3NwYW4+dG9rZW5fZW5kcG9pbnRfY2xpZW50 X2F1dGhfbWV0aG9kPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPuKA nQ0KIG1lbWJlciB3b3VsZCBiZSB0byBlbmFibGUgdGhlIGNsaWVudCB0byBkaXNjb3ZlciBpbmZv cm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhl IEFTIGFmdGVyIHRoZSByZWdpc3RyYXRpb24gaGFkIGJlZW4gcGVyZm9ybWVkLiZuYnNwOyBCdXQg dGhhdCBpcyBhIGRpc2NvdmVyeSBmdW5jdGlvbiwgYW5kIHNvIHNob3VsZCBiZSBwYXJ0IG9mIHRo ZSBkaXNjb3Zlcnkgd29yayDigJMgbm90IHRoaXMgc3BlY2lmaWNhdGlvbi4mbmJzcDsNCiBXZSBz aG91bGQgcmVzaXN0IHNob2Vob3JuaW5nIGluIGJpdHMgb2YgZGlzY292ZXJ5IGludG8gdGhpcyBz cGVjaWZpY2F0aW9uLiZuYnNwOyBJdCAqPGI+aXM8L2I+KiBhIHdvcnRod2hpbGUgdG9waWMsIGJ1 dCBkZXNlcnZlcyBmdWxsIGNvbnNpZGVyYXRpb24gYnkgdGhlIHdvcmtpbmcgZ3JvdXAgaW4gaXRz IG93biByaWdodC4mbmJzcDsgVGhlcmVmb3JlLCB0aGlzIG1lbWJlciBtdXN0IHJlbWFpbiBzaW5n bGUtdmFsdWVkLCBhbmQgYmUgY2xlYXJseSBzcGVjaWZpZWQNCiBhcyB0aGUgbWV0aG9kIGJ5IHdo aWNoIGEgY2xpZW50IGluZm9ybXMgdGhlIEFTIHdoaWNoIHRva2VuIGVuZHBvaW50IGF1dGhlbnRp Y2F0aW9uIG1ldGhvZCBpdCB3aWxsIHVzZS4mbmJzcDsgQW55dGhpbmcgZWxzZSB3b3VsZCBiZSBz Y29wZSBjcmVlcCwgYW5kIHJlc3VsdCBpbiBhbiB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIHNw ZWNpZmljYXRpb24gYW5kIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQgY2xpZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qIFRoZXJlIGlzIG5v IGF1dGhuIG1ldGhvZCBmb3IgJnF1b3Q7Y2xpZW50X3NlY3JldF9zYW1sJnF1b3Q7IG9yICZxdW90 O3ByaXZhdGVfa2V5X3NhbWwmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ob2JvZHkgaGFzIHJlYWxseSBhc2tlZCB0aGF0IHRoZXNl IHR3byBiZSBpbmNsdWRlZCBvciBzcGVjaWZpZWQuIFRoZSBleHRlbnNpb24gbWVjaGFuaXNtICh1 c2luZyBhbiBhYnNvbHV0ZSBVUkkpIHdvdWxkIGFsbG93IHNvbWVvbmUgZWxzZSB0byBkZWZpbmUg dGhlc2UuIElzIHRoZSBkZWZpbml0aW9uIGluIHRoZSBTQU1MIEFzc2VydGlvbiBkcmFmdCBzdWZm aWNpZW50DQogZm9yIHRoZWlyIHVzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayB0aGlzIGlzIGNvbWluZyBmcm9t IHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBKV1QgYmVhcmVyIGRyYWZ0IGFuZCBhIFNBTUwgYmVh cmVyIGRyYWZ0LiAmbmJzcDtUaGUgdHJ1dGggaXMgeW91IGFyZSBkZWZpbmluZyBhbiBhdXRoZW50 aWNhdGlvbiB0aGF0IGlzbid0IGV2ZW4gZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT5UaGVyZSBhcmUgbm8g cHJvZmlsZXMgcmVmZXJlbmNlZCBvciBkZWZpbmVkIGZvciAmcXVvdDtjbGllbnRfc2VjcmV0X2p3 dCZxdW90OyBvciAmcXVvdDtwcml2YXRlX2tleV9qd3QmcXVvdDsuIE5laXRoZXIgb2YgdGhlIEpX VCBvciBTQU1MIEJlYXJlciBkcmFmdHMgcmVmZXJlbmNlZCBjb3ZlciB0aGVzZSB0eXBlcyBvZiBm bG93cy4gVGhleSBvbmx5IGNvdmVyIGJlYXJlciBmbG93cy4gJm5ic3A7JnF1b3Q7Y2xpZW50X3Nl Y3JldF9qd3QmcXVvdDsNCiBhbmQgJnF1b3Q7cHJpdmF0ZV9rZXlfand0JnF1b3Q7IHNlZW0gdG8g aGF2ZSBzb21lIG1lYW5pbmcgd2l0aGluIE9wZW5JRCBDb25uZWN0LCBidXQgSSBub3RlIHRoYXQg T0lEQyBkb2VzIG5vdCBmdWxseSBkZWZpbmUgdGhlc2UgZWl0aGVyLjwvaT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBKV1QgYXNzZXJ0 aW9uIGRyYWZ0IGRvZXMgc2F5IGhvdyB0byB1c2UgYSBKV1QgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbiwgYW5kIHRoZSBEeW5SZWcgdGV4dCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIGEgY2xpZW50 IHNpZ25pbmcgc2FpZCBKV1Qgd2l0aCBpdHMgb3duIHNlY3JldCBzeW1tZXRyaWNhbGx5IHZzLiBh IGNsaWVudCB1c2luZyBpdHMgb3duIHByaXZhdGUNCiBrZXksIGFzeW1tZXRyaWNhbGx5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+QWN0dWFsbHkgbXkgaW50ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1 bWVzIHRoZSBKV1QgQmVhcmVyIGlzIGEgYmVhcmVyIHRva2VuLiAmbmJzcDtUaGUgYXNzdW1wdGlv biBpcyB0aGF0IGlmIGEgY2xpZW50IGhhcyB0aGUgYXNzZXJ0aW9uIGl0IGhhcyB0aGUgcmlnaHQg dG8gcHJlc2VudCBpdC4gJm5ic3A7SU9XLiBUaGUgSldUIEJlYXJlciBEcmFmdCBpcyBtb3N0IGRl ZmluaXRpdmVseQ0KIG5vdCBhIEpXVCBIb0sgRHJhZnQuICZuYnNwOzotKTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJlZ2FyZGxlc3MsIHlvdSBhcmUgaW50 cm9kdWNpbmcgYSBuZXcgcHJvZmlsZSB3aGljaCBpcyB1bmRlZmluZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+SSB0aGluayBJIHNlZSB0aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFraW5n IG5vdywgbGV0IG1lIHRyeSB0byByZS1zdGF0ZSBpdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XaGlsZSB0aGUgYmFzaWNzIG9mICZxdW90O2hvdyB0byBw cmVzZW50IGEgSldUIGFzIGEgY2xpZW50IGNyZWRlbnRpYWwmcXVvdDsgaXMgZGVmaW5lZCBoZXJl OiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRo LWp3dC1iZWFyZXItMDUuaHRtbCNyZmMuc2VjdGlvbi4yLjIiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUuaHRtbCNyZmMuc2VjdGlvbi4yLjI8 L2E+DQogLCBpdCdzIG5vdCBjb21wbGV0ZWx5IHNwZWNpZmllZCBpbiB0aGF0IGl0IGRvZXNuJ3Qg ZnVsbHkgcmVzdHJpY3QgdGhlIHNpZ25hdHVyZSBzZWNyZXQgc291cmNlLCB0aGUgYXVkaWVuY2Ug Y2xhaW0sIGFuZCBvdGhlciB0aGluZ3MgdGhhdCB0aGUgQVMgd291bGQgbmVlZCB0byBjaGVjayBh bmQgdmFsaWRhdGUuIFJpZ2h0PyBUaGUgZHluYW1pYyByZWdpc3RyYXRpb24gZHJhZnQgY2FuIGRl ZmluZSB0aG9zZSBjYXNlcyBpbiBncmVhdGVyIGRldGFpbA0KIGlmIG5lZWRlZCAodGhvdWdoIEkg dGhpbmsgaXQgZG9lcyBzbyBzdWZmaWNpZW50bHkgYXMtaXMsIEkgd2VsY29tZSBtb3JlIGNsYXJp dHkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkknZCBi ZSBPSyB3aXRoIGFkZGluZyB0aGUgU0FNTCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwg b24gdGhlIEpXVCBiaXRzLCBvciBkcm9wcGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50 cyB0byBkbyBhbnkgb2YgdGhvc2UgYWN0aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpX VCBzdHVmZiBpcyBhbHJlYWR5IGluIHVzZSBhbmQgZnVuY3Rpb25pbmcNCiBhbmQgaXQnZCBiZSBh IHNoYW1lIHRvIGxlYXZlIGl0IG91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGd1ZXNzIHRoZW4gdGhlIG1pc3Rha2UgdGhlIEpXVCBC ZWFyZXIgYW5kIFNBTUwgQmVhcmVyIGRyYWZ0cyBhdXRob3JzIG1hZGUgaXMgdGhleSBhc3N1bWVk IGV2ZXJ5b25lIGhhZCB0aGUgc2FtZSBkZWZpbml0aW9uIG9mIGJlYXJlciB0b2tlbi4gJm5ic3A7 VG8gbWUgYSBiZWFyZXIgdG9rZW4gb3BhcXVlIHRvIHRoZSBjbGllbnQuIEl0IHRoZXJlZm9yZSBj YW5ub3QgZG8gYW55DQogc2lnbmF0dXJlIHdvcmsgd2l0aCByZWdhcmRzIHRvIHRoZSB0b2tlbiBp dHNlbGYuICZuYnNwO05vdywgdGhhdCdzIG5vdCB0byBzYXkgYSBwcm9vZiBkaWRuJ3Qgb2NjdXIg YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgdG9rZW4gaXNzdWVyLCBidXQgd2hlbiB0aGUgY2xp ZW50IHdpZWxkcyB0aGUgdG9rZW4sIGl0IGlzIGhhbmRsaW5nIGFuIG9wYXF1ZSBzdHJpbmcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGNvbmNlcHQg b2YgY2xpZW50X3NlY3JldF9qd3Qgc3VnZ2VzdHMgYW4gSG9LIHByb2ZpbGUuICZuYnNwO1RoZXJl Zm9yZSBvZiBjb3Vyc2UgdGhlIGJlYXJlciBkcmFmdHMgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lm aWVkIHdoZW4gaXQgY29tZXMgdG8gSG9LIHByb2ZpbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvIGZvciBleGFtcGxlLCB5b3UgbmVlZCBhIGRyYWZ0 IGxpa2UgdGhlIE1BQyBkcmFmdCBmb3IgdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JJ20gaGF2aW5nIHRyb3VibGUgb3ZlcmFsbCBoZXJl LiBJdCBzZWVtcyB0aGUgYXV0aG4gdHlwZXMgc3VnZ2VzdCBPTkxZIHN0cm9uZyBhdXRoZW50aWNh dGlvbiBmb3IgY2xpZW50cywgeWV0IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgdGhl IGN1cnJlbnQgZHJhZnQgaXNuJ3QgYWJsZSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgaW5zdGFuY2Vz IG9mIHRoZSBzYW1lDQogc29mdHdhcmUgKGV2ZW4gaW4gYSBzZWxmLWFzc2VydGVkIHdheSkuICZu YnNwO0lmIHlvdSBoYXZlbid0IGF1dGhlbnRpY2F0ZWQgdGhlIHNvZnR3YXJlIGF0IGFsbCwgd2h5 IGhhdmUgc3Ryb25nIGNsaWVudCBhdXRoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBpcyBubyBhdXRo ZW50aWNhdGlvbiBtZXRob2QgZGVmaW5lZCBmb3IgJnF1b3Q7Y2xpZW50X2JlYXJlcl9zYW1sJnF1 b3Q7IG9yICZxdW90O2NsaWVudF9iZWFyZXJfand0JnF1b3Q7IG9yICZxdW90O2NsaWVudF9iZWFy ZXJfcmVmJnF1b3Q7LiAmbmJzcDtTaW5jZSB0aGUgYmVhcmVyIHNwZWNzIHNheSB0aGlzIGlzIGFj Y2VwdGFibGUsICZuYnNwO3RoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVjIHNob3VsZCBhY2Nl cHQgdGhlc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBiaXQgLS0gd2hlcmUgYXJlIHRoZXNlIGRl ZmluZWQgaW4gUkZDNjc1MD8gSSBkb24ndCBldmVuIGtub3cgd2hhdCBjbGllbnRfYmVhcmVyX3Jl ZiB3b3VsZCByZWZlciB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Njc1MCBzYXlzIHlvdSBjYW4gdXNlIGEgYmVhcmVyIGFz c2VydGlvbiAoZS5nLiBvYnRhaW5lZCBmcm9tIGFuIElEUCkgYW5kIHdpZWxkIGl0IGFzIGFuIGF1 dGhlbnRpY2F0aW9uIGFzc2VydGlvbi4gJm5ic3A7VGhlIGNsaWVudCBpcyBOT1QgY3JlYXRpbmcg b3IgbW9kaWZ5aW5nIHRoZSBhc3NlcnRpb24uIFRoZSBjbGllbnQgaXMgc2ltcGx5IHBhc3Npbmcg b25lIGl0IHByZXZpb3VzbHkNCiBvYnRhaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5XaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBub3QgYmVhcmVy LiBJdCBpcyBob2xkZXIgb2Yga2V5LiBWZXJ5IHZlcnkgZGlmZmVyZW50LiZuYnNwOzxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+QSBwb3NzaWJsZSBzdWdnZXN0aW9uIGlzIHRvIHJlbW92ZSBjbGllbnRfc2VjcmV0 X2p3dCBhbmQgcHJpdmF0ZV9rZXlfand0IGFuZCBkZWZpbmUgdGhvc2UgYXMgcmVnaXN0ZXIgZXh0 ZW5zaW9ucyBzaW5jZSB0aGVzZSBwcm9maWxlcyBhcmUgbm90IGRlZmluZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGF0J3MgcG9zc2li bGUsIGJ1dCB0aGV5IGFyZSBpbiBhY3RpdmUgdXNlIGFscmVhZHkuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYXQgbWF5IGJlIHRydWUuIEJ1 dCB0aGVuIHlvdSBuZWVkIHRvIHdyaXRlIGFub3RoZXIgZHJhZnQgc28gdGhlIHJlc3Qgb2YgdXMg Y2FuIGltcGxlbWVudCBpdCBpbiBhbiBpbnRlcm9wZXJhYmxlIHdheS4gJm5ic3A7TWUgSSBwcmVm ZXIgbm90IHRvIGd1ZXNzIHdoYXQgeW91IGFyZSBkb2luZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ VGhpcyBtdWNoIEkgYWdyZWUgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+SnVzdGluLCBKb2huLCBhbmQgSSBkaXNjdXNzZWQg dGhpcyBpc3N1ZSBhbmQgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24sIFBoaWwuJm5ic3A7IFNp bmNlIHRoZXkgYXJlIG5vdCBjb21wbGV0ZWx5IHNwZWNpZmllZCwgd2Ugd2lsbCByZW1vdmUgdGhl IGNsaWVudF9zZWNyZXRfand0DQogYW5kIHByaXZhdGVfa2V5X2p3dCBtZXRob2RzIGZyb20gdGhl IHNwZWNpZmljYXRpb24gYW5kIGFkZCBhIHJlZ2lzdHJ5LCBlbmFibGluZyBzcGVjaWZpY2F0aW9u IHRoYXQgZG8gZnVsbHkgc3BlY2lmeSB0aGVzZSBhbmQgb3RoZXIgdG9rZW4gZW5kcG9pbnQgYXV0 aGVudGljYXRpb24gbWV0aG9kcywgaW5jbHVkaW5nIHBvdGVudGlhbCBtZXRob2RzIHVzaW5nIFNB TUwgYXNzZXJ0aW9ucywgdG8gcmVnaXN0ZXIgdGhlbSBpbiB0aGUgcmVnaXN0cnksDQogcmF0aGVy IHRoYW4gdHJ5aW5nIHRvIGJha2UgdGhlbSBpbnRvIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3Ry YXRpb24gc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48Yj5BYm91dCAmcXVvdDt0b3NfdXJpJnF1b3Q7IGFuZCAmcXVvdDtwb2xpY3lfdXJp JnF1b3Q7PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRvc191cmkgYW5kIHBvbGljeV91cmkgaXMgdW5jbGVh ci4gJm5ic3A7Q2FuIHdlIGNsYXJpZnkgb3IgY29tYmluZSB0aGVtPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGVybXMgb2Ygc2VydmljZSBh bmQgcG9saWN5IGFyZSB0d28gZGlmZmVyZW50IGRvY3VtZW50cy4gT25lIGlzIHNvbWV0aGluZyB0 aGF0IGEgdXNlciBhY2NlcHRzIChnZW5lcmFsbHkgZGVzY3JpYmluZyB3aGF0IHRoZSB1c2VyIHdp bGwgZG8pLCBvbmUgaXMgYSBzdGF0ZW1lbnQgb2Ygd2hhdCB0aGUgc2VydmljZSBwcm92aWRlciAo aW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50KQ0KIHdpbGwgZG8uIE1vcmUgaW1wb3J0YW50bHksIHdl IHVzZWQgdG8gaGF2ZSBvbmx5IG9uZSwgYW5kIHNldmVyYWwgcGVvcGxlIGFza2VkIGZvciB0aGVt IHRvIGJlIHNwbGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5TZXZlcmFsIGRldmVsb3BlcnMgd2VyZSBjb25mdXNlZCBieSB0 aGlzLiBJbiBwYXJ0aWN1bGFyIHRoZXkgY291bGRuJ3QgZmlndXJlIG91dCB3aGljaCB3YXMgdXNl ZCBmb3Igd2hhdC4gJm5ic3A7SnVzdCBwYXNzaW5nIGFsb25nIHRoZSBmZWVkYmFjay48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ T0ssIHRoZSBkaXN0aW5jdGlvbiB0aGF0IEkgc2VlIGlzIHRoYXQgdGhlIFRPUyBpcyBjb250cmFj dHVhbCwgdGhlIFBvbGljeSBpcyBhIHN0YXRlbWVudC4gUmUtcmVhZGluZyB0aGUgZGVmaW5pdGlv bnMgaW4gdGhlcmUgcmlnaHQgbm93LCB0aGF0IGNhbiBiZSBtYWRlIG11Y2ggY2xlYXJlci4gKEl0 IGV2ZW4gbG9va3MgbGlrZSBzb21lIE9JREMgdGV4dCBsZWFrZWQgaW50bw0KIHRoZSBkZWZpbml0 aW9uIG9mIHBvbGljeV91cmkgYW5kIHRoYXQgaGFkbid0IGJlZW4gY2F1Z2h0IHlldC4pPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1s ZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1yaWdodDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+SSBzdXBwb3J0IGNsYXJpZnlpbmcgdGhlIGxhbmd1YWdlIG9uIHRoZXNlIGRl ZmluaXRpb25zLCBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIHRvIGRvIHNvLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsc28s IGFyZW4ndCB0aGVzZSByZWFsbHkgVVJJcyBvciBhcmUgdGhleSBtZWFudCB0byBiZSBVUkxzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhl cmUgd2FzIGFscmVhZHkgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRoZSBsaXN0OiBUaGUgSUVU RiBpcyBhcHBhcmVudGx5IHRyeWluZyB0byBkZXByZWNhdGUgVVJMIGluIGZhdm9yIG9mIFVSSSBp biBuZXcgc3BlY3MuIFNvIGluIHByYWN0aWNlIHRoZXknbGwgbmVhcmx5IGFsd2F5cyBiZSBVUkxz LCBidXQgc2luY2UgYWxsIFVSTHMgYXJlIFVSSXMgd2UncmUgbm90DQogdGVjaG5pY2FsbHkgaW5j b3JyZWN0IGluIGZvbGxvd2luZyB0aGUgbmV3IHBvbGljeS4gQW5kIGl0IG1ha2VzIHRoZSBJRVNH IGxlc3MgbWFkIGF0IHVzLCB3aGljaCBpcyBhIHBsdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFyZy4gTmljZS4gJm5ic3A7 VGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5IHRoZSB2YWx1ZSBwYXNzZWQgbXVzdCByZXNvbHZlIHRv IGEgdmFsaWQgd2ViIHBhZ2UsIGRvY3VtZW50LCB3aGF0ZXZlci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhdCdzIGZhaXIs IGFuZCBpdCdzIHNvbWV0aGluZyB0aGF0IHRoZSBBUyBjYW4gZXZlbiBjaGVjayBpZiBpdCB3YW50 cyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDBCMDUwIj5BZ3JlZWQgb24gdGhpcyBjbGFyaWZpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmln aHQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxiPkFib3V0ICZxdW90O2p3a3NfdXJpJnF1b3Q7PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3ImbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWIta2V5LTA5Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWIta2V5LTA5PC9hPiZuYnNwO2lzDQogbmVlZGVkLiZuYnNwOzwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Z ZXMsIHlvdSdyZSBjb3JyZWN0LCBJJ2xsIGFkZCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNob3Vs ZCBiZSBVUkwgaW5zdGVhZCBvZiBVUkk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TZWUgYWJvdmUuIDopPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAi PkFncmVlZCBvbiBhZGRpbmcgdGhpcyByZWZlcmVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPlNlY3Rpb24gMi4xPC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkluIHRoZSB0 YWJsZSZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij51cm46aWV0 ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpqd3QtYmVhcmVyPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5p cyBtaXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SXQncyB0aGVyZSBpbiB0aGUgY29weSBvZiAtMTAgSSdtIHJlYWRpbmcgb2ZmIG9m DQo8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmcvIj5pZXRmLm9yZzwvYT4gcmlnaHQgbm93IOKApiA/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPic8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5Tb3JyeSBJIG1lYW50OiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij51cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpzYW1sLWJlYXJlcjwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkFoLCB0aGF0IG1ha2VzIG1vcmUgc2Vuc2UuIElmIHRoZSBXRyB3YW50cyB0 byBhZGQgaW4gU0FNTCBzdXBwb3J0IHRvIHBhcmFsbGVsIHRoZSBKV1Qgc3VwcG9ydCwgSSdkIGJl IE9LIHdpdGggdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPuKAnEFzIHN1Y2gs IGEgc2VydmVyIHN1cHBvcnRpbmcgdGhlc2UgZmllbGRzIFNIT1VMRCB0YWtlIHN0ZXBzJm5ic3A7 dG8gZW5zdXJlIHRoYXQgYSBjbGllbnQgY2Fubm90IHJlZ2lzdGVyIGl0c2VsZiBpbnRvIGFuIGlu Y29uc2lzdGVudCBzdGF0ZS7igJ08YnI+DQo8YnI+DQpXZSBtYXkgd2FudCB0byBkZWZpbmUgbW9y ZSBkZXRhaWxlZCBIVFRQIGVycm9yIHJlc3BvbnNlLiZuYnNwO0UuZy4gNDAwIHN0YXR1cyBjb2Rl ICYjNDM7IGRlZmluZWQgZXJyb3IgY29kZSAo4oCcaW52YWxpZF9jbGllbnRfbWV0YWRhdGHigJ0p PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ SSdkIGJlIGZpbmUgd2l0aCBkZWZpbmluZyBhIG1vcmUgZXhwbGljaXQgZXJyb3Igc3RhdGUgaW4g dGhpcyBjYXNlLiBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgaW50ZXJvcCBmb3IgdGhlIHNlcnZlcnMg dGhhdCB3YW50IHRvIGVuZm9yY2UgZ3JhbnQtdHlwZSBhbmQgcmVzcG9uc2UtdHlwZSByZXN0cmlj dGlvbnMsIGJ1dCBzZXJ2ZXJzIHRoYXQgY2FuJ3Qgb3IgZG9uJ3QgY2FyZQ0KIGFib3V0IHJlc3Ry aWN0aW5nIGdyYW50cyB0eXBlcyBhbmQgd2hhdG5vdCBkb24ndCBoYXZlIHRvIGRvIGFueXRoaW5n IHNwZWNpYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgKjxiPnRoaW5rPC9iPiogdGhhdCB0aGlz IGdvZXMgYXdheSB3aXRoIHRoZSBkZWxldGlvbiBvZiBjbGllbnRfc2VjcmV0X2p3dCBhbmQgcHJp dmF0ZV9rZXlfand0IGluIGZhdm9yIG9mIHRoZSByZWdpc3RyeeKApiZuYnNwOyBJ4oCZbGwgZG8g YSBjb25zaXN0ZW5jeSBjaGVjayBhbmQgdmVyaWZ5DQogdGhhdCB3aGVuIHRoZSBzcGVjIGlzIHVw ZGF0ZWQgYWNjb3JkaW5nbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPlNlY3Rpb24gMi4yPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPk1heSB3YW50IHRv IGFkZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDsiIENvdXJpZXJOZXc/Pyw/c2VyaWY/Pz0iIj5XaGVuJm5ic3A74oCcI+KA nSBsYW5ndWFnZSB0YWcgaXMgbWlzc2luZywgKGUuZy4g4oCcI2Vu4oCdIGlzIG1pc3NpbmcgaW4g 4oCcY2xpZW50X25hbWXigJ0sIGluc3RlYWQmbmJzcDtvZiDigJxjbGllbnRfbmFtZSNlbuKAnSkg dGhlIE9BdXRoIHNlcnZlciBtYXkgdXNlIGludGVycHJldCB0aGUmbmJzcDtsYW5ndWFnZSB1c2Vk IGJhc2VkJm5ic3A7b24NCiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBvciBoZXVyaXN0aWNzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYXQgc2Vl bXMgaW5jb25zaXN0ZW50IHdpdGggd2hhdCB3ZSBhbHJlYWR5IGhhdmU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPklmIGFueSBodW1hbi1yZWFkYWJsZSBmaWVsZCBpcyBzZW50IHdpdGhvdXQgYSBsYW5n dWFnZSB0YWcsIHBhcnRpZXMgdXNpbmcgaXQgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1wdGlvbnMg YWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIgc2V0LCBvciBzY3JpcHQgb2YgdGhlIHN0cmlu ZyB2YWx1ZSwgYW5kIHRoZSBzdHJpbmcgdmFsdWUgTVVTVCBiZSB1c2VkIGFzLWlzDQogd2hlcmV2 ZXIgaXQgaXMgcHJlc2VudGVkIGluIGEgdXNlciBpbnRlcmZhY2UuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+V2hpY2ggaXMgdG8gc2F5LCB0cmVhdCBpdCBhcyBhIHJhdyBieXRl LXZhbHVlLXN0cmluZyBhbmQgZG9uJ3QgdHJ5IHRvIGdldCBmYW5jeS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkkgd2lsbCBkaXNjdXNzIHdpdGggb3VyIGRldmVsb3BlcnMuIEknbSBub3Qgc3VyZSB0 aGUgYXMtaXMgd29ya3MuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPklzIGl0IHRoZSBpbnRlbnQgdGhhdCB3aGVuIHRoZSBjbGllbnQgaGFzIGxv Y2FsaXplZCAmcXVvdDtjbGllbnRfbmFtZSZxdW90OyBmb3IgZXhhbXBsZSwgaXQgc2hvdWxkIHBh c3MgYWxsIGxhbmd1YWdlIHZhcmlhdGlvbnMgaW4gYSBKU09OIGFycmF5PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9yLCBzaG91bGQgcGFydCBvZiB0aGUg cmVnaXN0cmF0aW9uIGJlIHRvIGluZGljYXRlIHdoaWNoIGludGVyZmFjZSBsYW5ndWFnZSB0aGUg Y2xpZW50IHdpc2hlcyB0byB1c2U/ICZuYnNwO1RoZW4gaXQgb25seSBwYXNzZXMgYSBzaW5nbGUg dmFsdWUgZm9yIHRoYXQgcmVnaXN0cmF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5ObywgdGhlIGNsaWVudCBzaG91bGQgcGFzcyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNl cGFyYXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhpcyBpbiBpdHMgZXhhbXBsZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyAmcXVvdDtjbGllbnRfbmFtZSZxdW90 OzogJnF1b3Q7TXkgRXhhbXBsZSZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7ICZxdW90O2NsaWVudF9uYW1lI2phLUpwYW4t SlAmcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgq/jg6njgqTjgqLjg7Pjg4jlkI08L3NwYW4+JnF1b3Q7 LDxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPlNob3VsZCB3ZSBhZGQgdGhhdCB0byBhdCBsZWFzdCBvbmUgb2YgdGhl IGV4YW1wbGVzIGluIER5blJlZz8gKFRoZSBsYW5ndWFnZSB0YWdzIGFyZSBhIGxhdGUgYWRkaXRp b24sIHNvIHRoZSBleGFtcGxlcyBkb24ndCByZWZsZWN0IGl0Lik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5BbiBleGFtcGxlIHdvdWxkIGRlZmluaXRlbHkgaGVscC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPklmIHRoZSBjbGllbnQgcGFzc2VzIG9ubHkgYSBzaW5nbGUgdW5hZG9ybmVkIGZpZWxkLCB0 aGUgQVMgY2FuJ3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB3aGF0IGxhbmd1YWdlIGl0IGlz LiBUaGluayBvZiB0aGlzIGFzIHRoZSBpbnRlcm5hdGlvbmFsaXplZCB2YWx1ZSBvZiB0aGUgZmll bGQgd2hpbGUgdGhlIGxhbmd1YWdlIHRhZ3MgYXJlIHRoZSBsb2NhbGl6ZWQNCiB2ZXJzaW9ucyBv ZiB0aGUgZmllbGQuIFRoaXMgaXMgd2h5IHdlIHJlY29tbWVuZCB0aGF0IHRoZSBiYXJlLXZhbHVl IGFsd2F5cyBiZSBzZW50IGJ5IHRoZSBjbGllbnQsIHNvIHRoYXQgaW4gdGhlIGxhY2sgb2YgYW55 dGhpbmcgbW9yZSBzcGVjaWZpYywgdGhlIEFTIGNhbiBhdCBsZWFzdCBkbyAqc29tZXRoaW5nKiB3 aXRoIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBh c3NpbmcgaW4gYSAmcXVvdDtkZWZhdWx0JnF1b3Q7IGxhbmd1YWdlIGZpZWxkIChsaWtlIGRlZmF1 bHRfbG9jYWxlIG9yIHRoZSBsaWtlKSBpcyBvbmx5IGdvaW5nIHRvIGxlYWQgdG8gcGFpbiBmb3Ig aW1wbGVtZW50b3JzIG9mIGJvdGggY2xpZW50cyBhbmQgc2VydmVycywgYW5kIGl0J3MgZ29pbmcg dG8gaHVydCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgaHVtYW4tcmVhZGFibGUNCiBmaWVs ZHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayB3aGF0IEkgbWVh bnQgaXMgc2luY2UgeW91IGFyZSBhbGxvd2luZyBlYWNoIGNsaWVudCB0byByZWdpc3RlciBkaWZm ZXJlbnQgdGhpbmdzLCBBTkQgdGhlIGNsaWVudCBsaWtlbHkgYWxyZWFkeSBrbm93cyB0aGUgdXNl cidzIHByZWZlcnJlZCBsYW5ndWFnZSwgd2h5IHdvdWxkbid0IHRoZSBjbGllbnQganVzdCBwYXNz IHRleHQgdmFsdWVzIGluIG9uZSBsYW5ndWFnZQ0KIGFuZCBhbm90aGVyIHBhcmFtZXRlciBpbmRp Y2F0aW5nIHByZWZlcnJlZCBsYW5ndWFnZSBpbiB0aGUgY2FzZSBvZiBhbnkgc2VydmljZSBnZW5l cmF0ZWQgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JcyB0aGUgcmVhc29uIHlvdSBhcmUgcGFzc2luZyBtdWx0aXBsZSBsb2NhbGl6YXRpb25zIGlz IHNvIHRoYXQgeW91IGNhbiB1c2UgdGhlIHByZWZlcnJlZCBsYW5ndWFnZSBvZiB0aGUgcmVzb3Vy Y2Ugb3duZXIgcmF0aGVyIHRoZW4gdGhlIGNsaWVudCB1c2VyPyBJIHdvbmRlciBpZiB0aGF0IGlz IGNvcnJlY3QuICZuYnNwO0lmIHRoZSBsYW5ndWFnZSBwcmVmZXJlbmNlcyBhcmUNCiBpbiBmYWN0 IGRpZmZlcmVudCwgd2hhdCB3b3VsZCB0aGUgdXNlciBvZiB0aGUgY2xpZW50IGFwcCBleHBlY3Q/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0tLSZndDsg YW55IG11bHRpLWxpbmd1YWwgcGVvcGxlIGhhdmUgYW55IG9waW5pb25zIGhlcmU/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPldpdGhvdXQgc3BlY2lmaWMgcHJvcG9zZWQgdGV4dCBj aGFuZ2VzIHRvIHJldmlldywgaXTigJlzIGhhcmQgdG8ga25vdyB3aGF0IHRvIHRoaW5rIGFib3V0 IHRoaXMgY29tbWVudC4mbmJzcDsgVW5sZXNzIGEgc3BlY2lmaWMgcHJvcG9zZWQNCiB0ZXh0IGNo YW5nZSBpcyBzZW50IHRvIHRoZSBsaXN0IHdpdGggY2xlYXIgcmF0aW9uYWxlIGZvciB3aHkgaXTi gJlzIGJldHRlciB0aGFuIHdoYXTigJlzIHRoZXJlIG5vdyBhbmQgcmV2aWV3ZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAsIEkgZG9u4oCZdCBiZWxpZXZlIHdlIHNob3VsZCBjaGFuZ2UgdGhlIHNwZWNp ZmljYXRpb24gaW4gcmVzcG9uc2UgdG8gdGhpcyBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPlNlY3Rpb24gMzwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5FeGlzdGluZyB0ZXh0Ojxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDsiIENvdXJpZXJOZXc/Pyw/c2VyaWY/ Pz0iIj7igJxJbiBvcmRlciB0byBzdXBwb3J0IG9wZW4gcmVnaXN0cmF0aW9uIGFuZCBmYWNpbGl0 YXRlIHdpZGVyJm5ic3A7aW50ZXJvcGVyYWJpbGl0eSwgdGhlIENsaWVudCBSZWdpc3RyYXRpb24g RW5kcG9pbnQmbmJzcDtTSE9VTEQmbmJzcDthbGxvdyBpbml0aWFsIHJlZ2lzdHJhdGlvbiZuYnNw O3JlcXVlc3RzIHdpdGggbm8mbmJzcDthdXRoZW50aWNhdGlvbi4mbmJzcDsmbmJzcDtUaGVzZSBy ZXF1ZXN0cyBNQVkgYmUmbmJzcDtyYXRlLWxpbWl0ZWQNCiBvciBvdGhlcndpc2UgbGltaXRlZCB0 byBwcmV2ZW50IGEgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIG9uIHRoZSZuYnNwO0NsaWVudCZu YnNwO1JlZ2lzdHJhdGlvbiBFbmRwb2ludC7igJ08L3NwYW4+PGJyPg0KPGJyPg0KSSB3b3VsZCBz dWdnZXN0IHRvIGNoYW5nZSB0aGUgZmlyc3Qg4oCcU0hPVUxE4oCdIHRvIOKAnE1BWeKAnS4mbmJz cDsgJm5ic3A7SW4gbW9zdCBjbG91ZCBzZXJ2aWNlcywgdGhlIGZpcnN0IGNsaWVudCBpcyZuYnNw O3JlZ2lzdGVyZWQgYnkgYSBodW1hbiB1c2VyLiBUaGVuLCBvdGhlciZuYnNwO2NsaWVudHMgY2Fu IGJlIGZ1cnRoZXIgdXNlZCB0byBhdXRvbWF0ZSZuYnNwO290aGVyIGNsaWVudCByZWdpc3RyYXRp b24uJm5ic3A7Jm5ic3A7U28sIHRoZSBmaXJzdCZuYnNwO3JlcXVlc3Qgd291bGQgdHlwaWNhbGx5 IGNvbWUgd2l0aA0KIGFuIGF1dGhlbnRpY2F0ZWQgdXNlciBpZGVudGl0eS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsgdGhlIHdlaWdo dCBvZiAmcXVvdDtTSE9VTEQmcXVvdDsgaXMgYXBwcm9wcmlhdGUgaGVyZSwgYmVjYXVzZSBJIGJl bGlldmUgdGhhdCB0dXJuaW5nIG9mZiBvcGVuIHJlZ2lzdHJhdGlvbiBhdCB0aGUgQVMgKHdoaWNo IGlzIHdoYXQgdGhpcyBpcyB0YWxraW5nIGFib3V0KSByZWFsbHkgb3VnaHQgdG8gYmUgdGhlIGV4 Y2VwdGlvbiByYXRoZXIgdGhhbiB0aGUgcnVsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayB5b3UgYXJl IHJlYWRpbmcgaXQgd3JvbmcgLS0gYSBkb3VibGUtbmVnYXRpdmUgaXNzdWUuIFRoZSBlbmQgb2Yg dGhlIHNlbnRlbmNlIGlzICZxdW90O25vIGF1dGhlbnRpY2F0aW9uJnF1b3Q7LiAmbmJzcDtZb3Ug YXJlIGltcGx5aW5nIHRoYXQgTk8gQXV0aGVudGljYXRpb24gdXMgd2hhdCBzaG91bGQgbm9ybWFs bHkgYmUgZG9uZS4gSSB0aGluayB5b3UgaW50ZW5kIGFub255bW91cw0KIGF1dGhlbnRpY2F0aW9u IHRvIGJlIHRoZSBleGNlcHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUgZG9uJ3QgeW91PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5ObywgSSB0aGluayB0aGF0IGFub255bW91cyBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdGhl IHJ1bGUuIE9wZW4gcmVnaXN0cmF0aW9uIHNob3VsZCBiZSBkZWZhdWx0LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkaXNhZ3JlZS4gJm5ic3A7QWdhaW4sICZuYnNwO3RoZSBz cGVjIHNlZW1zIGNvbnRyYWRpY3RvcnkuIEl0IHN1Z2dlc3RzIHN0cm9uZyBjbGllbnQgYXV0aCBt ZXRob2RzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIGFub255bW91cyByZWdpc3RyYXRpb24uICZuYnNw O1llcyB5b3UgZ2FpbiB1bmlxdWVuZXNzLCBidXQgdGhhdCdzIGFib3V0IGl0LjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCk9uIHRoZSBmbGlwIHNpZGUsIHRoZSBlYXJs aWVyIHBhcmFncmFwaDo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 IiBDb3VyaWVyTmV3Pz8sP3NlcmlmPz89IiI+4oCcVGhlIENsaWVudCBSZWdpc3RyYXRpb24gRW5k cG9pbnQmbmJzcDtNQVkmbmJzcDthY2NlcHQgYW4gaW5pdGlhbCBhdXRob3JpemF0aW9uIGNyZWRl bnRpYWwgaW4gdGhlIGZvcm0gb2YgYW4gT0F1dGggMi4wJm5ic3A7W1JGQzY3NDldIGFjY2VzcyB0 b2tlbiBpbiBvcmRlciB0byZuYnNwO2xpbWl0IHJlZ2lzdHJhdGlvbiB0byBvbmx5IHByZXZpb3Vz bHkmbmJzcDthdXRob3JpemVkIHBhcnRpZXMuIFRoZQ0KIG1ldGhvZCBieSB3aGljaCB0aGlzIGFj Y2VzcyB0b2tlbiBpcyBvYnRhaW5lZCBieSB0aGUmbmJzcDtyZWdpc3RyYW50IGlzIGdlbmVyYWxs eSBvdXQtb2YtYmFuZCBhbmQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi7i gJ08YnI+DQo8L3NwYW4+PGJyPg0KSSB0ZW5kIHRvIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0 byBjaGFuZ2UgdGhpcyDigJxNQVnigJ0gdG8g4oCcU0hPVUxE4oCdLjxicj4NCjxicj4NClRoYXQg YWNjZXNzIHRva2VuIHdvdWxkIGNhcnJ5IGEgaHVtYW4gdXNlciBhdXRoZW50aWNhdGVkJm5ic3A7 aWRlbnRpdHkgc29tZWhvdy4gSW4gc29tZSBjYXNlcywgaXQgY2FuIGJlIGEgcHVyZSBhdXRoZW50 aWNhdGVkIHVzZXIgYXNzZXJ0aW9uJm5ic3A7dG9rZW4uPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWdhaW4s IGRpc2FncmVlLCBmb3IgdGhlIHNhbWUgcmVhc29uaW5nIGFzIGFib3ZlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TYW1lIHJl YXNvbmluZy4mbmJzcDs8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgYWdyZWUgd2l0aCBKdXN0aW4gaGVyZS4mbmJz cDsgVGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgb3BlbiByZWdpc3RyYXRpb25zIGFyZSBlbmFi bGVkLiZuYnNwOyBUaGUgZXhjZXB0aW9uIGNhc2UgaXMgdGhhdCBzcGVjaWZpYyBwZXJtaXNzaW9u cyBhcmUgcmVxdWlyZWQgdG8gcGVyZm9ybQ0KIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGJyPg0KPGI+QWJvdXQgc2VjdGlvbiA0LjM6PC9iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklmIHRoZSBjbGllbnQgZG9lcyBub3QgZXhpc3Qg b24gdGhpcyBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgTVVTVCByZXNwb25kPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyB3aXRoIEhU VFAgNDAxIFVuYXV0aG9yaXplZCwgYW5kIHRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIHVz ZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jm5ic3A7Jm5ic3A7IG1ha2UgdGhpcyByZXF1ZXN0IFNIT1VMRCBiZSBpbW1lZGlhdGVseSBy ZXZva2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPklmIHRoZSBDbGllbnQgZG9lcyBub3QgZXhpc3Qgb24mbmJzcDt0aGlzIHNlcnZlciwg c2hvdWxkbid0IGl0IHJldHVybiBhICZxdW90OzQwNCBOb3QgRm91bmQmcXVvdDs/PGJyPg0KPGJy Pg0KSWYgcmV2b2tpbmcgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4sIGlzIGl0IGJvdW5k IHRvIGEgc2luZ2xlIGNsaWVudCByZWdpc3RyYXRpb24/ICZuYnNwO1RoaXMgaXMgbm90IGNsZWFy LiAmbmJzcDtXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJlZ2lzdHJhdGlvbiBhY2Nlc3Mg dG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJlc3BvbnNlIGlu IHNlY3Rpb24gNS4xLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VGhlIGxhbmd1YWdlIGFib3V0IHRoZSA0MDEgaGVyZSAoYW5kIGluIG90aGVyIG5lYXJieSBz ZWN0aW9ucykgaXMgc3BlY2lmaWNhbGx5IHNvIHRoYXQgeW91IHRyZWF0IGEgbWlzc2luZyBjbGll bnQgYW5kIGEgYmFkIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gdGhlIHNhbWUgd2F5LiBZb3Ug c2VlLCZuYnNwO3JldHVybmluZyBhIDQwNCBoZXJlIGFjdHVhbGx5IGluZGljYXRlcw0KIHRoaW5n cyB3ZXJlIGluIGFuIGluY29uc2lzdGVudCBzdGF0ZS4gTmFtZWx5LCB0aGF0IHRoZSByZWdpc3Ry YXRpb24gYWNjZXNzIHRva2VuIHdhcyBzdGlsbCB2YWxpZCBidXQgdGhlIGNsaWVudCB0aGF0IHRo ZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIHdhcyBhdHRhY2hlZCB0byBkb2Vzbid0IGV4aXN0 IGFueW1vcmUuIFRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGluIG1lYW50IHRvIGJlIHRp ZWQgdG8gYSBjbGllbnQncyBpbnN0YW5jZQ0KIChvciByZWdpc3RyYXRpb24pLCBzbyBpdCdzIGFj dHVhbGx5IG1vcmUgc2Vuc2libGUgdG8gYWN0IGFzIHRob3VnaCB0aGUgcmVnaXN0cmF0aW9uIGFj Y2VzcyB0b2tlbiBpc24ndCB2YWxpZCBhbnltb3JlLiBJbiBhdCBsZWFzdCBzb21lIGltcGxlbWVu dGF0aW9ucyAoc3BlY2lmaWNhbGx5IG91cnMgYXQgTUlUUkUgdGhhdCdzIGJ1aWx0IG9uIFNFQ09B VVRIIGluIEphdmEpLCB5b3UnZCBuZXZlciBiZSBhYmxlIHRvIHJlYWNoIHRoZSA0MDQgc3RhdGUN CiBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0aGUgaW5ib3VuZCB0b2tlbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TaW5jZSB0aGUgaW50 ZW50IG9mIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGlzIHRoYXQgaXQncyBib3VuZCB0 byBhIHNpbmdsZSBpbnN0YW5jZSwgaXRzIGxpZmVjeWNsZSBpcyBnZW5lcmFsbHkgdGllZCB0byB0 aGUgbGlmZWN5Y2xlIGJlZ2lucyBhdCB0aGUgaXNzdWFuY2Ugb2YgYSBuZXcgY2xpZW50X2lkIHdp dGggdGhhdCBpbnN0YW5jZS4gVGhhdCB0b2tlbg0KIG1pZ2h0IGJlIHJldm9rZWQgYW5kIGEgbmV3 IG9uZSBpc3N1ZWQgb24gUmVhZCBhbmQgVXBkYXRlIHJlcXVlc3RzIHRvIHRoZSBDbGllbnQgQ29u ZmlndXJhdGlvbiBFbmRwb2ludCAoYW5kIHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgcHJlcGFyZWQg Zm9yIHRoYXQgLS0gc2FtZSBhcyB0aGUgY2xpZW50X3NlY3JldCksIGFuZCBpdCB3aWxsIGJlIHJl dm9rZWQgd2hlbiB0aGUgY2xpZW50IGlzIGRlbGV0ZWQgZWl0aGVyIHdpdGggYSBEZWxldGUgY2Fs bA0KIHRvIHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludCBvciBzb21ldGhpbmcgaGFw cGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwgdGhlIGNsaWVudC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TaG91bGQgd2UgYWRkIG1vcmUgZXhw bGFuYXRvcnkgdGV4dCB0byB0aGUgZGVmaW5pdGlvbiBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlv bj8gRWxzZXdoZXJlPyBJJ20gdmVyeSBvcGVuIHRvIGNvbmNyZXRlIHN1Z2dlc3Rpb25zIHdpdGgg dGhpcywgc2luY2UgSSBkb24ndCB0aGluayBpdCdzIGFzIGNsZWFyIGFzIHdlJ2QgbGlrZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayB3ZSBz aG91bGQgbG9vayBhdCBpdC48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkZvciBzZWN1cml0eSByZWFzb25zLCBpdOKA mXMgZ2VuZXJhbGx5IG5vdCBnb29kIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g4oCcbm90IGZvdW5k 4oCdIGFuZCDigJx1bmF1dGhvcml6ZWTigJ0gZXJyb3JzIGluIHJlc3BvbnNlcywgYXMgdGhhdCBj YW4gcHJvdmlkZSB0aGUgYXR0YWNrZXIgYW4NCiBvcmFjbGUgdG8gcHJvYmUgd2hldGhlciBhIHBh cnRpY3VsYXIgZW50aXR5IGV4aXN0cyZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgYSBjaGFuZ2UgaXMg Y2FsbGVkIGZvciBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8Yj5BYm91dCBzZWN0aW9uIDUuMTo8 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JcyByZWdp c3RyYXRpb25fYWNjZXNzX3Rva2VuIHVuaXF1ZT8gJm5ic3A7T3IgaXMgaXQgc2hhcmVkIGJ5IG11 bHRpcGxlIGluc3RhbmNlcz8gJm5ic3A7IElmIHNoYXJlZCwgdGhlbiByZWdpc3RyYXRpb25fYWNj ZXNzX3Rva2VuIGNhbid0IGJlIHJldm9rZWQgb24gZGVsZXRlIG9mIGNsaWVudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMEIwNTAiPlRoZSByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGlzIHVuaXF1 ZSB0byBhIHJlZ2lzdGVyZWQgY2xpZW50LCBpbiB0aGUgUkZDIDY3NDkgc2Vuc2Ugb2Yg4oCcY2xp ZW504oCdLiZuYnNwOyBBZ2FpbiwgaWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIOKAnGNsaWVudCBp bnN0YW5jZXPigJ0sIHdlIG5lZWQNCiB0byByZWNoYXJ0ZXIgYW5kIHRha2UgdGhpcyBkaXN0aW5j dCB3b3JrIGl0ZW0gdXAgZXhwbGljaXRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KU3VnZ2VzdCByZW5h bWUg4oCcZXhwaXJlc19hdOKAnSB0byDigJxjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXTigJ0sJm5i c3A7PGJyPg0KPGJyPg0KU3VnZ2VzdCB0byByZW5hbWUg4oCcaXNzdWVkX2F04oCdIHRvIOKAnGlk X2lzc3VlZF9hdOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+V2hpbGUgSSBkbyBsaWtlIHRoZSBzdWdnZXN0aW9uIG9mIGNoYW5naW5nIHRoZXNlIHRvIGNs aWVudF9zZWNyZXRfZXhwaXJlc19hdCBhbmQgY2xpZW50X2lkX2lzc3VlZF9hdCwgYW5kIEkgdGhp bmsgdGhlc2UgYXJlIG1vcmUgY2xlYXIgYW5kIHJlYWRhYmxlLA0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGRvbid0IHdhbnQgdG8gY2hhbmdlIHRoZSBz eW50YXggZHVyaW5nIGxhc3QgY2FsbCB1bmxlc3MgdGhlcmUgaXMgYSBjbGVhciBuZWVkIGFuZCBh IGNsZWFyIGNvbnNlbnN1cyBmb3IgZG9pbmcgc28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5UaGF0J3Mgd2h5IHdlIGFyZSBoYXZpbmcgbGFzdCBjYWxsLiBUbyBjb25m aXJtIGNvbnNlbnN1cyBvbiB0aGUgZHJhZnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U2FtZSByZWFzb25pbmcgYXMgZWFybGllci4gWW91IG5v dyBoYXZlIG11bHRpcGxlIHRva2VucyAocmVnaXN0cmF0aW9uIGFjY2VzcyBhbmQgY2xpZW50KSBp biBwbGF5LiBUaGUgc3BlYyBuZWVkcyB0byBiZSBjbGVhciB3aGljaCBvbmUgaXQgaXMgdGFsa2lu ZyBhYm91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+SSdtIGZpbmUgd2l0aCB0aGUgc3VnZ2VzdGVkIGNoYW5nZSBidXQgSSB3 b3VsZCBsaWtlIG1vcmUgZmVlZGJhY2sgZnJvbSBvdGhlciBwZW9wbGUgYmVmb3JlIG1vdmluZyBm b3J3YXJkIHdpdGggaXQuIFRoZXJlJ3MgYSBsb3Qgb2YgdmFsdWUgaW4gJnF1b3Q7anVzdCBwaWNr IGEgbmFtZSBhbmQgc2hpcCBpdCZxdW90OyBhcyB3ZWxsIHRob3VnaCwgYW5kIEkgZG9uJ3Qgd2Fu dCB0byBkZXZvbHZlDQogaW50byBiaWtlIHNoZWRkaW5nLiAoSSdtIG5vdCBhY2N1c2luZyB5b3Ug b2YgYmlrZSBzaGVkZGluZyBxdWl0ZSB5ZXQsIGJ0dywganVzdCBhZnJhaWQgb2YgZ2V0dGluZyBp bnRvIGEgbG9uZyBkZWJhdGUgb24gbmFtZXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFnYWluLCB0aGlzIHdhcyBhIHByb2JsZW0gcmFp c2VkIGJ5IHBlb3BsZSBuZXcgdG8gdGhlIHNwZWNpZmljYXRpb24uIFRoZXkgZm91bmQgaXQgY29u ZnVzaW5nLiBJIHRlbmQgdG8gYWdyZWUuIFdlJ3JlIG5vdCB0YWxraW5nIGFib3V0IHdoYXQgY29s b3VyIHRvIHBhaW50IHRoZSBzaGVkLiBXZSdyZSB0YWxraW5nIGFib3V0IHdoZXRoZXIgdGhlIGJp a2Ugc2hlZCBpcw0KIGEgaG91c2UuJm5ic3A7Jm5ic3A7Oi0pJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSdtIG5vdCB0b28gZnVzc2VkIGFib3V0 IHdoZXRoZXIgeW91IGNhbGwgaXQgJnF1b3Q7Y2xfc2VjX2V4cGlyeSZxdW90OyBvciAmcXVvdDtj bGllbnRfc2VjcmV0X2V4cGlyZXNfYXQmcXVvdDsuJm5ic3A7PGJyPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5JZiB0aGUg ZGVmaW5pdGlvbnMgb2Yg4oCcZXhwaXJlc19hdOKAnSBvciDigJxpc3N1ZWRfYXTigJ0gYXJlIHVu Y2xlYXIsIHdlIHNob3VsZCBjbGFyaWZ5IHRoZW0uJm5ic3A7IElmIHlvdSBiZWxpZXZlIHRoYXQg dGhpcyBpcyB0aGUgY2FzZSBQaGlsLCBjYW4geW91IHN1cHBseSBwcm9wb3NlZCBhbHRlcm5hdGl2 ZQ0KIGRlZmluaXRpb24gdGV4dCB0aGF0IGlzIGNsZWFyZXI/Jm5ic3A7IFRoYXQgYmVpbmcgc2Fp ZCwgSSBiZWxpZXZlIHRoYXQgYXQgdGhpcyBwb2ludCB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUg ZXhpc3RpbmcgcHJvdG9jb2wgZWxlbWVudCBuYW1lcyB1bmxlc3Mgb3ZlcndoZWxtaW5nIHdvcmtp bmcgZ3JvdXAgc2VudGltZW50IGVtZXJnZXMgdG8gY2hhbmdlIHRoZW0uJm5ic3A7IFRoZXkgYXJl IGFscmVhZHkgd29ya2luZyBmaW5lIGFzLWlzIGluIHByb2R1Y3Rpb24NCiBkZXBsb3ltZW50cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 Yj5TZWN0aW9uIDc8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+V2hlbiBhIGNsaWVudF9zZWNyZXQgZXhwaXJlcyBpcyBpdCB0aGUgaW50ZW50IHRoYXQg Y2xpZW50cyBkbyBhbiB1cGRhdGUgb3IgcmVmcmVzaCB0byBnZXQgYSBuZXcgY2xpZW50IHNlY3Jl dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlllcywgdGhl IGNsaWVudCBpcyBzdXBwb3NlZCB0byBlaXRoZXIgY2FsbCB0aGUgcmVhZCBvciB1cGRhdGUgbWV0 aG9kcyBvbiB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24gZW5kcG9pbnQgdG8gZ2V0IGl0cyBuZXcg c2VjcmV0LiBBcyBkaXNjdXNzZWQgYWJvdmUsIEknbSBub3Qgc3VyZSB0aGF0J3MgYXMgY2xlYXIg YXMgaXQgbmVlZHMgdG8gYmUsIGFuZCBJIHdlbGNvbWUNCiBzdWdnZXN0aW9ucyBvbiBob3cgdG8g Y2xhcmlmeSB0aGlzLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkVpdGhl ciBpcyBhIHJlYXNvbmFibGUgYmVoYXZpb3Igb24gdGhlIGJlaGFsZiBvZiBjbGllbnRzLCBkZXBl bmRpbmcgdXBvbiBjb250ZXh0LiZuYnNwOyBJIHN1cHBvcnQgYWRkaW5nIHRleHQgdG8gY2xhcmlm eSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWdhaW4sIHRoYW5rcyBmb3Ig dGhlIHZlcnkgdGhvcm91Z2ggcmVhZCB0aHJvdWdoLiBIYXZlIHlvdSBpbXBsZW1lbnRlZCBhbnkg b2YgdGhlIHNwZWMgeWV0LCBlaXRoZXIgYXMtaXMgb3Igd2l0aCBhbnkgb2YgeW91ciBzdWdnZXN0 ZWQgY2hhbmdlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+WWVzLiBNdWNoIG9mIHRoZSBmZWVkYmFjayBpcyBjb21pbmcgZnJv bSBvdXIgZGV2ZWxvcG1lbnQgY29tbXVuaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BaCwgdmVyeSBjb29sLiBE ZXZlbG9wZXIgZXhwZXJpZW5jZSBpcyB0aGUgbW9zdCB2YWx1YWJsZSBmZWVkYmFjaywgaW4gbXkg b3Bpbmlvbi4gSWYgeW91IGNhbid0IGFjdHVhbGx5IGJ1aWxkIHRoZSBibGFzdGVkIHRoaW5nLCB3 aGF0IGdvb2QgaXMgaXQ/IDopPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5HbGFkIHRvIGhl YXIgdGhhdCB5b3XigJlyZSB3b3JraW5nIHdpdGggZGV2ZWxvcGVycyBidWlsZGluZyB0aGUgc3Bl Yy4mbmJzcDsgUGxlYXNlIHRoYW5rIHRoZW0gZm9yIHRoZSBmZWVkYmFjay48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw Oy0tIEp1c3RpbjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436773435CTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri May 17 13:27:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7459321F9603 for ; Fri, 17 May 2013 13:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGkIIH32JXdU for ; Fri, 17 May 2013 13:27:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9A821F8556 for ; Fri, 17 May 2013 13:27:45 -0700 (PDT) Received: from BN1AFFO11FD012.protection.gbl (10.58.52.200) by BN1AFFO11HUB027.protection.gbl (10.58.52.137) with Microsoft SMTP Server (TLS) id 15.0.687.1; Fri, 17 May 2013 20:27:29 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD012.mail.protection.outlook.com (10.58.52.72) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Fri, 17 May 2013 20:27:29 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 17 May 2013 20:26:33 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUoliz4X67XowG0mWW52R1yHjnpkI+JSwgAAJYYCAAAa3sIAAHCOAgACuEVA= Date: Fri, 17 May 2013 20:26:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677344BC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> <655FB525-6952-4517-BD4B-8ECD67F3087E@oracle.com> <4E1F6AAD24975D4BA5B168042967394367733A24@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367733D51@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.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943677344BCTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174002)(377454002)(189002)(377424003)(50854003)(164054003)(13464003)(24454002)(51704005)(199002)(77982001)(56816002)(47446002)(46102001)(81542001)(80022001)(59766001)(4396001)(31966008)(47736001)(71186001)(81342001)(16236675002)(74662001)(50986001)(69226001)(65816001)(33656001)(47976001)(16601075002)(512874002)(74502001)(74366001)(15202345002)(79102001)(15974865001)(51856001)(66066001)(54316002)(16406001)(53806001)(49866001)(76482001)(56776001)(74706001)(74876001)(54356001)(6806003)(20776003)(55846006)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB027; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 20:27:52 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943677344BCTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gc2F5aW5nIHRoYXQgd2UgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGdyYW50aW5nIGFjY2Vz cyB0byB0aGUgcmVnaXN0cmF0aW9uIHN0YXRlIGZvciB0aGUgY2xpZW50IGFuZCBhIHNlcGFyYXRl IGNsaWVudF9pZCAoYW5kIHNvbWV0aW1lcyBjbGllbnRfc2VjcmV0KSB1c2VkIGZvciBhY2Nlc3Np bmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgVGhlIGZpcnN0IGlzIHVzZWQgYnkgdGhlIHBh cnR5IHdyaXRpbmcvcmVnaXN0ZXJpbmcgdGhlIGNsaWVudC4gIFRoZSBzZWNvbmQgaXMgdXNlZCBi eSB0aGUgY2xpZW50LiAgQm90aCB0aGUgcmVzb3VyY2VzIGFjY2Vzc2VkIGFuZCB0aGUgcGFydGll cyBhY2Nlc3NpbmcgdGhlIHJlc291cmNlcyBhcmUgZGlmZmVyZW50Lg0KDQpJ4oCZbSBwdXp6bGVk IHdoeSB5b3Ugd291bGQgcHJvcG9zZSBjb21iaW5pbmcvb3ZlcmxvYWRpbmcgdGhlbSwgZ2l2ZW4g dGhlIHNlY3VyaXR5IGRpZmZlcmVuY2VzLiAgRXNwZWNpYWxseSwgSSB3b3VsZG7igJl0IHdhbnQg dG8gYmFrZSB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbnRvIHRoZSBjbGllbnQg4oCT IGVzcGVjaWFsbHkgYSBtb2JpbGUgY2xpZW50IOKAkyBiZWNhdXNlIGl0IHdvdWxkIG1lYW4gYW55 b25lIGluIHBvc3Nlc3Npb24gb2YgYW4gaW5zdGFuY2Ugb2YgdGhlIGNsaWVudCBjb3VsZCBjaGFu Z2UvZGVmYWNlL21hbGljaW91c2x5LWludGVudGlvbmFsbHktYnJlYWsgdGhlIGNsaWVudCByZWdp c3RyYXRpb24gZm9yIGFsbCBpbnN0YW5jZXMuICBXaGVyZWFzLCBJICptdXN0KiBiYWtlIHRoZSBj bGllbnRfaWQgYW5kIHBvdGVudGlhbGx5IHRoZSBjbGllbnRfc2VjcmV0IGludG8gdGhlIGNsaWVu dC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDE3LCAyMDEzIDI6NTcgQU0NClRvOiBNaWtlIEpv bmVzDQpDYzogb2F1dGhAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENsaWVu dCBDcmVkZW50aWFsIEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBk cmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMTANCg0KT3IsIGFyZSB5b3Ugc2F5aW5nIHJlZyBhY2Nl c3MgdG9rZW4gaXMgYSBzaWduZWQgYXNzZXJ0aW9uIGVjaG9pbmcgYmFjayB0aGUgcmVnaXN0cmF0 aW9uPw0KDQpJIGhhdmUgdG8gdGhpbmsgYWJvdXQgdGhhdC4gU3RpbGwgZG9uJ3Qgc2VlIHRoZSB2 YWx1ZSBzaW5jZSB0aGVyZSBzaG91bGQgYmUgb25seSBvbmUgcmVnaXN0cmF0aW9uIHBlciBjbGll bnQgY3JlZC4NCg0KVG8gbWUgdGhlIGNsaWVudCB0b2tlbiBjYW4gYWxzbyBiZSB0aGUgcmVnaXN0 cmF0aW9uIG1vcmUgZWFzaWx5IHdpdGggbGVzcyBjb21wbGV4aXR5Lg0KDQpQaGlsDQoNClBzLiBB cG9sb2dpZXMganVzdCBub3RpY2VkIEkgZGlkbid0IHJlcGx5IGFsbCB0byBncm91cCBlYXJsaWVy Lg0KDQpPbiAyMDEzLTA1LTE3LCBhdCAxOjE2LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K SSB0aGluayB5b3UgbXVzdCB1bmRlcnN0YW5kIHNvbWV0aGluZyBoZXJlLiAgVGhlIHRva2VuIGlu IHRoZSByZWdpc3RyYXRpb24gc3BlYyAqaXMqIHRoZSB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVu dCBieSB0aGUgcmVnaXN0cmF0aW9uIHNlcnZlciB0byByZXByZXNlbnQgdGhlIGNsaWVudCdzIHJl Z2lzdHJhdGlvbi4NCg0KLS0gTWlrZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFBoaWwgSHVudA0KU2VudDogNS8xNy8yMDEzIDk6NTMgQU0NClRvOiBNaWtlIEpvbmVz DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDbGllbnQgQ3JlZGVudGlhbCBFeHBpcnkgYW5kIG5l dyBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIC0gZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEw DQpXZWxsIHdoeSBub3QganVzdCB1c2UgdGhlIGNsaWVudCB0b2tlbj8NCg0KUGhpbA0KDQpPbiAy MDEzLTA1LTE3LCBhdCAwOjE5LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSXRzIG5vdCB0 aGVyZSBmb3IgcmVhc29ucyByZWxhdGVkIHRvIGV4cGlyYXRpb24uIEl0J3MgdGhlcmUgYXMgYW4g YWNjZXNzIHRva2VuIHNvIHRoZSBjbGllbnQgY2FuIGFjY2VzcyBhbmQgcG9zc2libHkgdXBkYXRl IGl0cyBjbGllbnQgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uLg0KDQotLSBNaWtlDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGhpbCBIdW50DQpTZW50OiA1LzE3LzIw MTMgMTowMiBBTQ0KVG86IE1pa2UgSm9uZXMNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENsaWVu dCBDcmVkZW50aWFsIEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBk cmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMTANClN1cmUuIEl0IGlzbid0IGEgbmV3IHRva2VuIGZv cm1hdC4gIEJ1dCBpdCBpcyB5ZXQgYW5vdGhlciB0b2tlbiB3aXRoIHNwZWNpZmljIHVzYWdlIGFu ZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KSSdtIGNvbmNlcm5lZCBhYm91dCB3aGV0aGVy IGl0IG1ha2VzIHNlbnNlIHRvIGNyZWF0ZSB5ZXRhbnV0aGVydG9rZW4ganVzdCB0byBoYW5kbGUg ZXhwaXJ5IG9mIGEgdG9rZW4gd2hvc2UgZXhwaXJ5IHdhc24ndCBjYWxsZWQgZm9yIGluIHRoZSBn cm91cCBvciBpbiB0aGUgdGhyZWF0IG1vZGVsICg2NzQ5IG9yIDY4MTkpLg0KDQpQaGlsDQoNCkBp bmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVu dGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT4NCg0KDQoNCg0KDQpPbiAyMDEzLTA1LTE2LCBhdCAzOjI2IFBNLCBNaWtlIEpvbmVzIHdyb3Rl Og0KDQo+IFRoaXMgaXMgbm90aGluZyBtb3JlIHRoYW4gYW4gUkZDIDY3NTAgYmVhcmVyIHRva2Vu LiAgVGhlc2UgY2FuIGV4cGlyZSwgYXMgZXhwbGFpbmVkIGluIHRoYXQgZHJhZnQuICAoVGhlIGNh biBhbHNvIGJlIGlzc3VlZCBhbiBhIG1hbm5lciB0aGF0IHRoZXkgZG9uJ3QgZXhwaXJlLikgIE5v dGhpbmcgbmV3IGlzIGJlaW5nIGludmVudGVkIGluIHRoaXMgcmVnYXJkLg0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBQaGlsIEh1bnQNCj4gU2VudDogVGh1cnNkYXksIE1heSAxNiwgMjAxMyAyOjM1IFBNDQo+IFRv OiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdHDQo+IFN1YmplY3Q6IFtP QVVUSC1XR10gQ2xpZW50IENyZWRlbnRpYWwgRXhwaXJ5IGFuZCBuZXcgUmVnaXN0cmF0aW9uIEFj Y2VzcyBUb2tlbiAtIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMA0KPg0KPiBBbGwsDQo+DQo+ IEluIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBkcmFmdCwgYSBuZXcgdG9rZW4gdHlwZSBpcyBk ZWZpbmVkIGNhbGxlZCB0aGUgInJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4iLiBJdHMgdXNlIGlz IGludGVuZGVkIHRvIGZhY2lsaXRhdGUgY2xpZW50cyBiZWluZyBhYmxlIHRvIHVwZGF0ZSB0aGVp ciByZWdpc3RyYXRpb24gYW5kIG9idGFpbiBuZXcgY2xpZW50IGNyZWRlbnRpYWxzIG92ZXIgdGlt ZS4gIFRoZSBjbGllbnQgY3JlZGVudGlhbCBpcyBpc3N1ZWQgb24gY29tcGxldGlvbiBvZiB0aGUg aW5pdGlhbCByZWdpc3RyYXRpb24gcmVxdWVzdCBieSBhIHBhcnRpY3VsYXIgY2xpZW50IGluc3Rh bmNlLg0KPg0KPiBJdCBhcHBlYXJzIHRoZSBuZWVkIGZvciB0aGUgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiBhcmlzZXMgZnJvbSB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhhdCBjbGllbnQgY3Jl ZGVudGlhbHMgc2hvdWxkIGV4cGlyZS4NCj4gLS0+IElzIGFueW9uZSBleHBpcmluZyBjbGllbnQg Y3JlZGVudGlhbHM/DQo+DQo+IFRvIGRhdGUsIHdlIGhhdmVuJ3QgaGFkIG11Y2ggZGlzY3Vzc2lv biBhYm91dCBjbGllbnQgY3JlZGVudGlhbCBleHBpcnkuIEl0IGxlYWRzIG1lIHRvIHRoZSBmb2xs b3dpbmcgcXVlc3Rpb25zOg0KPg0KPiAxLiAgSXMgdGhlcmUgdGVjaG5pY2FsIHZhbHVlIHdpdGgg Y2xpZW50IGNyZWRlbnRpYWwvdG9rZW4gZXhwaXJ5PyAgS2VlcCBpbiBtaW5kIHRoYXQgY2xpZW50 IGNyZWRlbnRpYWwgaXMgb25seSB1c2VkIHdpdGggdGhlIHRva2VuIGVuZHBvaW50IG92ZXIgVExT IGNvbm5lY3Rpb24uIEl0IGlzIE5PVCB1c2VkIHRvIGFjY2VzcyByZXNvdXJjZXMgZGlyZWN0bHku DQo+DQo+IDIuICBJZiB5ZXMsIG9uIHdoYXQgYmFzaXMgc2hvdWxkIGNsaWVudCBjcmVkZW50aWFs L3Rva2VuIGV4cGlyZT8NCj4gIGEuICBUaW1lPw0KPiAgYi4gIEEgY2hhbmdlIHRvIHRoZSBjbGll bnQgc29mdHdhcmUgKGUuZy4gdmVyc2lvbiB1cGRhdGUpPw0KPiAgYy4gIFNvbWUgb3RoZXIgcmVh c29uPw0KPg0KPiAzLiBJcyBpdCB3b3J0aCB0aGUgY29tcGxpY2F0aW9uIHRvIGNyZWF0ZSBhIG5l dyB0b2tlbiB0eXBlIChyZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuKSBqdXN0IHRvIGFsbG93IGNs aWVudHMgdG8gb2J0YWluIG5ldyBjbGllbnQgdG9rZW5zPyAgS2VlcCBpbiBtaW5kIHRoYXQgY2xp ZW50IHRva2VucyBhcmUgb25seSB1c2FibGUgd2l0aCB0aGUgQVMgdG9rZW4gZW5kcG9pbnQuICBX aHkgbm90IGluc3RlYWQgdXNlIGEgY2xpZW50IHRva2VuIGZvciBkeW4gcmVnIGFuZCB0b2tlbiBl bmRwb2ludCB3aXRoIHRoZSBydWxlIHRoYXQgb25jZSBhIGNsaWVudCB0b2tlbiBoYXMgZXhwaXJl ZCAoaWYgdGhleSBleHBpcmUpLCBhbiBleHBpcmVkIHRva2VuIG1heSBzdGlsbCBiZSB1c2VkIGF0 IHRoZSByZWdpc3RyYXRpb24gZW5kLXBvaW50Lg0KPg0KPiA0LiBBcmUgdGhlcmUgb3RoZXIgcmVh c29ucyBmb3IgdGhlIHJlZ2lzdHJhdGlvbiB0b2tlbj8NCj4NCj4gVGhhbmtzLA0KPg0KPiBQaGls DQo+DQo+IEBpbmRlcGVuZGVudGlkDQo+IHd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tPg0KPiBwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_4E1F6AAD24975D4BA5B1680429673943677344BCTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRp di5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDoxLjBwdDsNCglib3JkZXI6bm9uZTsNCglwYWRkaW5nOjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIHNheWluZyB0aGF0 IHdlIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBncmFudGluZyBhY2Nlc3MgdG8gdGhlIHJlZ2lzdHJh dGlvbiBzdGF0ZSBmb3IgdGhlIGNsaWVudCBhbmQgYSBzZXBhcmF0ZSBjbGllbnRfaWQgKGFuZCBz b21ldGltZXMgY2xpZW50X3NlY3JldCkgdXNlZA0KIGZvciBhY2Nlc3NpbmcgdGhlIEF1dGhvcml6 YXRpb24gU2VydmVyLiZuYnNwOyBUaGUgZmlyc3QgaXMgdXNlZCBieSB0aGUgcGFydHkgd3JpdGlu Zy9yZWdpc3RlcmluZyB0aGUgY2xpZW50LiZuYnNwOyBUaGUgc2Vjb25kIGlzIHVzZWQgYnkgdGhl IGNsaWVudC4mbmJzcDsgQm90aCB0aGUgcmVzb3VyY2VzIGFjY2Vzc2VkIGFuZCB0aGUgcGFydGll cyBhY2Nlc3NpbmcgdGhlIHJlc291cmNlcyBhcmUgZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0g cHV6emxlZCB3aHkgeW91IHdvdWxkIHByb3Bvc2UgY29tYmluaW5nL292ZXJsb2FkaW5nIHRoZW0s IGdpdmVuIHRoZSBzZWN1cml0eSBkaWZmZXJlbmNlcy4mbmJzcDsgRXNwZWNpYWxseSwgSSB3b3Vs ZG7igJl0IHdhbnQgdG8gYmFrZSB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbg0KIGludG8g dGhlIGNsaWVudCDigJMgZXNwZWNpYWxseSBhIG1vYmlsZSBjbGllbnQg4oCTIGJlY2F1c2UgaXQg d291bGQgbWVhbiBhbnlvbmUgaW4gcG9zc2Vzc2lvbiBvZiBhbiBpbnN0YW5jZSBvZiB0aGUgY2xp ZW50IGNvdWxkIGNoYW5nZS9kZWZhY2UvbWFsaWNpb3VzbHktaW50ZW50aW9uYWxseS1icmVhayB0 aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBmb3IgYWxsIGluc3RhbmNlcy4mbmJzcDsgV2hlcmVhcywg SSAqPGI+bXVzdDwvYj4qIGJha2UgdGhlIGNsaWVudF9pZA0KIGFuZCBwb3RlbnRpYWxseSB0aGUg Y2xpZW50X3NlY3JldCBpbnRvIHRoZSBjbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDE3LCAyMDEzIDI6NTcgQU08 YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3Jn IFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENsaWVudCBDcmVkZW50aWFs IEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBkcmFmdC1pZXRmLW9h dXRoLWR5bi1yZWctMTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T3IsIGFyZSB5b3Ugc2F5aW5nIHJlZyBhY2Nlc3MgdG9rZW4gaXMgYSBzaWdu ZWQgYXNzZXJ0aW9uIGVjaG9pbmcgYmFjayB0aGUgcmVnaXN0cmF0aW9uPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgdG8gdGhpbmsg YWJvdXQgdGhhdC4gU3RpbGwgZG9uJ3Qgc2VlIHRoZSB2YWx1ZSBzaW5jZSB0aGVyZSBzaG91bGQg YmUgb25seSBvbmUgcmVnaXN0cmF0aW9uIHBlciBjbGllbnQgY3JlZC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbWUgdGhlIGNs aWVudCB0b2tlbiBjYW4gYWxzbyBiZSB0aGUgcmVnaXN0cmF0aW9uIG1vcmUgZWFzaWx5IHdpdGgg bGVzcyBjb21wbGV4aXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcy4gQXBvbG9naWVzIGp1c3Qgbm90aWNlZCBJIGRp ZG4ndCByZXBseSBhbGwgdG8gZ3JvdXAgZWFybGllci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gMjAxMy0wNS0xNywgYXQgMToxNiwgTWlrZSBKb25lcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgdGhpbmsgeW91IG11c3QgdW5k ZXJzdGFuZCBzb21ldGhpbmcgaGVyZS4mbmJzcDsgVGhlIHRva2VuIGluIHRoZSByZWdpc3RyYXRp b24gc3BlYyAqaXMqIHRoZSB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgcmVnaXN0 cmF0aW9uIHNlcnZlcg0KIHRvIHJlcHJlc2VudCB0aGUgY2xpZW50J3MgcmVnaXN0cmF0aW9uLjxi cj4NCjxicj4NCi0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlBoaWwgSHVudDwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+U2VudDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij41LzE3LzIwMTMgOTo1MyBBTTwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1pa2UgSm9u ZXM8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1YmplY3Q6IDwv c3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtPQVVUSC1XR10gQ2xp ZW50IENyZWRlbnRpYWwgRXhwaXJ5IGFuZCBuZXcgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiAt IGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VsbCB3aHkgbm90IGp1c3QgdXNlIHRoZSBj bGllbnQgdG9rZW4/ICZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KT24gMjAxMy0wNS0xNywgYXQgMDoxOSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdHMgbm90IHRoZXJlIGZv ciByZWFzb25zIHJlbGF0ZWQgdG8gZXhwaXJhdGlvbi4gSXQncyB0aGVyZSBhcyBhbiBhY2Nlc3Mg dG9rZW4gc28gdGhlIGNsaWVudCBjYW4gYWNjZXNzIGFuZCBwb3NzaWJseSB1cGRhdGUgaXRzIGNs aWVudCByZWdpc3RyYXRpb24NCiBpbmZvcm1hdGlvbi48YnI+DQo8YnI+DQotLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsIEh1 bnQ8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NS8xNy8yMDEzIDE6MDIgQU08L3Nw YW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NaWtlIEpvbmVzPC9zcGFuPjxicj4NCjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlJlOiBbT0FVVEgtV0ddIENsaWVudCBDcmVkZW50aWFsIEV4cGlyeSBh bmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBkcmFmdC1pZXRmLW9hdXRoLWR5bi1y ZWctMTA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5TdXJlLiBJdCBpc24ndCBhIG5ldyB0b2tlbiBmb3JtYXQuJm5ic3A7IEJ1dCBp dCBpcyB5ZXQgYW5vdGhlciB0b2tlbiB3aXRoIHNwZWNpZmljIHVzYWdlIGFuZCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucy48YnI+DQo8YnI+DQpJJ20gY29uY2VybmVkIGFib3V0IHdoZXRoZXIgaXQg bWFrZXMgc2Vuc2UgdG8gY3JlYXRlIHlldGFudXRoZXJ0b2tlbiBqdXN0IHRvIGhhbmRsZSBleHBp cnkgb2YgYSB0b2tlbiB3aG9zZSBleHBpcnkgd2Fzbid0IGNhbGxlZCBmb3IgaW4gdGhlIGdyb3Vw IG9yIGluIHRoZSB0aHJlYXQgbW9kZWwgKDY3NDkgb3IgNjgxOSkuPGJyPg0KPGJyPg0KUGhpbDxi cj4NCjxicj4NCkBpbmRlcGVuZGVudGlkPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxicj4NCjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxMy0wNS0xNiwgYXQgMzoyNiBQTSwgTWlr ZSBKb25lcyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IFRoaXMgaXMgbm90aGluZyBtb3JlIHRoYW4g YW4gUkZDIDY3NTAgYmVhcmVyIHRva2VuLiZuYnNwOyBUaGVzZSBjYW4gZXhwaXJlLCBhcyBleHBs YWluZWQgaW4gdGhhdCBkcmFmdC4mbmJzcDsgKFRoZSBjYW4gYWxzbyBiZSBpc3N1ZWQgYW4gYSBt YW5uZXIgdGhhdCB0aGV5IGRvbid0IGV4cGlyZS4pJm5ic3A7IE5vdGhpbmcgbmV3IGlzIGJlaW5n IGludmVudGVkIGluIHRoaXMgcmVnYXJkLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs ZiBPZiBQaGlsIEh1bnQ8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMjoz NSBQTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA aWV0Zi5vcmc8L2E+IFdHPGJyPg0KJmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIENsaWVudCBDcmVk ZW50aWFsIEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBkcmFmdC1p ZXRmLW9hdXRoLWR5bi1yZWctMTA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxsLDxicj4NCiZndDsg PGJyPg0KJmd0OyBJbiB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gZHJhZnQsIGEgbmV3IHRva2Vu IHR5cGUgaXMgZGVmaW5lZCBjYWxsZWQgdGhlICZxdW90O3JlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9r ZW4mcXVvdDsuIEl0cyB1c2UgaXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZSBjbGllbnRzIGJlaW5n IGFibGUgdG8gdXBkYXRlIHRoZWlyIHJlZ2lzdHJhdGlvbiBhbmQgb2J0YWluIG5ldyBjbGllbnQg Y3JlZGVudGlhbHMgb3ZlciB0aW1lLiZuYnNwOyBUaGUgY2xpZW50IGNyZWRlbnRpYWwgaXMNCiBp c3N1ZWQgb24gY29tcGxldGlvbiBvZiB0aGUgaW5pdGlhbCByZWdpc3RyYXRpb24gcmVxdWVzdCBi eSBhIHBhcnRpY3VsYXIgY2xpZW50IGluc3RhbmNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCBh cHBlYXJzIHRoZSBuZWVkIGZvciB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBhcmlzZXMg ZnJvbSB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhhdCBjbGllbnQgY3JlZGVudGlhbHMgc2hvdWxk IGV4cGlyZS4NCjxicj4NCiZndDsgLS0mZ3Q7IElzIGFueW9uZSBleHBpcmluZyBjbGllbnQgY3Jl ZGVudGlhbHM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvIGRhdGUsIHdlIGhhdmVuJ3QgaGFkIG11 Y2ggZGlzY3Vzc2lvbiBhYm91dCBjbGllbnQgY3JlZGVudGlhbCBleHBpcnkuIEl0IGxlYWRzIG1l IHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjxicj4NCiZndDsgPGJyPg0KJmd0OyAxLiZuYnNw OyBJcyB0aGVyZSB0ZWNobmljYWwgdmFsdWUgd2l0aCBjbGllbnQgY3JlZGVudGlhbC90b2tlbiBl eHBpcnk/Jm5ic3A7IEtlZXAgaW4gbWluZCB0aGF0IGNsaWVudCBjcmVkZW50aWFsIGlzIG9ubHkg dXNlZCB3aXRoIHRoZSB0b2tlbiBlbmRwb2ludCBvdmVyIFRMUyBjb25uZWN0aW9uLiBJdCBpcyBO T1QgdXNlZCB0byBhY2Nlc3MgcmVzb3VyY2VzIGRpcmVjdGx5Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyAyLiZuYnNwOyBJZiB5ZXMsIG9uIHdoYXQgYmFzaXMgc2hvdWxkIGNsaWVudCBjcmVkZW50aWFs L3Rva2VuIGV4cGlyZT88YnI+DQomZ3Q7Jm5ic3A7IGEuJm5ic3A7IFRpbWU/PGJyPg0KJmd0OyZu YnNwOyBiLiZuYnNwOyBBIGNoYW5nZSB0byB0aGUgY2xpZW50IHNvZnR3YXJlIChlLmcuIHZlcnNp b24gdXBkYXRlKT88YnI+DQomZ3Q7Jm5ic3A7IGMuJm5ic3A7IFNvbWUgb3RoZXIgcmVhc29uPzxi cj4NCiZndDsgPGJyPg0KJmd0OyAzLiBJcyBpdCB3b3J0aCB0aGUgY29tcGxpY2F0aW9uIHRvIGNy ZWF0ZSBhIG5ldyB0b2tlbiB0eXBlIChyZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuKSBqdXN0IHRv IGFsbG93IGNsaWVudHMgdG8gb2J0YWluIG5ldyBjbGllbnQgdG9rZW5zPyZuYnNwOyBLZWVwIGlu IG1pbmQgdGhhdCBjbGllbnQgdG9rZW5zIGFyZSBvbmx5IHVzYWJsZSB3aXRoIHRoZSBBUyB0b2tl biBlbmRwb2ludC4mbmJzcDsgV2h5IG5vdCBpbnN0ZWFkIHVzZSBhIGNsaWVudCB0b2tlbiBmb3IN CiBkeW4gcmVnIGFuZCB0b2tlbiBlbmRwb2ludCB3aXRoIHRoZSBydWxlIHRoYXQgb25jZSBhIGNs aWVudCB0b2tlbiBoYXMgZXhwaXJlZCAoaWYgdGhleSBleHBpcmUpLCBhbiBleHBpcmVkIHRva2Vu IG1heSBzdGlsbCBiZSB1c2VkIGF0IHRoZSByZWdpc3RyYXRpb24gZW5kLXBvaW50Ljxicj4NCiZn dDsgPGJyPg0KJmd0OyA0LiBBcmUgdGhlcmUgb3RoZXIgcmVhc29ucyBmb3IgdGhlIHJlZ2lzdHJh dGlvbiB0b2tlbj88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgPGJyPg0K Jmd0OyBQaGlsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEBpbmRlcGVuZGVudGlkPGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5j b208L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943677344BCTK5EX14MBXC283r_-- From donald.coffin@reminetworks.com Fri May 17 13:53:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56121F96A9 for ; Fri, 17 May 2013 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZjbBbYDMW9y for ; Fri, 17 May 2013 13:53:06 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 77E8821F96A2 for ; Fri, 17 May 2013 13:53:04 -0700 (PDT) Received: (qmail 20283 invoked by uid 0); 17 May 2013 20:32:00 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 17 May 2013 20:32:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=58W5jjwQz7ouOGmAE6WLkAdkC3PMQsGQrUQBmRmnWI8=; b=KznXrQN0ZAR/T/xH63M3wNgNCOQ27p5YrXNSKs2jBoSHkBF4kjgamAja1lL4Qq89EhJSz6gkvblPh4vPM1QwxFvxokvHcxkL2zgmWZTB/5VwG9EDhvwT45YbfVnwbPNI; Received: from [68.4.207.246] (port=2508 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UdRJn-00048c-ND; Fri, 17 May 2013 14:31:59 -0600 From: "Donald F Coffin" To: "'Phil Hunt'" References: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> <015101ce532f$d9e75d70$8db61850$@reminetworks.com> <57F130F2-AE65-4B78-A7B4-797965285067@oracle.com> In-Reply-To: <57F130F2-AE65-4B78-A7B4-797965285067@oracle.com> Date: Fri, 17 May 2013 13:30:11 -0700 Message-ID: <019a01ce533d$54cb4080$fe61c180$@reminetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGc2XTV0stTXKINHA5eqQN7Dtb7MgNZWJg/Ac33NBwCxRi/1pktY6aQ Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 20:53:11 -0000 Phil, That is true. All I am saying is the client may use the client_credential access token to access groups of authorizations which have been granted based on the client grant request and thus does have access to resources. Your initial post said the client_credential grant cannot be used to access resources, which IMHO is incorrect based on the RFC 6749 definition in section 4.4. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Friday, May 17, 2013 12:01 PM To: Donald F Coffin Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 That is incorrect. A client grant request still results in a separate access token issued. Phil On 2013-05-17, at 11:53, Donald F Coffin wrote: > The statement "Keep in mind that client credential is only used with > the token endpoint over TLS connection. It is NOT used to access > resources directly." is incorrect. Section 4.4 of RFC 6749 states: > > The client can request an access token using only its client > credentials (or other supported means of authentication) when the > client is requesting access to the protected > resources under its control, or those of another resource owner > that have been previously arranged with the authorization server (the > method of which is beyond the scope > of this specification). > > I have interpreted section 4.4 to imply that a client who has been > granted access to resources via an authorization code, for example, > may use their client credentials to access either a single resource or > multiple resources for which they have been granted access. > Although it is possible to never expire an access token obtained using > client credentials, I believe not expiring the token, since it allows > access to resources, is not desirable from a security stand point. > > On the other hand, the registration_access_token clearly will not > allow a client to access any resources and can only be used with > client application information. > > Best regards, > Don > Donald F. Coffin > Founder/CTO > > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 > > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, May 16, 2013 3:27 PM > To: Phil Hunt; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration > Access Token - draft-ietf-oauth-dyn-reg-10 > > This is nothing more than an RFC 6750 bearer token. These can expire, > as explained in that draft. (The can also be issued an a manner that > they don't expire.) Nothing new is being invented in this regard. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, May 16, 2013 2:35 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Client Credential Expiry and new Registration > Access Token - draft-ietf-oauth-dyn-reg-10 > > All, > > In the dynamic registration draft, a new token type is defined called > the "registration access token". Its use is intended to facilitate > clients being able to update their registration and obtain new client > credentials over time. The client credential is issued on completion > of the initial registration request by a particular client instance. > > It appears the need for the registration access token arises from the > implied assertion that client credentials should expire. > --> Is anyone expiring client credentials? > > To date, we haven't had much discussion about client credential > expiry. It leads me to the following questions: > > 1. Is there technical value with client credential/token expiry? > Keep in mind that client credential is only used with the token > endpoint over TLS connection. It is NOT used to access resources directly. > > 2. If yes, on what basis should client credential/token expire? > a. Time? > b. A change to the client software (e.g. version update)? > c. Some other reason? > > 3. Is it worth the complication to create a new token type > (registration access token) just to allow clients to obtain new client > tokens? Keep in mind that client tokens are only usable with the AS > token endpoint. Why not instead use a client token for dyn reg and > token endpoint with the rule that once a client token has expired (if > they expire), an expired token may still be used at the registration end-point. > > 4. Are there other reasons for the registration token? > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From phil.hunt@oracle.com Fri May 17 14:24:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D749D21F96C3 for ; Fri, 17 May 2013 14:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMHPBoX3f2AQ for ; Fri, 17 May 2013 14:24:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3C21F949A for ; Fri, 17 May 2013 14:24:34 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4HLOUpJ023243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 21:24:31 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HLOVt2015998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 21:24:31 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HLOUgs005199; Fri, 17 May 2013 21:24:30 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 14:24:29 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3C6CBDC-3723-486C-B20A-078990575F38" From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 17 May 2013 14:24:27 -0700 Message-Id: <80E6C4AC-5402-43E3-A6A2-0A98595F7203@oracle.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 21:24:41 -0000 --Apple-Mail=_E3C6CBDC-3723-486C-B20A-078990575F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have started a separate thread on having dyn reg correlate client = software. My other comments are embedded marked with [PH]. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 1:08 PM, Mike Jones wrote: > Thanks for the detailed feedback, Phil. Sorry for the delayed = response =E2=80=93 I was pretty fully engaged at the European Identity = Conference (where OAuth 2.0 won the award for best new standard J). My = feedback on the points raised is inline in green=E2=80=A6 > =20 > (Perhaps if any of you reply to this thread, you could also choose a = distinct color for your inline replies, so that it will be easily = evident who said what. As it is, just the back-and-forth between Phil = and Justin is already very difficult to follow. Thanks.) > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, May 16, 2013 12:54 PM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 > =20 > Justin, > =20 > Thanks for the discussion. More comments below... > =20 > BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > =20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: > =20 > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > =20 > Phil, many thanks for the extremely thorough review! It is very useful = indeed.=20 > =20 > My comments and responses to each point are inline.=20 > =20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: > =20 > It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. > =20 > Overall =20 > ----------- > I think dynamic registration is a critical part of the OAuth framework = now that we are starting to consider how individual client applications = should operate when there is one or more deployments of a particular = resource API. We've moved from the simple use case of a single API = provider like Facebook or Flickr and moved on to standards based, open = source based, and commercial based deployments where there are multiple = service endpoints and many clients to manage. > =20 > The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: > =20 > 1. How is a new client application recognized for the first time when = deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? > =20 > In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 > =20 > I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. > =20 > But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? > =20 > I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) > =20 > I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. > =20 > In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. > =20 > What the UUID does is link multiple instances of a client app together = as the same "thing" that should have similar heuristics/behaviours. = This is very useful if you want to be able to revoke access to a set of = clients identified by application id (or a version of that app). > =20 > While I=E2=80=99m sympathetic to the OAuth working group eventually = doing work on differentiating between instances of an OAuth client, = I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as = a client instance. There are only clients, which are identified by = client_id values. If we want to do work on client instances, we should = recharter to add this new work as a working group deliverable. We = should not try to shoehorn bits and pieces of it into the Dynamic = Registration spec, any more than we should have tried to shoehorn it = into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients = as defined in RFC 6749. It=E2=80=99s not the right place to extend what = an OAuth client is in new ways. [PH] See new thread I have begun. > =20 > 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? > =20 > The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 > Something like this should be in the draft. > =20 > Should this be up in the introductory text, somewhere else, or have = its own section? > =20 > I'm starting to think credential management is a key part of the = draft. It may be worth introducing a specific section outling the = registration life-cycle, registration access token usage, and client = token usage and bootstrapping. > =20 > I think that adding a discussion on this would be fine, as it could = help developers understand the workflow of registering, using, and = updating registered clients. > =20 > How does a client authenticate the first time and subsequent times to = the registration service? > =20 > This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: > - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. > =20 > Subsequent times that the same registered client (by which we mean the = same instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. > =20 > Something like this should be in the draft. > =20 > OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer. > =20 > See the discussion on what the registration_access_token is in the = thread =E2=80=9CClient Credential Expiry and new Registration Access = Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin = to apply these clarifications to the specification. This may go into = the proposed credential management overview section discussed above. > =20 > 3. How is versioning of clients managed? Should each new version of a = client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. > =20 > This is up to the AS, really, and I don't think that any global policy = would ever fly here. Especially if you consider that the entire notion = of "version" is more fluid these days than it ever has been. I wouldn't = mind adding a discussion in the security considerations if it merits = mentioning though, so that we can help both client developers and server = developers institute reasonably good policy. > =20 > I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. Since you = have an update are clients expected to update /re-register or not? I'm = not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. > =20 > If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= > I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. > =20 > I think this may be just a case of letting people exchange credentials = for whatever reason they feel is appropriate. The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register". Depending on the policy of the server, it may = (or may not) receive a new client_id and/or new credential. =20 > =20 > One of the best benefits I can think of is if you discover a version = of a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ > =20 > Again, RFC 6749 defines no client instances or groups of clients, = therefore I believe that it=E2=80=99s inappropriate to do so here. We = don=E2=80=99t need to boil the ocean. If a new charter item is approved = to do work on client instances and protocol elements to use and express = them, that=E2=80=99s the time for the working group to consider that = possibility =E2=80=93 not as part of Dynamic Client Registration. [PH] We disagree strongly here. I think it is well within charter and = in fact if such a new charter item were developed we would be quickly = moving to replace dyn reg version 2. > =20 > 4. What is the registration access token? Why is is used? What is its = life-cycle? When is it issued, when is it changed? When is it deleted? > =20 > See the response above above and the definition in =C2=A71.2:=20 > =20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. > =20 > If this can be clarified, I welcome text suggestions. > =20 > The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. > =20 > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > =20 > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL = for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > =20 > o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > =20 > This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? > =20 > Probably this is more a matter of style. But, what happened for me is = I naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? > =20 > If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. > =20 > When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. > =20 > I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? > =20 > We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. > =20 > I haven't heard a reason justifying this parameter other then "it is = needed". Why? > =20 > The role of the dynamic registration protocol is twofold: half of that = is the server informing the client what it must do. But the other half = is the client informing the server what it *can* do, or what it *wants* = to do.=20 > =20 > And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 > =20 > I think we've discussed how recognizing subsequent instances is easily = done. > =20 > As I mentioned in the other thread, if a developer chooses to limit = the capabilities of the client it must do so by looking to the developer = or standard behind the API. Otherwise they are taking the chance. = There's no way a developer can query all the potential deployers to ask = what authn types will you use. As I said, the net effect in the absence = of an API standard dictating what should be supported, the developer = will have to implement all methods. > =20 > My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? > =20 > And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. > =20 > Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. > =20 > See my previous comments on differentiating client instances being out = of scope without rechartering to do this new work and on what the = registration_access_token is. In short, the registration_access_token = is an RFC 6750 bearer token issued to the party registering the client, = enabling it to subsequently retrieve information about the client = registration and to potentially update the registration information for = that registered client. Again, I=E2=80=99ll work with Justin to make = sure that this is as clear as possible in the specification. > =20 > Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? > =20 > That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. > =20 > Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 > =20 > One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. > =20 > There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 > =20 > If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. > =20 > ETags seem like an unnecessary addition (and potential complication) = to the specification. It=E2=80=99s already working fine as-is. > =20 > Specific items: > --------------------- > "token_endpoint_auth_method" > =20 > There is some confusion as to whether this applies to server or client = authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" > =20 > This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. > =20 > The question was raised to me by some new developers. It seems obvious = to us as experienced OAuth persons, but to new developers it seems = unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) > =20 > Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to. > =20 > I agree with Justin here. I=E2=80=99m fine clarifying the description = of this parameter to resolve the potential ambiguities that you cite, = Phil. I=E2=80=99m not OK revising the syntax without a compelling = reason to do so. [PH] I don't think we're changing any syntax here. Just clarifying the = name. This seems important now that there are 3 types of tokens being = managed (registration, client, access). =20 I would much prefer just dumping the registration access token rather = then renaming parameters that would otherwise be unclear. > =20 > * Currently, the API only supports a single value instead of an array. = If the purpose is to allow the client to know what auth methods it = supports, this should be an array indicated what methods the client = supports - or it should not be used. > =20 > I would rather like this to be an array, personally, and brought it up = with the OpenID Connect working group about six months ago. But there it = was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. > =20 > I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method = based on its own policy. >=20 > Also note that this field, like all others in =C2=A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. > =20 > This is the heart of my objection. This fuzziness is is going to lead = to interop issues. > =20 > There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 > =20 > The inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. = If an implementer assumes singular and clients assume multiple, we have = issues. > =20 > The multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written. The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification. I strongly believe that we need to add a = clear statement to this effect in the introduction to the specification. > =20 > The purpose of the Dynamic Client Registration specification is for = the client to register with the Authorization Server and to inform it of = properties of the client that the AS may want/need to be aware of. It = *is not* the purpose of this specification for it to be used by clients = in any manner to discover features of the Authorization Server. That = should be explicitly out of scope. [PH] Agreed. > =20 > Currently, clients are instructed by RFC 6749 to discover information = about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and = 3.2). They can also learn information about Authorization Servers in = specific contexts through discovery protocols such as OpenID Connect = Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) = and UMA Discovery (TBD). > =20 > I suspect that at some point, someone in the OAuth working group will = propose developing a generic OAuth discovery mechanism, which will lead = to a rechartering to include this work in the working group=E2=80=99s = set of deliverables. I would support doing this work and the necessary = rechartering to do so. [PH] So, given the above, the client shouldn't be dictating token type. = The AS should simply assign the credential and inform the client what it = must use. We agree, no discovery. But I also want to eliminate negotiation that = doesn't actually help anything. > =20 > That being said, I strongly oppose trying to shoehorn piecemeal = aspects of discovery into the Dynamic Client Registration specification. = It is distinct functionality and deserves first-class and separable = treatment by the working group. Discovery is for potential clients to = learn properties of the AS before registration. Registration is for = potential clients to inform the AS of its properties, creating a = registered client. Discovery sends information about the AS to the = Client. Registration sends information about the Client to the AS. = That=E2=80=99s a clean separation. We should strongly resist muddying = the two functions. > =20 > OAuth 2.0 is a success because it didn=E2=80=99t try to boil the = ocean. It specified how to do one thing well in a simple, web-friendly = manner. We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this work. > =20 > I apologize at this point on behalf of myself and the other spec = editors for not being 100% clear that discovery functionality is = explicitly out of scope for Dynamic Client Registration. If we had done = so, I=E2=80=99m sure that many of the current questions and confusions = would not have arisen. I think we=E2=80=99d assumed that this was = obvious, but from the current discussions, it=E2=80=99s apparent that = it=E2=80=99s not obvious. I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion. > =20 > Getting back to the specifics, the only useful purpose of a = multi-valued =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member = would be to enable the client to discover information about the = authentication methods supported by the AS after the registration had = been performed. But that is a discovery function, and so should be part = of the discovery work =E2=80=93 not this specification. We should = resist shoehorning in bits of discovery into this specification. It = *is* a worthwhile topic, but deserves full consideration by the working = group in its own right. Therefore, this member must remain = single-valued, and be clearly specified as the method by which a client = informs the AS which token endpoint authentication method it will use. = Anything else would be scope creep, and result in an unnecessarily = complicated specification and unnecessarily complicated clients. [PH] Agreed. Let's remove the parameter.in the request. It should only = be in the response. > =20 > * There is no authn method for "client_secret_saml" or = "private_key_saml". > =20 > Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? > =20 > I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. > =20 > There are no profiles referenced or defined for "client_secret_jwt" or = "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced = cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. > =20 > The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. > =20 > Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) > =20 > Regardless, you are introducing a new profile which is undefined. > =20 > I think I see the point that you're making now, let me try to re-state = it: > =20 > While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). > =20 > I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. > =20 > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors = made is they assumed everyone had the same definition of bearer token. = To me a bearer token opaque to the client. It therefore cannot do any = signature work with regards to the token itself. Now, that's not to say = a proof didn't occur between the client and the token issuer, but when = the client wields the token, it is handling an opaque string. > =20 > The concept of client_secret_jwt suggests an HoK profile. Therefore = of course the bearer drafts are a little underspecified when it comes to = HoK profiles. > =20 > So for example, you need a draft like the MAC draft for this.=20 > =20 > I'm having trouble overall here. It seems the authn types suggest ONLY = strong authentication for clients, yet during the registration process = the current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way). If you haven't authenticated = the software at all, why have strong client auth? > =20 > There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. > =20 > I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. > =20 > 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. > =20 > What you are describing is not bearer. It is holder of key. Very very = different.=20 >=20 > A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. > =20 > That's possible, but they are in active use already.=20 > =20 > That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. > =20 > This much I agree with. > =20 > Justin, John, and I discussed this issue and agree with your = suggestion, Phil. Since they are not completely specified, we will = remove the client_secret_jwt and private_key_jwt methods from the = specification and add a registry, enabling specification that do fully = specify these and other token endpoint authentication methods, including = potential methods using SAML assertions, to register them in the = registry, rather than trying to bake them into the Dynamic Client = Registration specification. > =20 > About "tos_uri" and "policy_uri" > =20 > The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? > =20 > Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. > =20 > Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. > =20 > OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) > =20 > I support clarifying the language on these definitions, and will work = with Justin to do so. > =20 > Also, aren't these really URIs or are they meant to be URLs? > =20 > There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. > =20 > Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. > =20 > That's fair, and it's something that the AS can even check if it wants = to. > =20 > Agreed on this clarification. > =20 > About "jwks_uri" > =20 > A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 > =20 > Yes, you're correct, I'll add that. > =20 > Should be URL instead of URI? > =20 > See above. :) > =20 > Agreed on adding this reference. > =20 > Section 2.1 > =20 > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > is missing. > =20 > It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? > ' > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > =20 > Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. > =20 > =E2=80=9CAs such, a server supporting these fields SHOULD take steps = to ensure that a client cannot register itself into an inconsistent = state.=E2=80=9D >=20 > We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? > =20 > I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. > =20 > I *think* that this goes away with the deletion of client_secret_jwt = and private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a = consistency check and verify that when the spec is updated accordingly. [PH] Agreed. > =20 > Section 2.2 > =20 > May want to add: > =20 > When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. > =20 > That seems inconsistent with what we already have: > =20 > If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. > =20 > Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. > =20 > I will discuss with our developers. I'm not sure the as-is works. =20 > =20 > Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? > =20 > Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? > =20 > =20 > No, the client should pass parameters as multiple separate values. = Connect has this in its example: > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) > =20 > An example would definitely help. > If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. > =20 > Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 > =20 > I think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text. > =20 > Is the reason you are passing multiple localizations is so that you = can use the preferred language of the resource owner rather then the = client user? I wonder if that is correct. If the language preferences = are in fact different, what would the user of the client app expect? > =20 > ----> any multi-lingual people have any opinions here? > =20 > Without specific proposed text changes to review, it=E2=80=99s hard to = know what to think about this comment. Unless a specific proposed text = change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and reviewed by the working group, = I don=E2=80=99t believe we should change the specification in response = to this comment. [PH] I agree. I plan to follow up and see if I can't get more = clarification on requirements from my side.=20 > =20 > Section 3 > =20 > Existing text: >=20 > =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >=20 > I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 > =20 > I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 > =20 > I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? > =20 > No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 > =20 > I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >=20 > On the flip side, the earlier paragraph: >=20 > =E2=80=9CThe 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.=E2=80=9D >=20 > I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D = to =E2=80=9CSHOULD=E2=80=9D. >=20 > That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. > =20 > Again, disagree, for the same reasoning as above. > =20 > Same reasoning.=20 >=20 > I agree with Justin here. The default should be that open = registrations are enabled. The exception case is that specific = permissions are required to perform dynamic client registration. [PH] I'm not sure I understand your last sentence. It seems to = contradict your position. If you need specific permissions, then surely = you can't be anonymous??? >=20 > About section 4.3: > =20 > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used = to > make this request SHOULD be immediately revoked. > =20 > If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >=20 > If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. > =20 > The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. > =20 > Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 > =20 > Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. > =20 > I think we should look at it. >=20 > For security reasons, it=E2=80=99s generally not good to distinguish = between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D = errors in responses, as that can provide the attacker an oracle to probe = whether a particular entity exists I don=E2=80=99t think a change is = called for here. [PH] I agree in principle. This issue is bound up too in what the = life-cycle of the registration and the access token and client tokens. = We need to describe those first before this becomes clear. For example, = if the client is still authenticated, but its registration is gone, it = should be not found. But I agree this doesn't make sense, because the = "implied" action was that the deletion of a registration invalidates all = associated credentials. ---> meaning the client should never be able to = authenticate with the registration endpoint anyway. >=20 > About section 5.1: > Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. > =20 > The registration_access_token is unique to a registered client, in the = RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly. [PH] Disagree. I think it is well within charter and in fact a = foundational requirement. >=20 > Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >=20 > Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D > =20 > While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >=20 >=20 > I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. > =20 > That's why we are having last call. To confirm consensus on the draft.=20= > =20 > Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. > =20 > I'm fine with the suggested change but I would like more feedback from = other people before moving forward with it. There's a lot of value in = "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) > =20 > Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 > =20 > I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >=20 > If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at= =E2=80=9D are unclear, we should clarify them. If you believe that this = is the case Phil, can you supply proposed alternative definition text = that is clearer? That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them. They are = already working fine as-is in production deployments. [PH] I'm just reporting the confusion people have had with ambiguity. =20= > =20 > Section 7 > =20 > When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? > =20 > Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. > =20 > Either is a reasonable behavior on the behalf of clients, depending = upon context. I support adding text to clarify this. > =20 > Again, thanks for the very thorough read through. Have you implemented = any of the spec yet, either as-is or with any of your suggested changes? > =20 > Yes. Much of the feedback is coming from our development community.=20 > =20 > Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) > =20 > Glad to hear that you=E2=80=99re working with developers building the = spec. Please thank them for the feedback. > =20 > -- Justin > =20 > Best = wishes, > -- Mike [PH] Thankss. --Apple-Mail=_E3C6CBDC-3723-486C-B20A-078990575F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have started a separate thread on having dyn reg correlate client = software.

My other comments are embedded marked with = [PH].  

Phil

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





On 2013-05-17, at 1:08 PM, Mike Jones wrote:

 OAuth 2.0 won the award for best new = standard J).  My feedback on the points raised is inline in = green=E2=80=A6
  for your inline replies, so that it will be easily = evident who said what.  As it is, just the back-and-forth between = Phil and Justin is already very difficult to follow.  = Thanks.)
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Phil = Hunt
Sent: Thursday, May 16, 2013 = 12:54 PM
To: Richer, Justin = P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call = review of = draft-ietf-oauth-dyn-reg-10
 
Thanks for the = discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to = some rough agreement first.  For example, I think we need to have a = away to recognize two pieces of software as being the same (even if = self-asserted).  Once defined, I can put together some intro text, = etc.
Phil
@independentid
It seems = unfortunate that I have not gotten a chance to get into this level of = detail much earlier. But then, I guess that's what LC review is for! My = apologies for not getting many of these concerns to the WG much = earlier.
Overall =  
I think = dynamic registration is a critical part of the OAuth framework now that = we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource = API. We've moved from the simple use case of a single API provider like = Facebook or Flickr and moved on to standards based, open source based, = and commercial based deployments where there are multiple service = endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with = a couple of issues that I would like to see made more clear in early = part of the spec:
1.  How = is a new client application recognized for the first time when deployed = against a particular SP endpoint?  Should clients actually assert = an application_id UUID that never changes and possibly a version id that = does change with versions?
 
In the general case, why is any recognition required? = If you're doing things as part of a larger protocol ecosystem, like Blue = Button+ or a particular OpenID Connect provider, then you can define = semantics for tying together classes of clients (see below for more = discussion on this very point). But in general, a client is just going = to show up as a new instance to the AS and get issued a new, unique = client_id, and that's = that. 
 
I think we = have to define more clearly what an "instance" is. For me, there are = applications and there are instances of that application.  It is = useful to understand that a client application represents a set of code = that should behave in a consistent way.  It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree.
But without = other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other = client instance. Therefore, from the perspective of an AS, the first = instance of an application (i.e., particular configuration of a set of = code) to register is no different to subsequent instances of that same = application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere?
I do agree = that a discussion of "instance vs. application" would be helpful in = clearing this up, I'll make a note to add text to that effect. (We had = to do something similar for = BB+)
I think it is = simple enough to at least add a self generated UUID for the application = ID.  Though I would allow for cases where the application ID is = assigned when the client developer and the APIs owner do a formal = assignment of application IDs.
 
In a sense this is just a lower tech way of doing it = than what you described as the initial client credential in Blue Button+ = where you encoded extra claims into the initial app = credential.
What the UUID = does is link multiple instances of a client app together as the same = "thing" that should have similar heuristics/behaviours.  This is = very useful if you want to be able to revoke access to a set of clients = identified by application id (or a version of that app).
While = I=E2=80=99m sympathetic to the OAuth working group eventually doing work = on differentiating between instances of an OAuth client, I=E2=80=99ll = note that in RFC 6749 or RFC 6750 there is no such thing as a client = instance.  There are only clients, which are identified by = client_id values.  If we want to do work on client instances, we = should recharter to add this new work as a working group = deliverable.  We should not try to shoehorn bits and pieces of it = into the Dynamic Registration spec, any more than we should have tried = to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there = to register clients as defined in RFC 6749.  It=E2=80=99s not the = right place to extend what an OAuth client is in new = ways.
=

[PH] See new thread I have begun.
2.  How are client credentials managed. Are we = assuming client credentials have a limited lifetime or rotation = policy?
The intent was = that client_secret could be rotated, as indicated by the expires_at = member of the response. If a client's secret expires, it calls the read = operation on the Client Configuration Endpoint (=C2=A74.2) to get its = new client_secret. If this is unclear in the current text (which I = suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that = clear. 
Something like = this should be in the draft.
 
Should this be up in the introductory text, somewhere = else, or have its own = section?
 
I'm starting to think credential management is a key = part of the draft. It may be worth introducing a specific section = outling the registration life-cycle, registration access token usage, = and client token usage and bootstrapping.
I = think that adding a discussion on this would be fine, as it could help = developers understand the workflow of registering, using, and updating = registered clients.
How does a client authenticate the first time and = subsequent times to the registration = service?
This is a = separate question all together, as it does not involve the client_secret = or client_id at all. Rather, the first time the client shows up to the = registration service, it may either:
  - Not authenticate at all (this is the true = public, open registration, and it is recommended that servers do = this)
 - = Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to = the AS beyond "this client is authorized to register" is out of scope = for the spec, by design.
 
Subsequent times that the same registered client (by = which we mean the same instance of a client with a particular client_id) = shows up at the registration endpoint (actually, the Client = Configuration Endpoint), it uses its Registration Access Token that it = was issued on initial registration. This is an OAuth 2.0 Bearer token = that is unique to the client = instance.
 
Something like = this should be in the draft.
 
OK, the definition of the registration access token can = be expanded, but I think that the rest of it is already in there in =C2=A7= 3. I'd welcome suggestions on which bits of this could be made = clearer.See = the discussion on what the registration_access_token is in the thread = =E2=80=9CClient Credential Expiry and new Registration Access Token - = draft-ietf-oauth-dyn-reg-10=E2=80=9D.  I will work with Justin to = apply these clarifications to the specification.  This may go into = the proposed credential management overview section discussed = above.
3.  How is versioning of clients managed? Should = each new version of a client require a change in client registration = including possibly changing client_id and authentication credential? I = don't have a strong feeling, but it is something that implementors = should consider.
 
This is up to the AS, really, and I don't think that = any global policy would ever fly here. Especially if you consider that = the entire notion of "version" is more fluid these days than it ever has = been. I wouldn't mind adding a discussion in the security considerations = if it merits mentioning though, so that we can help both client = developers and server developers institute reasonably good = policy.
 
I guess the = issue is that when a client upgrades it may have access to the old = credentials. What is the intent then of registration.  Since you = have an update are clients expected to update /re-register or not? =  I'm not sure this is a security consideration but more part of the = whole change management function dynamic registration = supports.
If your = upgraded version of the client still has access to its old credentials, = why wouldn't it just use those? I don't see a reason for forcing a = re-registration. Nor do I see any way that an AS would even be able to = tell that a client had been upgraded. An upgraded client always has the = *option* of re-registering itself and getting a new = client_id. 
I think the concern here is that rotation of client = credential is not something discussed before. Before we put it in the = spec we should consider the reasons for doing it and what problems it = solves.
I think this = may be just a case of letting people exchange credentials for whatever = reason they feel is appropriate.  The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register".  Depending on the policy of the server, it = may (or may not) receive a new client_id and/or new credential. =  
One of the = best benefits I can think of is if you discover a version of a client = has a problem, being able to select a group of clients by software and = version is important. Thus if client_id doesn't trace to a particular = software and version, that makes it hard to do.  I  think you = talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client = instances or groups of clients, therefore I believe that it=E2=80=99s = inappropriate to do so here.  We don=E2=80=99t need to boil the = ocean.  If a new charter item is approved to do work on client = instances and protocol elements to use and express them, that=E2=80=99s = the time for the working group to consider that possibility =E2=80=93 = not as part of Dynamic Client = Registration.

[PH] We disagree strongly here.  I think it = is well within charter and in fact if such a new charter item were = developed we would be quickly moving to replace dyn reg version = 2.
4.  What is the = registration access token? Why is is used? What is its life-cycle? =  When is it issued, when is it changed? When is it = deleted?
See the = response above above and the definition in = =C2=A71.2: 
Registration Access Token: An OAuth 2.0 Bearer Token = issued by the Authorization Server through the Client Registration = Endpoint which is used by the Client to authenticate itself during read, = update, and delete operations. This token is associated with a = particular = Client.
 
If this can be clarified, I welcome text = suggestions.
 
The latter = part of 1.2 didn't seem like terminology but rather architecture or part = of the introduction that describes what the spec does. The third point = doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration = access tokens.
Client = Registration Endpoint: The OAuth 2.0 Endpoint through = which
      a =
Client can request new registration.  The means of the =
Client
      =
obtaining the URL for this endpoint are out of scope for =
this
      =
specification.
 
      which =
a specific Client can manage its registration =
information,
      =
provided by the Authorization Server to the Client.  This URL =
for
      this endpoint =
is communicated to the client by the =
Authorization
      =
Server in the Client Information Response.
   o  Registration =
Access Token: An OAuth 2.0 Bearer Token issued by =
the
      Authorization =
Server through the Client Registration =
Endpoint
      which =
is used by the Client to authenticate itself during =
read,
      =
update, and delete operations.  This token is associated with =
a
      particular =
Client.
 
This section is meant to just introduce the new terms = that are then explained in greater detail throughout the rest of the = document. Yes, it's a bit architecture, but only in the sense that you = need to define the terms that make up your architecture. How would you = suggest that it change?
 
Probably this = is more a matter of style.  But, what happened for me is I = naturally skipped the terminology section, as I wasn't expecting = protocol components to be there.  "terminology" is something I = think people tend to use as a dictionary rather than as protocol = component description.  Maybe the chairs can = advise?
If we distinguish between first time registration of a = particular client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri).  I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance.
When = subsequent instances register, I have to ask the question, for example = when would things like "token_endpoint_auth_method" be negotiated or be = different for the same client software? Should not all instances use the = same authentication = method.
 
I'm confused by this -- as far as the dynamic = registration spec is concerned, all instances are separate from each = other. All parameters change per instance. And instance, you should keep = in mind, is defined as any one copy of the client code connecting to any = new authorization server. That pairing creates the client_id, and = therefore the instance, and therefore the registration access token, and = therefore the registration itself at a conceptual level. So there is no = way other than per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about = it?
 
We still disagree on this. It is my assertion that = clients should NEVER ask for a particular token auth method. Since it is = the AS that is authenticating the client, then it is the AS's right to = set the authentication policy.  The role of dynamic reg endpoint is = to inform the client what it must do.  My assumption is that during = the first time a piece of software is registered (the first instance), = there could be some OOB discussion by an administrator to approve the = particular authentication type for the AS in = question.
I haven't = heard a reason justifying this parameter other then "it is needed". =  Why?
 
The role of the dynamic registration protocol is = twofold: half of that is the server informing the client what it must = do. But the other half is the client informing the server what it *can* = do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first = instance from a subsequent instance unless you're doing something in = addition. Nothing is stopping the same application from registering a = new instance of itself for every single user or every single token that = it wants to get access for. That's complicated and wasteful and not a = great idea, sure, but  there's no useful way to prevent that kind = of behavior if you also want open registration of = clients. 
 
I think we've = discussed how recognizing subsequent instances is easily = done.
As I mentioned = in the other thread, if a developer chooses to limit the capabilities of = the client it must do so by looking to the developer or standard behind = the API.  Otherwise they are taking the chance.  There's no = way a developer can query all the potential deployers to ask what authn = types will you use. As I said, the net effect in the absence of an API = standard dictating what should be supported, the developer will have to = implement all methods.
 
My point here is that none of this is helped by the = client app saying what it supports. A developer who takes the route of = limiting implementation takes the chance that the server will not = accept.  So why negotiate within = registration?
And there's no way other than per-instance for the = server to tell the client which token_endpoint_auth_method to use. All = instances will probably ask for the same token_endpoint_auth_method from = all auth servers they talk to, right? And each AS will tell each = instance that registers with it to use a particular auth method. There = is no way to tie together different instances across (or within) auth = servers without specifying a significant amount of other = machinery.
Which is not to say that it's not useful in some circumstances = to tie together different instances of the same code across (or within) = auth servers. This is why, with Blue Button+, we specified a specific = token format for the initial access token that the clients use to call = the registration endpoint the first time,  as well as a discovery = protocol against a centralized server that handles pre-registration. All = of this machinery is, in my opinion, a stupendous overkill for the = general case, though if some folks find use for it outside of BB+ then = it'd be a good thing to abstract out and make its own spec that extends = the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue = Button+ we specify that all auth servers MUST also accept open = registration, without an initial access token, where the client simply = shows up and says "hey, here are my parameters." The auth server has no = way to know in this case any kind of out-of-band negotiation for = different things. In BB+ we are writing very specific policy guidelines = about how to present the UX and things to the end user for all of these = different cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its = own. I believe it would be far too limiting.

 
See my previous comments on = differentiating client instances being out of scope without rechartering = to do this new work and on what the registration_access_token is.  = In short, the registration_access_token is an RFC 6750 bearer token = issued to the party registering the client, enabling it to subsequently = retrieve information about the client registration and to potentially = update the registration information for that registered client.  = Again, I=E2=80=99ll work with Justin to make sure that this is as clear = as possible in the specification.
Specific = items:
 
There is some confusion as to whether this applies to = server or client authentication.  Suggest renaming parameter to = "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular = confusion. I'm fine with either name but at this stage I don't want to = make syntax changes without very, very compelling reasons to do = so.
 
The question was raised to me by some new developers. = It seems obvious to us as experienced OAuth persons, but to new = developers it seems unclear.  Also, now that you are introducing = registration authentication, the whole thing gets very confusing. So it = is useful disambiguate all the parameters where possible.  That = said, I wouldn't mind shorter names (maybe not quite as short as the = JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax = changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  = I=E2=80=99m fine clarifying the description of this parameter to resolve = the potential ambiguities that you cite, Phil.  I=E2=80=99m not OK = revising the syntax without a compelling reason to do = so.

[PH] I don't think we're changing any syntax = here. Just clarifying the name. This seems important now that there are = 3 types of tokens being managed (registration, client, access). =  

I would much prefer just dumping the = registration access token rather then renaming parameters that would = otherwise be unclear.
* Currently, the API only supports a single value = instead of an array.  If the purpose is to allow the client to know = what auth methods it supports, this should be an array indicated what = methods the client supports - or it should not be = used.
I would rather = like this to be an array, personally, and brought it up with the OpenID = Connect working group about six months ago. But there it was decided = that a single value was simpler and sufficient for the purpose. The IETF = draft has inherited this decision. I *believe* (though am not 100% = positive) that I brought up this very issue in the WG here but didn't = receive any traction on it, so single it = remains.
 
I can get = behind multiple values. In this case, it changes the meaning of the = parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can = perform. This allows the server to assign the appropriate method based = on its own policy.

Also note that = this field, like all others in =C2=A72, represents two things: the = client telling the server "I want to use this value for this field", and = the server telling the client "this is the value you have for this = field". It's not exactly a negotiation, more like making a polite = request to an absolute dictator who has the last word anyway. But at = least this dictator is nice enough to tell you what their decision was = instead of just decapitating you.
 
This is the = heart of my objection. This fuzziness is is going to lead to interop = issues.
There is no = fuzziness that I can see here. It's parallelism between what goes in to = the endpoint and what comes out of it. The semantics for the request and = the response are different, and differentiable by the fact that one is a = request and the other is a = response. 
 
The inter-op = issue I would like to point out is that the spec does not currently = specify if particular input values are singular or multiple.  If an = implementer assumes singular and clients assume multiple, we have = issues.The = multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written.  The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification.  I strongly believe that we need to = add a clear statement to this effect in the introduction to the = specification.
The = purpose of the Dynamic Client Registration specification is for the = client to register with the Authorization Server and to inform it of = properties of the client that the AS may want/need to be aware of.  = It *is not* the purpose of this specification for it to be used = by clients in any manner to discover features of the Authorization = Server.  That should be explicitly out of = scope.
=
[PH] Agreed.
[PH] = So, given the above, the client shouldn't be dictating token type. The = AS should simply assign the credential and inform the client what it = must use.

We agree, no discovery.  But I = also want to eliminate negotiation that doesn't actually help = anything.
 
That being said, I strongly oppose trying to shoehorn = piecemeal aspects of discovery into the Dynamic Client Registration = specification.  It is distinct functionality and deserves = first-class and separable treatment by the working group.  = Discovery is for potential clients to learn properties of the AS before = registration.  Registration is for potential clients to inform the = AS of its properties, creating a registered client.  Discovery = sends information about the AS to the Client.  Registration sends = information about the Client to the AS.  That=E2=80=99s a clean = separation.  We should strongly resist muddying the two = functions.
OAuth = 2.0 is a success because it didn=E2=80=99t try to boil the ocean.  = It specified how to do one thing well in a simple, web-friendly = manner.  We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this = work.
I = apologize at this point on behalf of myself and the other spec editors = for not being 100% clear that discovery functionality is explicitly out = of scope for Dynamic Client Registration.  If we had done so, I=E2=80= =99m sure that many of the current questions and confusions would not = have arisen.  I think we=E2=80=99d assumed that this was obvious, = but from the current discussions, it=E2=80=99s apparent that it=E2=80=99s = not obvious.  I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion.
=E2=80=9D member would be to enable the client to = discover information about the authentication methods supported by the = AS after the registration had been performed.  But that is a = discovery function, and so should be part of the discovery work =E2=80=93 = not this specification.  We should resist shoehorning in bits of = discovery into this specification.  It *is* a worthwhile = topic, but deserves full consideration by the working group in its own = right.  Therefore, this member must remain single-valued, and be = clearly specified as the method by which a client informs the AS which = token endpoint authentication method it will use.  Anything else = would be scope creep, and result in an unnecessarily complicated = specification and unnecessarily complicated = clients.

[PH] Agreed. Let's remove the parameter.in the request. It = should only be in the response.
* There is no authn method for "client_secret_saml" or = "private_key_saml".
 
Nobody has really asked that these two be included or = specified. The extension mechanism (using an absolute URI) would allow = someone else to define these. Is the definition in the SAML Assertion = draft sufficient for their = use?
 
I think this = is coming from the fact that there is a JWT bearer draft and a SAML = bearer draft.  The truth is you are defining an authentication that = isn't even defined.
 
There are no profiles referenced or defined for = "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML = Bearer drafts referenced cover these types of flows. They only cover = bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to = have some meaning within OpenID Connect, but I note that OIDC does not = fully define these either.
 
The JWT assertion draft does say how to use a JWT for = client authentication, and the DynReg text differentiates between a = client signing said JWT with its own secret symmetrically vs. a client = using its own private key, = asymmetrically.
 
Actually my interpretation is the JWT draft assumes the = JWT Bearer is a bearer token.  The assumption is that if a client = has the assertion it has the right to present it.  IOW. The JWT = Bearer Draft is most definitively not a JWT HoK Draft. =  :-)
Regardless, = you are introducing a new profile which is = undefined.
 
I think I see the point that you're making now, let me = try to re-state it:
=E2=80=9CAs such, a server = supporting these fields SHOULD take steps to ensure that a client = cannot register itself into an inconsistent state.=E2=80=9D

We = may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code = (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?
<= div>
 
I'd be fine with defining a more explicit error state = in this case. I think it would help interop for the servers that want to = enforce grant-type and response-type restrictions, but servers that = can't or don't care about restricting grants types and whatnot don't = have to do anything special.
I = *think* that this goes away with the deletion of = client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6&nb= sp; I=E2=80=99ll do a consistency check and verify that when the spec is = updated = accordingly.
= [PH] Agreed.
Section = 2.2 
May want to = add:
 
When =E2=80=9C#=E2=80= =9D language tag is missing, (e.g. =E2=80=9C#en=E2=80=9D is missing in = =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_name#en=E2=80= =9D) the OAuth server may use interpret the language used = based on server configuration or = heuristics.
That seems = inconsistent with what we already have:
 
If any human-readable field is sent without a language = tag, parties using it MUST NOT make any assumptions about the language, = character set, or script of the string value, and the string value MUST = be used as-is wherever it is presented in a user = interface.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0.5in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "> 
Which is to say, treat it as a raw byte-value-string = and don't try to get = fancy.
 
I will discuss = with our developers. I'm not sure the as-is works. =  
Is it the = intent that when the client has localized "client_name" for example, it = should pass all language variations in a JSON = array?
Or, should = part of the registration be to indicate which interface language the = client wishes to use?  Then it only passes a single value for that = registration?
 
 
No, the client should pass parameters as multiple = separate values. Connect has this in its = example:
   = "client_name": "My Example",
   =
"client_name#ja-Jpan-JP":
     =
"
Should we add that to at least = one of the examples in DynReg? (The language tags are a late addition, = so the examples don't reflect = it.)
 
An example would definitely = help.
If the client passes only a single unadorned field, the = AS can't make any assumption about what language it is. Think of this as = the internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with = it.
Passing in a = "default" language field (like default_locale or the like) is only going = to lead to pain for implementors of both clients and servers, and it's = going to hurt the interoperability of the human-readable = fields. 
 
I think what I meant is since you are allowing each = client to register different things, AND the client likely already knows = the user's preferred language, why wouldn't the client just pass text = values in one language and another parameter indicating preferred = language in the case of any service generated = text.
Is the reason = you are passing multiple localizations is so that you can use the = preferred language of the resource owner rather then the client user? I = wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app = expect?
----> any = multi-lingual people have any opinions = here?
 
Without specific proposed text = changes to review, it=E2=80=99s hard to know what to think about this = comment.  Unless a specific proposed text change is sent to the = list with clear rationale for why it=E2=80=99s better than what=E2=80=99s = there now and reviewed by the working group, I don=E2=80=99t believe we = should change the specification in response to this = comment.

[PH] I agree. I plan to follow up = and see if I can't get more clarification on requirements from my = side. 
Section = 3
Existing = text:

=E2=80=9CIn order to = support open registration and facilitate wider interoperability, = the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication.  These = requests MAY be rate-limited or otherwise limited to prevent a = denial-of-service attack on the Client Registration = Endpoint.=E2=80=9D

I would suggest to change the first = =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY=E2=80=9D.   In most = cloud services, the first client is registered by a human user. = Then, other clients can be further used to automate other = client registration.  So, the first request would = typically come with an authenticated user = identity. 
=
I think the = weight of "SHOULD" is appropriate here, because I believe that turning = off open registration at the AS (which is what this is talking about) = really ought to be the exception rather than the = rule. 
 
I think you = are reading it wrong -- a double-negative issue. The end of the sentence = is "no authentication".  You are implying that NO Authentication us = what should normally be done. I think you intend anonymous = authentication to be the exception rather than the rule don't = you?
No, I think = that anonymous authentication should be the rule. Open registration = should be = default. 
 
I disagree.  Again,  the spec seems = contradictory. It suggests strong client auth methods and at the same = time anonymous registration.  Yes you gain uniqueness, but that's = about it.

On the = flip side, the earlier paragraph:

=E2=80=9CThe 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.=E2=80=9D

I tend to think it would be better = to change this =E2=80=9CMAY=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.

T= hat access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.Again, = disagree, for the same reasoning as = above.
 
Same = reasoning. 

I agree with = Justin here.  The default should be that open registrations are = enabled.  The exception case is that specific permissions are = required to perform dynamic client = registration.
=

[PH] I'm not sure I = understand your last sentence. It seems to contradict your position. If = you need specific permissions, then surely you can't be = anonymous???

About section = 4.3: 
If the client does not exist on this =
server, the server MUST respond
   make this request =
SHOULD be immediately revoked.
 
If the Client does not exist on this server, = shouldn't it return a "404 Not Found"?

If revoking the = registration access token, is it bound to a single client registration? =  This is not clear.  What is the lifecycle around registration = access token? Only hint is in the Client Information Response in section = 5.1.
=
 
The language about the 401 here (and in other nearby = sections) is specifically so that you treat a missing client and a bad = registration access token the same way. You see, returning a 404 = here actually indicates things were in an inconsistent state. Namely, = that the registration access token was still valid but the client that = the registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token.
 
Since the intent of the registration access token is = that it's bound to a single instance, its lifecycle is generally tied to = the lifecycle begins at the issuance of a new client_id with that = instance. That token might be revoked and a new one issued on Read and = Update requests to the Client Configuration Endpoint (and the client = needs to be prepared for that -- same as the client_secret), and it will = be revoked when the client is deleted either with a Delete call to the = Client Configuration Endpoint or something happening out-of-band to kill = the client. 
Should we add = more explanatory text to the definition in the terminology section? = Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd = like.
I think we = should look at it.

For security = reasons, it=E2=80=99s generally not good to distinguish between =E2=80=9Cn= ot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors in = responses, as that can provide the attacker an oracle to probe whether a = particular entity exists  I don=E2=80=99t think a change is called = for = here.

[PH] I agree in principle. This = issue is bound up too in what the life-cycle of the registration and the = access token and client tokens. We need to describe those first before = this becomes clear.  For example, if the client is still = authenticated, but its registration is gone, it should be not found. =  But I agree this doesn't make sense, because the "implied" action = was that the deletion of a registration invalidates all associated = credentials. ---> meaning the client should never be able to = authenticate with the registration endpoint anyway.

About section = 5.1:Is registration_access_token unique?  Or is it = shared by multiple instances?   If shared, then = registration_access_token can't be revoked on delete of = client.
 
The registration_access_token is = unique to a registered client, in the RFC 6749 sense of = =E2=80=9Cclient=E2=80=9D.  Again, if we want to do work on = =E2=80=9Cclient instances=E2=80=9D, we need to recharter and take this = distinct work item up = explicitly.

[PH] Disagree. I think it is well within = charter and in fact a foundational = requirement.


Suggest rename = =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to = rename =E2=80=9Cissued_at=E2=80=9D to = =E2=80=9Cid_issued_at=E2=80=9D
While I do = like the suggestion of changing these to client_secret_expires_at and = client_id_issued_at, and I think these are more clear and = readable,
I don't want = to change the syntax during last call unless there is a clear need and a = clear consensus for doing so.
 
That's why we = are having last call. To confirm consensus on the = draft. 
Same reasoning = as earlier. You now have multiple tokens (registration access and = client) in play. The spec needs to be clear which one it is talking = about.
I'm fine with = the suggested change but I would like more feedback from other people = before moving forward with it. There's a lot of value in "just pick a = name and ship it" as well though, and I don't want to devolve into bike = shedding. (I'm not accusing you of bike shedding quite yet, btw, just = afraid of getting into a long debate on = names.)
Again, this = was a problem raised by people new to the specification. They found it = confusing. I tend to agree. We're not talking about what colour to paint = the shed. We're talking about whether the bike shed is a = house.  :-) 
 
I'm not too fussed about whether you call it = "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of = =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2=80=9D are unclear, = we should clarify them.  If you believe that this is the case Phil, = can you supply proposed alternative definition text that is = clearer?  That being said, I believe that at this point we should = stick with the existing protocol element names unless overwhelming = working group sentiment emerges to change them.  They are already = working fine as-is in production = deployments.

[PH] I'm just reporting the confusion people have had = with ambiguity.  

Section 7
 
When a client_secret expires is it the intent that = clients do an update or refresh to get a new client = secret?
 
Yes, the client is supposed to either call the read or = update methods on the client configuration endpoint to get its new = secret. As discussed above, I'm not sure that's as clear as it needs to = be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on = the behalf of clients, depending upon context.  I support adding = text to clarify this.
Again, thanks for the very thorough read through. Have = you implemented any of the spec yet, either as-is or with any of your = suggested changes?
 
Yes. Much of = the feedback is coming from our development = community. 
 
Ah, very cool. Developer experience is the most = valuable feedback, in my opinion. If you can't actually build the = blasted thing, what good is it? :)
Glad = to hear that you=E2=80=99re working with developers building the = spec.  Please thank them for the = feedback.
 -- = Justin To: "oauth@ietf.org WG" References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-Id: X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 21:27:34 -0000 --Apple-Mail=_22F2346F-7659-4021-9452-7953DBF22CFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, Rather then embed comments in an extended thread, I'd like to open up a = specific discussion on the objective of dyn reg. I see limited to no value in having clients completely anonymously = registering and receiving tokens without any ability to correlate = applications between applications.=20 Associating client_id's with known client applications to allow admins = to know who is running what version of clients seems to be the most = fundamental part of the reason for dynamic reg. How can you revoke = access to particular client app types? As Justin already talked about = in his Blue Button+ scenario, there are often life and death situations = where particular sets of clients need to be revoked. =20 Or put another way. I believe this will be a critical operational = requirement going forwards. If the spec is published as is, it will be = quickly invalidated by one that does at least partially address the = problem. We're ahead of schedule, lets talk through the requirement. As I mentioned in my comments to the other thread. Let's say we agree = not do this now. Well, then the new draft that does solve it would = likely be 95% overlap. Thus I see this issue as within charter and = should be solved now rather then waiting for a V2 dyn reg in the next = charter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 1:08 PM, Mike Jones wrote: > Thanks for the detailed feedback, Phil. Sorry for the delayed = response =E2=80=93 I was pretty fully engaged at the European Identity = Conference (where OAuth 2.0 won the award for best new standard J). My = feedback on the points raised is inline in green=E2=80=A6 > =20 > (Perhaps if any of you reply to this thread, you could also choose a = distinct color for your inline replies, so that it will be easily = evident who said what. As it is, just the back-and-forth between Phil = and Justin is already very difficult to follow. Thanks.) > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, May 16, 2013 12:54 PM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 > =20 > Justin, > =20 > Thanks for the discussion. More comments below... > =20 > BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > =20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: > =20 > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > =20 > Phil, many thanks for the extremely thorough review! It is very useful = indeed.=20 > =20 > My comments and responses to each point are inline.=20 > =20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: > =20 > It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. > =20 > Overall =20 > ----------- > I think dynamic registration is a critical part of the OAuth framework = now that we are starting to consider how individual client applications = should operate when there is one or more deployments of a particular = resource API. We've moved from the simple use case of a single API = provider like Facebook or Flickr and moved on to standards based, open = source based, and commercial based deployments where there are multiple = service endpoints and many clients to manage. > =20 > The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: > =20 > 1. How is a new client application recognized for the first time when = deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? > =20 > In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 > =20 > I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. > =20 > But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? > =20 > I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) > =20 > I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. > =20 > In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. > =20 > What the UUID does is link multiple instances of a client app together = as the same "thing" that should have similar heuristics/behaviours. = This is very useful if you want to be able to revoke access to a set of = clients identified by application id (or a version of that app). > =20 > While I=E2=80=99m sympathetic to the OAuth working group eventually = doing work on differentiating between instances of an OAuth client, = I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as = a client instance. There are only clients, which are identified by = client_id values. If we want to do work on client instances, we should = recharter to add this new work as a working group deliverable. We = should not try to shoehorn bits and pieces of it into the Dynamic = Registration spec, any more than we should have tried to shoehorn it = into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients = as defined in RFC 6749. It=E2=80=99s not the right place to extend what = an OAuth client is in new ways. > =20 > 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? > =20 > The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 > Something like this should be in the draft. > =20 > Should this be up in the introductory text, somewhere else, or have = its own section? > =20 > I'm starting to think credential management is a key part of the = draft. It may be worth introducing a specific section outling the = registration life-cycle, registration access token usage, and client = token usage and bootstrapping. > =20 > I think that adding a discussion on this would be fine, as it could = help developers understand the workflow of registering, using, and = updating registered clients. > =20 > How does a client authenticate the first time and subsequent times to = the registration service? > =20 > This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: > - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. > =20 > Subsequent times that the same registered client (by which we mean the = same instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. > =20 > Something like this should be in the draft. > =20 > OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer. > =20 > See the discussion on what the registration_access_token is in the = thread =E2=80=9CClient Credential Expiry and new Registration Access = Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin = to apply these clarifications to the specification. This may go into = the proposed credential management overview section discussed above. > =20 > 3. How is versioning of clients managed? Should each new version of a = client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. > =20 > This is up to the AS, really, and I don't think that any global policy = would ever fly here. Especially if you consider that the entire notion = of "version" is more fluid these days than it ever has been. I wouldn't = mind adding a discussion in the security considerations if it merits = mentioning though, so that we can help both client developers and server = developers institute reasonably good policy. > =20 > I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. Since you = have an update are clients expected to update /re-register or not? I'm = not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. > =20 > If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= > I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. > =20 > I think this may be just a case of letting people exchange credentials = for whatever reason they feel is appropriate. The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register". Depending on the policy of the server, it may = (or may not) receive a new client_id and/or new credential. =20 > =20 > One of the best benefits I can think of is if you discover a version = of a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ > =20 > Again, RFC 6749 defines no client instances or groups of clients, = therefore I believe that it=E2=80=99s inappropriate to do so here. We = don=E2=80=99t need to boil the ocean. If a new charter item is approved = to do work on client instances and protocol elements to use and express = them, that=E2=80=99s the time for the working group to consider that = possibility =E2=80=93 not as part of Dynamic Client Registration. > =20 > 4. What is the registration access token? Why is is used? What is its = life-cycle? When is it issued, when is it changed? When is it deleted? > =20 > See the response above above and the definition in =C2=A71.2:=20 > =20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. > =20 > If this can be clarified, I welcome text suggestions. > =20 > The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. > =20 > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > =20 > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL = for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > =20 > o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > =20 > This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? > =20 > Probably this is more a matter of style. But, what happened for me is = I naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? > =20 > If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. > =20 > When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. > =20 > I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? > =20 > We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. > =20 > I haven't heard a reason justifying this parameter other then "it is = needed". Why? > =20 > The role of the dynamic registration protocol is twofold: half of that = is the server informing the client what it must do. But the other half = is the client informing the server what it *can* do, or what it *wants* = to do.=20 > =20 > And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 > =20 > I think we've discussed how recognizing subsequent instances is easily = done. > =20 > As I mentioned in the other thread, if a developer chooses to limit = the capabilities of the client it must do so by looking to the developer = or standard behind the API. Otherwise they are taking the chance. = There's no way a developer can query all the potential deployers to ask = what authn types will you use. As I said, the net effect in the absence = of an API standard dictating what should be supported, the developer = will have to implement all methods. > =20 > My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? > =20 > And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. > =20 > Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. > =20 > See my previous comments on differentiating client instances being out = of scope without rechartering to do this new work and on what the = registration_access_token is. In short, the registration_access_token = is an RFC 6750 bearer token issued to the party registering the client, = enabling it to subsequently retrieve information about the client = registration and to potentially update the registration information for = that registered client. Again, I=E2=80=99ll work with Justin to make = sure that this is as clear as possible in the specification. > =20 > Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? > =20 > That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. > =20 > Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 > =20 > One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. > =20 > There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 > =20 > If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. > =20 > ETags seem like an unnecessary addition (and potential complication) = to the specification. It=E2=80=99s already working fine as-is. > =20 > Specific items: > --------------------- > "token_endpoint_auth_method" > =20 > There is some confusion as to whether this applies to server or client = authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" > =20 > This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. > =20 > The question was raised to me by some new developers. It seems obvious = to us as experienced OAuth persons, but to new developers it seems = unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) > =20 > Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to. > =20 > I agree with Justin here. I=E2=80=99m fine clarifying the description = of this parameter to resolve the potential ambiguities that you cite, = Phil. I=E2=80=99m not OK revising the syntax without a compelling = reason to do so. > =20 > * Currently, the API only supports a single value instead of an array. = If the purpose is to allow the client to know what auth methods it = supports, this should be an array indicated what methods the client = supports - or it should not be used. > =20 > I would rather like this to be an array, personally, and brought it up = with the OpenID Connect working group about six months ago. But there it = was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. > =20 > I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method = based on its own policy. >=20 > Also note that this field, like all others in =C2=A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. > =20 > This is the heart of my objection. This fuzziness is is going to lead = to interop issues. > =20 > There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 > =20 > The inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. = If an implementer assumes singular and clients assume multiple, we have = issues. > =20 > The multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written. The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification. I strongly believe that we need to add a = clear statement to this effect in the introduction to the specification. > =20 > The purpose of the Dynamic Client Registration specification is for = the client to register with the Authorization Server and to inform it of = properties of the client that the AS may want/need to be aware of. It = *is not* the purpose of this specification for it to be used by clients = in any manner to discover features of the Authorization Server. That = should be explicitly out of scope. > =20 > Currently, clients are instructed by RFC 6749 to discover information = about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and = 3.2). They can also learn information about Authorization Servers in = specific contexts through discovery protocols such as OpenID Connect = Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) = and UMA Discovery (TBD). > =20 > I suspect that at some point, someone in the OAuth working group will = propose developing a generic OAuth discovery mechanism, which will lead = to a rechartering to include this work in the working group=E2=80=99s = set of deliverables. I would support doing this work and the necessary = rechartering to do so. > =20 > That being said, I strongly oppose trying to shoehorn piecemeal = aspects of discovery into the Dynamic Client Registration specification. = It is distinct functionality and deserves first-class and separable = treatment by the working group. Discovery is for potential clients to = learn properties of the AS before registration. Registration is for = potential clients to inform the AS of its properties, creating a = registered client. Discovery sends information about the AS to the = Client. Registration sends information about the Client to the AS. = That=E2=80=99s a clean separation. We should strongly resist muddying = the two functions. > =20 > OAuth 2.0 is a success because it didn=E2=80=99t try to boil the = ocean. It specified how to do one thing well in a simple, web-friendly = manner. We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this work. > =20 > I apologize at this point on behalf of myself and the other spec = editors for not being 100% clear that discovery functionality is = explicitly out of scope for Dynamic Client Registration. If we had done = so, I=E2=80=99m sure that many of the current questions and confusions = would not have arisen. I think we=E2=80=99d assumed that this was = obvious, but from the current discussions, it=E2=80=99s apparent that = it=E2=80=99s not obvious. I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion. > =20 > Getting back to the specifics, the only useful purpose of a = multi-valued =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member = would be to enable the client to discover information about the = authentication methods supported by the AS after the registration had = been performed. But that is a discovery function, and so should be part = of the discovery work =E2=80=93 not this specification. We should = resist shoehorning in bits of discovery into this specification. It = *is* a worthwhile topic, but deserves full consideration by the working = group in its own right. Therefore, this member must remain = single-valued, and be clearly specified as the method by which a client = informs the AS which token endpoint authentication method it will use. = Anything else would be scope creep, and result in an unnecessarily = complicated specification and unnecessarily complicated clients. > =20 > * There is no authn method for "client_secret_saml" or = "private_key_saml". > =20 > Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? > =20 > I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. > =20 > There are no profiles referenced or defined for "client_secret_jwt" or = "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced = cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. > =20 > The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. > =20 > Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) > =20 > Regardless, you are introducing a new profile which is undefined. > =20 > I think I see the point that you're making now, let me try to re-state = it: > =20 > While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). > =20 > I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. > =20 > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors = made is they assumed everyone had the same definition of bearer token. = To me a bearer token opaque to the client. It therefore cannot do any = signature work with regards to the token itself. Now, that's not to say = a proof didn't occur between the client and the token issuer, but when = the client wields the token, it is handling an opaque string. > =20 > The concept of client_secret_jwt suggests an HoK profile. Therefore = of course the bearer drafts are a little underspecified when it comes to = HoK profiles. > =20 > So for example, you need a draft like the MAC draft for this.=20 > =20 > I'm having trouble overall here. It seems the authn types suggest ONLY = strong authentication for clients, yet during the registration process = the current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way). If you haven't authenticated = the software at all, why have strong client auth? > =20 > There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. > =20 > I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. > =20 > 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. > =20 > What you are describing is not bearer. It is holder of key. Very very = different.=20 >=20 > A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. > =20 > That's possible, but they are in active use already.=20 > =20 > That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. > =20 > This much I agree with. > =20 > Justin, John, and I discussed this issue and agree with your = suggestion, Phil. Since they are not completely specified, we will = remove the client_secret_jwt and private_key_jwt methods from the = specification and add a registry, enabling specification that do fully = specify these and other token endpoint authentication methods, including = potential methods using SAML assertions, to register them in the = registry, rather than trying to bake them into the Dynamic Client = Registration specification. > =20 > About "tos_uri" and "policy_uri" > =20 > The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? > =20 > Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. > =20 > Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. > =20 > OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) > =20 > I support clarifying the language on these definitions, and will work = with Justin to do so. > =20 > Also, aren't these really URIs or are they meant to be URLs? > =20 > There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. > =20 > Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. > =20 > That's fair, and it's something that the AS can even check if it wants = to. > =20 > Agreed on this clarification. > =20 > About "jwks_uri" > =20 > A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 > =20 > Yes, you're correct, I'll add that. > =20 > Should be URL instead of URI? > =20 > See above. :) > =20 > Agreed on adding this reference. > =20 > Section 2.1 > =20 > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > is missing. > =20 > It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? > ' > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > =20 > Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. > =20 > =E2=80=9CAs such, a server supporting these fields SHOULD take steps = to ensure that a client cannot register itself into an inconsistent = state.=E2=80=9D >=20 > We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? > =20 > I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. > =20 > I *think* that this goes away with the deletion of client_secret_jwt = and private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a = consistency check and verify that when the spec is updated accordingly. > =20 > Section 2.2 > =20 > May want to add: > =20 > When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. > =20 > That seems inconsistent with what we already have: > =20 > If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. > =20 > Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. > =20 > I will discuss with our developers. I'm not sure the as-is works. =20 > =20 > Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? > =20 > Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? > =20 > =20 > No, the client should pass parameters as multiple separate values. = Connect has this in its example: > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) > =20 > An example would definitely help. > If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. > =20 > Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 > =20 > I think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text. > =20 > Is the reason you are passing multiple localizations is so that you = can use the preferred language of the resource owner rather then the = client user? I wonder if that is correct. If the language preferences = are in fact different, what would the user of the client app expect? > =20 > ----> any multi-lingual people have any opinions here? > =20 > Without specific proposed text changes to review, it=E2=80=99s hard to = know what to think about this comment. Unless a specific proposed text = change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and reviewed by the working group, = I don=E2=80=99t believe we should change the specification in response = to this comment. > =20 > Section 3 > =20 > Existing text: >=20 > =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >=20 > I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 > =20 > I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 > =20 > I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? > =20 > No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 > =20 > I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >=20 > On the flip side, the earlier paragraph: >=20 > =E2=80=9CThe 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.=E2=80=9D >=20 > I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D = to =E2=80=9CSHOULD=E2=80=9D. >=20 > That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. > =20 > Again, disagree, for the same reasoning as above. > =20 > Same reasoning.=20 >=20 > I agree with Justin here. The default should be that open = registrations are enabled. The exception case is that specific = permissions are required to perform dynamic client registration. >=20 > About section 4.3: > =20 > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used = to > make this request SHOULD be immediately revoked. > =20 > If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >=20 > If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. > =20 > The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. > =20 > Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 > =20 > Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. > =20 > I think we should look at it. >=20 > For security reasons, it=E2=80=99s generally not good to distinguish = between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D = errors in responses, as that can provide the attacker an oracle to probe = whether a particular entity exists I don=E2=80=99t think a change is = called for here. >=20 > About section 5.1: > Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. > =20 > The registration_access_token is unique to a registered client, in the = RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly. >=20 > Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >=20 > Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D > =20 > While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >=20 >=20 > I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. > =20 > That's why we are having last call. To confirm consensus on the draft.=20= > =20 > Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. > =20 > I'm fine with the suggested change but I would like more feedback from = other people before moving forward with it. There's a lot of value in = "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) > =20 > Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 > =20 > I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >=20 > If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at= =E2=80=9D are unclear, we should clarify them. If you believe that this = is the case Phil, can you supply proposed alternative definition text = that is clearer? That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them. They are = already working fine as-is in production deployments. > =20 > Section 7 > =20 > When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? > =20 > Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. > =20 > Either is a reasonable behavior on the behalf of clients, depending = upon context. I support adding text to clarify this. > =20 > Again, thanks for the very thorough read through. Have you implemented = any of the spec yet, either as-is or with any of your suggested changes? > =20 > Yes. Much of the feedback is coming from our development community.=20 > =20 > Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) > =20 > Glad to hear that you=E2=80=99re working with developers building the = spec. Please thank them for the feedback. > =20 > -- Justin > =20 > Best = wishes, > -- Mike --Apple-Mail=_22F2346F-7659-4021-9452-7953DBF22CFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Phil

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





On 2013-05-17, at 1:08 PM, Mike Jones wrote:

 OAuth 2.0 won the award for best new = standard J).  My feedback on the points raised is inline in = green=E2=80=A6
  for your inline replies, so that it will be easily = evident who said what.  As it is, just the back-and-forth between = Phil and Justin is already very difficult to follow.  = Thanks.)
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Phil = Hunt
Sent: Thursday, May 16, 2013 = 12:54 PM
To: Richer, Justin = P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call = review of = draft-ietf-oauth-dyn-reg-10
 
Thanks for the = discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to = some rough agreement first.  For example, I think we need to have a = away to recognize two pieces of software as being the same (even if = self-asserted).  Once defined, I can put together some intro text, = etc.
Phil
@independentid
It seems = unfortunate that I have not gotten a chance to get into this level of = detail much earlier. But then, I guess that's what LC review is for! My = apologies for not getting many of these concerns to the WG much = earlier.
Overall =  
I think = dynamic registration is a critical part of the OAuth framework now that = we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource = API. We've moved from the simple use case of a single API provider like = Facebook or Flickr and moved on to standards based, open source based, = and commercial based deployments where there are multiple service = endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with = a couple of issues that I would like to see made more clear in early = part of the spec:
1.  How = is a new client application recognized for the first time when deployed = against a particular SP endpoint?  Should clients actually assert = an application_id UUID that never changes and possibly a version id that = does change with versions?
 
In the general case, why is any recognition required? = If you're doing things as part of a larger protocol ecosystem, like Blue = Button+ or a particular OpenID Connect provider, then you can define = semantics for tying together classes of clients (see below for more = discussion on this very point). But in general, a client is just going = to show up as a new instance to the AS and get issued a new, unique = client_id, and that's = that. 
 
I think we = have to define more clearly what an "instance" is. For me, there are = applications and there are instances of that application.  It is = useful to understand that a client application represents a set of code = that should behave in a consistent way.  It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree.
But without = other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other = client instance. Therefore, from the perspective of an AS, the first = instance of an application (i.e., particular configuration of a set of = code) to register is no different to subsequent instances of that same = application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere?
I do agree = that a discussion of "instance vs. application" would be helpful in = clearing this up, I'll make a note to add text to that effect. (We had = to do something similar for = BB+)
I think it is = simple enough to at least add a self generated UUID for the application = ID.  Though I would allow for cases where the application ID is = assigned when the client developer and the APIs owner do a formal = assignment of application IDs.
 
In a sense this is just a lower tech way of doing it = than what you described as the initial client credential in Blue Button+ = where you encoded extra claims into the initial app = credential.
What the UUID = does is link multiple instances of a client app together as the same = "thing" that should have similar heuristics/behaviours.  This is = very useful if you want to be able to revoke access to a set of clients = identified by application id (or a version of that app).
While = I=E2=80=99m sympathetic to the OAuth working group eventually doing work = on differentiating between instances of an OAuth client, I=E2=80=99ll = note that in RFC 6749 or RFC 6750 there is no such thing as a client = instance.  There are only clients, which are identified by = client_id values.  If we want to do work on client instances, we = should recharter to add this new work as a working group = deliverable.  We should not try to shoehorn bits and pieces of it = into the Dynamic Registration spec, any more than we should have tried = to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there = to register clients as defined in RFC 6749.  It=E2=80=99s not the = right place to extend what an OAuth client is in new = ways.
2.  How are client credentials managed. Are we = assuming client credentials have a limited lifetime or rotation = policy?
The intent was = that client_secret could be rotated, as indicated by the expires_at = member of the response. If a client's secret expires, it calls the read = operation on the Client Configuration Endpoint (=C2=A74.2) to get its = new client_secret. If this is unclear in the current text (which I = suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that = clear. 
Something like = this should be in the draft.
 
Should this be up in the introductory text, somewhere = else, or have its own = section?
 
I'm starting to think credential management is a key = part of the draft. It may be worth introducing a specific section = outling the registration life-cycle, registration access token usage, = and client token usage and bootstrapping.
I = think that adding a discussion on this would be fine, as it could help = developers understand the workflow of registering, using, and updating = registered clients.
How does a client authenticate the first time and = subsequent times to the registration = service?
This is a = separate question all together, as it does not involve the client_secret = or client_id at all. Rather, the first time the client shows up to the = registration service, it may either:
  - Not authenticate at all (this is the true = public, open registration, and it is recommended that servers do = this)
 - = Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to = the AS beyond "this client is authorized to register" is out of scope = for the spec, by design.
 
Subsequent times that the same registered client (by = which we mean the same instance of a client with a particular client_id) = shows up at the registration endpoint (actually, the Client = Configuration Endpoint), it uses its Registration Access Token that it = was issued on initial registration. This is an OAuth 2.0 Bearer token = that is unique to the client = instance.
 
Something like = this should be in the draft.
 
OK, the definition of the registration access token can = be expanded, but I think that the rest of it is already in there in =C2=A7= 3. I'd welcome suggestions on which bits of this could be made = clearer.See = the discussion on what the registration_access_token is in the thread = =E2=80=9CClient Credential Expiry and new Registration Access Token - = draft-ietf-oauth-dyn-reg-10=E2=80=9D.  I will work with Justin to = apply these clarifications to the specification.  This may go into = the proposed credential management overview section discussed = above.
3.  How is versioning of clients managed? Should = each new version of a client require a change in client registration = including possibly changing client_id and authentication credential? I = don't have a strong feeling, but it is something that implementors = should consider.
 
This is up to the AS, really, and I don't think that = any global policy would ever fly here. Especially if you consider that = the entire notion of "version" is more fluid these days than it ever has = been. I wouldn't mind adding a discussion in the security considerations = if it merits mentioning though, so that we can help both client = developers and server developers institute reasonably good = policy.
 
I guess the = issue is that when a client upgrades it may have access to the old = credentials. What is the intent then of registration.  Since you = have an update are clients expected to update /re-register or not? =  I'm not sure this is a security consideration but more part of the = whole change management function dynamic registration = supports.
If your = upgraded version of the client still has access to its old credentials, = why wouldn't it just use those? I don't see a reason for forcing a = re-registration. Nor do I see any way that an AS would even be able to = tell that a client had been upgraded. An upgraded client always has the = *option* of re-registering itself and getting a new = client_id. 
I think the concern here is that rotation of client = credential is not something discussed before. Before we put it in the = spec we should consider the reasons for doing it and what problems it = solves.
I think this = may be just a case of letting people exchange credentials for whatever = reason they feel is appropriate.  The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register".  Depending on the policy of the server, it = may (or may not) receive a new client_id and/or new credential. =  
One of the = best benefits I can think of is if you discover a version of a client = has a problem, being able to select a group of clients by software and = version is important. Thus if client_id doesn't trace to a particular = software and version, that makes it hard to do.  I  think you = talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client = instances or groups of clients, therefore I believe that it=E2=80=99s = inappropriate to do so here.  We don=E2=80=99t need to boil the = ocean.  If a new charter item is approved to do work on client = instances and protocol elements to use and express them, that=E2=80=99s = the time for the working group to consider that possibility =E2=80=93 = not as part of Dynamic Client Registration.
4.  What is the = registration access token? Why is is used? What is its life-cycle? =  When is it issued, when is it changed? When is it = deleted?
See the = response above above and the definition in = =C2=A71.2: 
Registration Access Token: An OAuth 2.0 Bearer Token = issued by the Authorization Server through the Client Registration = Endpoint which is used by the Client to authenticate itself during read, = update, and delete operations. This token is associated with a = particular = Client.
 
If this can be clarified, I welcome text = suggestions.
 
The latter = part of 1.2 didn't seem like terminology but rather architecture or part = of the introduction that describes what the spec does. The third point = doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration = access tokens.
Client = Registration Endpoint: The OAuth 2.0 Endpoint through = which
      a =
Client can request new registration.  The means of the =
Client
      =
obtaining the URL for this endpoint are out of scope for =
this
      =
specification.
 
      which =
a specific Client can manage its registration =
information,
      =
provided by the Authorization Server to the Client.  This URL =
for
      this endpoint =
is communicated to the client by the =
Authorization
      =
Server in the Client Information Response.
   o  Registration =
Access Token: An OAuth 2.0 Bearer Token issued by =
the
      Authorization =
Server through the Client Registration =
Endpoint
      which =
is used by the Client to authenticate itself during =
read,
      =
update, and delete operations.  This token is associated with =
a
      particular =
Client.
 
This section is meant to just introduce the new terms = that are then explained in greater detail throughout the rest of the = document. Yes, it's a bit architecture, but only in the sense that you = need to define the terms that make up your architecture. How would you = suggest that it change?
 
Probably this = is more a matter of style.  But, what happened for me is I = naturally skipped the terminology section, as I wasn't expecting = protocol components to be there.  "terminology" is something I = think people tend to use as a dictionary rather than as protocol = component description.  Maybe the chairs can = advise?
If we distinguish between first time registration of a = particular client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri).  I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance.
When = subsequent instances register, I have to ask the question, for example = when would things like "token_endpoint_auth_method" be negotiated or be = different for the same client software? Should not all instances use the = same authentication = method.
 
I'm confused by this -- as far as the dynamic = registration spec is concerned, all instances are separate from each = other. All parameters change per instance. And instance, you should keep = in mind, is defined as any one copy of the client code connecting to any = new authorization server. That pairing creates the client_id, and = therefore the instance, and therefore the registration access token, and = therefore the registration itself at a conceptual level. So there is no = way other than per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about = it?
 
We still disagree on this. It is my assertion that = clients should NEVER ask for a particular token auth method. Since it is = the AS that is authenticating the client, then it is the AS's right to = set the authentication policy.  The role of dynamic reg endpoint is = to inform the client what it must do.  My assumption is that during = the first time a piece of software is registered (the first instance), = there could be some OOB discussion by an administrator to approve the = particular authentication type for the AS in = question.
I haven't = heard a reason justifying this parameter other then "it is needed". =  Why?
 
The role of the dynamic registration protocol is = twofold: half of that is the server informing the client what it must = do. But the other half is the client informing the server what it *can* = do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first = instance from a subsequent instance unless you're doing something in = addition. Nothing is stopping the same application from registering a = new instance of itself for every single user or every single token that = it wants to get access for. That's complicated and wasteful and not a = great idea, sure, but  there's no useful way to prevent that kind = of behavior if you also want open registration of = clients. 
 
I think we've = discussed how recognizing subsequent instances is easily = done.
As I mentioned = in the other thread, if a developer chooses to limit the capabilities of = the client it must do so by looking to the developer or standard behind = the API.  Otherwise they are taking the chance.  There's no = way a developer can query all the potential deployers to ask what authn = types will you use. As I said, the net effect in the absence of an API = standard dictating what should be supported, the developer will have to = implement all methods.
 
My point here is that none of this is helped by the = client app saying what it supports. A developer who takes the route of = limiting implementation takes the chance that the server will not = accept.  So why negotiate within = registration?
And there's no way other than per-instance for the = server to tell the client which token_endpoint_auth_method to use. All = instances will probably ask for the same token_endpoint_auth_method from = all auth servers they talk to, right? And each AS will tell each = instance that registers with it to use a particular auth method. There = is no way to tie together different instances across (or within) auth = servers without specifying a significant amount of other = machinery.
Which is not to say that it's not useful in some circumstances = to tie together different instances of the same code across (or within) = auth servers. This is why, with Blue Button+, we specified a specific = token format for the initial access token that the clients use to call = the registration endpoint the first time,  as well as a discovery = protocol against a centralized server that handles pre-registration. All = of this machinery is, in my opinion, a stupendous overkill for the = general case, though if some folks find use for it outside of BB+ then = it'd be a good thing to abstract out and make its own spec that extends = the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue = Button+ we specify that all auth servers MUST also accept open = registration, without an initial access token, where the client simply = shows up and says "hey, here are my parameters." The auth server has no = way to know in this case any kind of out-of-band negotiation for = different things. In BB+ we are writing very specific policy guidelines = about how to present the UX and things to the end user for all of these = different cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its = own. I believe it would be far too limiting.

 
See my previous comments on = differentiating client instances being out of scope without rechartering = to do this new work and on what the registration_access_token is.  = In short, the registration_access_token is an RFC 6750 bearer token = issued to the party registering the client, enabling it to subsequently = retrieve information about the client registration and to potentially = update the registration information for that registered client.  = Again, I=E2=80=99ll work with Justin to make sure that this is as clear = as possible in the specification.
* Currently, the API only supports a single value = instead of an array.  If the purpose is to allow the client to know = what auth methods it supports, this should be an array indicated what = methods the client supports - or it should not be = used.
I would rather = like this to be an array, personally, and brought it up with the OpenID = Connect working group about six months ago. But there it was decided = that a single value was simpler and sufficient for the purpose. The IETF = draft has inherited this decision. I *believe* (though am not 100% = positive) that I brought up this very issue in the WG here but didn't = receive any traction on it, so single it = remains.
 
I can get = behind multiple values. In this case, it changes the meaning of the = parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can = perform. This allows the server to assign the appropriate method based = on its own policy.

Also note that = this field, like all others in =C2=A72, represents two things: the = client telling the server "I want to use this value for this field", and = the server telling the client "this is the value you have for this = field". It's not exactly a negotiation, more like making a polite = request to an absolute dictator who has the last word anyway. But at = least this dictator is nice enough to tell you what their decision was = instead of just decapitating you.
=E2=80=9CAs such, a server = supporting these fields SHOULD take steps to ensure that a client = cannot register itself into an inconsistent state.=E2=80=9D

We = may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code = (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?
<= div>
 
I'd be fine with defining a more explicit error state = in this case. I think it would help interop for the servers that want to = enforce grant-type and response-type restrictions, but servers that = can't or don't care about restricting grants types and whatnot don't = have to do anything special.
I = *think* that this goes away with the deletion of = client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6&nb= sp; I=E2=80=99ll do a consistency check and verify that when the spec is = updated accordingly.
Section = 2.2 
May want to = add:
 
When =E2=80=9C#=E2=80= =9D language tag is missing, (e.g. =E2=80=9C#en=E2=80=9D is missing in = =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_name#en=E2=80= =9D) the OAuth server may use interpret the language used = based on server configuration or = heuristics.
That seems = inconsistent with what we already have:
 
If any human-readable field is sent without a language = tag, parties using it MUST NOT make any assumptions about the language, = character set, or script of the string value, and the string value MUST = be used as-is wherever it is presented in a user = interface.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0.5in; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "> 
Which is to say, treat it as a raw byte-value-string = and don't try to get = fancy.
 
I will discuss = with our developers. I'm not sure the as-is works. =  
Is it the = intent that when the client has localized "client_name" for example, it = should pass all language variations in a JSON = array?
Or, should = part of the registration be to indicate which interface language the = client wishes to use?  Then it only passes a single value for that = registration?
 
 
No, the client should pass parameters as multiple = separate values. Connect has this in its = example:
   = "client_name": "My Example",
   =
"client_name#ja-Jpan-JP":
     =
"
Should we add that to at least = one of the examples in DynReg? (The language tags are a late addition, = so the examples don't reflect = it.)
 
An example would definitely = help.
If the client passes only a single unadorned field, the = AS can't make any assumption about what language it is. Think of this as = the internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with = it.
Passing in a = "default" language field (like default_locale or the like) is only going = to lead to pain for implementors of both clients and servers, and it's = going to hurt the interoperability of the human-readable = fields. 
 
I think what I meant is since you are allowing each = client to register different things, AND the client likely already knows = the user's preferred language, why wouldn't the client just pass text = values in one language and another parameter indicating preferred = language in the case of any service generated = text.
Is the reason = you are passing multiple localizations is so that you can use the = preferred language of the resource owner rather then the client user? I = wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app = expect?
----> any = multi-lingual people have any opinions = here?
 
Without specific proposed text = changes to review, it=E2=80=99s hard to know what to think about this = comment.  Unless a specific proposed text change is sent to the = list with clear rationale for why it=E2=80=99s better than what=E2=80=99s = there now and reviewed by the working group, I don=E2=80=99t believe we = should change the specification in response to this = comment.
Section = 3
Existing = text:

=E2=80=9CIn order to = support open registration and facilitate wider interoperability, = the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication.  These = requests MAY be rate-limited or otherwise limited to prevent a = denial-of-service attack on the Client Registration = Endpoint.=E2=80=9D

I would suggest to change the first = =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY=E2=80=9D.   In most = cloud services, the first client is registered by a human user. = Then, other clients can be further used to automate other = client registration.  So, the first request would = typically come with an authenticated user = identity. 
=
I think the = weight of "SHOULD" is appropriate here, because I believe that turning = off open registration at the AS (which is what this is talking about) = really ought to be the exception rather than the = rule. 
 
I think you = are reading it wrong -- a double-negative issue. The end of the sentence = is "no authentication".  You are implying that NO Authentication us = what should normally be done. I think you intend anonymous = authentication to be the exception rather than the rule don't = you?
No, I think = that anonymous authentication should be the rule. Open registration = should be = default. 
 
I disagree.  Again,  the spec seems = contradictory. It suggests strong client auth methods and at the same = time anonymous registration.  Yes you gain uniqueness, but that's = about it.

On the = flip side, the earlier paragraph:

=E2=80=9CThe 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.=E2=80=9D

I tend to think it would be better = to change this =E2=80=9CMAY=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.

T= hat access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.Again, = disagree, for the same reasoning as = above.
 
Same = reasoning. 

I agree with = Justin here.  The default should be that open registrations are = enabled.  The exception case is that specific permissions are = required to perform dynamic client = registration.

About = section 4.3: 
If the client does not exist on this =
server, the server MUST respond
   make this request =
SHOULD be immediately revoked.
 
If the Client does not exist on this server, = shouldn't it return a "404 Not Found"?

If revoking the = registration access token, is it bound to a single client registration? =  This is not clear.  What is the lifecycle around registration = access token? Only hint is in the Client Information Response in section = 5.1.
=
 
The language about the 401 here (and in other nearby = sections) is specifically so that you treat a missing client and a bad = registration access token the same way. You see, returning a 404 = here actually indicates things were in an inconsistent state. Namely, = that the registration access token was still valid but the client that = the registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token.
 
Since the intent of the registration access token is = that it's bound to a single instance, its lifecycle is generally tied to = the lifecycle begins at the issuance of a new client_id with that = instance. That token might be revoked and a new one issued on Read and = Update requests to the Client Configuration Endpoint (and the client = needs to be prepared for that -- same as the client_secret), and it will = be revoked when the client is deleted either with a Delete call to the = Client Configuration Endpoint or something happening out-of-band to kill = the client. 
Should we add = more explanatory text to the definition in the terminology section? = Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd = like.
I think we = should look at it.

For security = reasons, it=E2=80=99s generally not good to distinguish between =E2=80=9Cn= ot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors in = responses, as that can provide the attacker an oracle to probe whether a = particular entity exists  I don=E2=80=99t think a change is called = for here.

About = section 5.1:Is registration_access_token unique?  Or is it = shared by multiple instances?   If shared, then = registration_access_token can't be revoked on delete of = client.
 
The registration_access_token is = unique to a registered client, in the RFC 6749 sense of = =E2=80=9Cclient=E2=80=9D.  Again, if we want to do work on = =E2=80=9Cclient instances=E2=80=9D, we need to recharter and take this = distinct work item up explicitly.

Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to = rename =E2=80=9Cissued_at=E2=80=9D to = =E2=80=9Cid_issued_at=E2=80=9D
While I do = like the suggestion of changing these to client_secret_expires_at and = client_id_issued_at, and I think these are more clear and = readable,
I don't want = to change the syntax during last call unless there is a clear need and a = clear consensus for doing so.
 
That's why we = are having last call. To confirm consensus on the = draft. 
Same reasoning = as earlier. You now have multiple tokens (registration access and = client) in play. The spec needs to be clear which one it is talking = about.
I'm fine with = the suggested change but I would like more feedback from other people = before moving forward with it. There's a lot of value in "just pick a = name and ship it" as well though, and I don't want to devolve into bike = shedding. (I'm not accusing you of bike shedding quite yet, btw, just = afraid of getting into a long debate on = names.)
Again, this = was a problem raised by people new to the specification. They found it = confusing. I tend to agree. We're not talking about what colour to paint = the shed. We're talking about whether the bike shed is a = house.  :-) 
 
I'm not too fussed about whether you call it = "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of = =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2=80=9D are unclear, = we should clarify them.  If you believe that this is the case Phil, = can you supply proposed alternative definition text that is = clearer?  That being said, I believe that at this point we should = stick with the existing protocol element names unless overwhelming = working group sentiment emerges to change them.  They are already = working fine as-is in production = deployments.
Section 7
 
When a client_secret expires is it the intent that = clients do an update or refresh to get a new client = secret?
 
Yes, the client is supposed to either call the read or = update methods on the client configuration endpoint to get its new = secret. As discussed above, I'm not sure that's as clear as it needs to = be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on = the behalf of clients, depending upon context.  I support adding = text to clarify this.
Again, thanks for the very thorough read through. Have = you implemented any of the spec yet, either as-is or with any of your = suggested changes?
 
Yes. Much of = the feedback is coming from our development = community. 
 
Ah, very cool. Developer experience is the most = valuable feedback, in my opinion. If you can't actually build the = blasted thing, what good is it? :)
Glad = to hear that you=E2=80=99re working with developers building the = spec.  Please thank them for the = feedback.
 -- = Justin Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 23:30:00 -0000 John, Thanks for jumping in. 1. I do buy the implied argument that some client credential types do = expire (eg. bearer assertions). Therefore the expiry issue has to be = dealt with. I would prefer to handle this by allowing an exception = whereby expired assertions could be used to re-register (only). This = shouldn't be a big security issue since we're talking about an expired = client refreshing with its issuer rather then a third party trusting an = expired token.=20 I just don't think adding another token, the registration access token, = that in turn (by your argument) should expire, actually helps. It just = adds another layer to the problem and increases complexity. It solves = nothing. 2. You seem to be describing a different usage than Justin is. The way = he explains the draft, there is no developer cycle at all. He's saying = every client gets a registration token and a client token. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 10:40 AM, John Bradley wrote: > 1 No reasonable security profile is going to let you use the same = symmetric password over long time periods. It will be brute forced = given enough time. =20 > The rotation time will depend on entropy and the rate an attacker can = submit attempts. I would expect profiles to look at SP-800-63 for = guidance as essentially a password for the client. >=20 > 2 the registration interface is likely used by a developer who = probably doesn't want the client instances (say native clients) to be = able to update the configuration directly. using the client secret = credential for updates would break the separation. Registration my be = done by the client itself or by a developer as a separate process. >=20 > John B. >=20 > On 2013-05-17, at 7:27 PM, Phil Hunt wrote: >=20 >> Justin, >>=20 >> Your reason was you copied connect. Ok. I was looking for a technical = reason. A security reason. >>=20 >> BTW. Mike Jones says expiry wasn't the reason. =20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-17, at 9:01 AM, Justin Richer wrote: >>=20 >>> The separation between these two is necessary: Not all clients have = client_secret, and you want the lifecycle/management of the registration = to be protected. This is what the registration access token was made = for. In older versions of Connect's registration, the client_secret was = forced on all clients in order to provide this, but then you had public = clients with a client_secret that they couldn't use to get tokens, and = it was a bad disconnect. >>>=20 >>> The requirement for client secrets to expire or otherwise be rotated = by the server came from several implementors in the Connect WG. There's = an easy way to indicate that they don't expire, and a fairly = straightforward way for them to be rotated (client does a GET on its = client configuration endpoint url, with its registration access token as = auth). >>>=20 >>> -- Justin >>>=20 >>> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>>> All, >>>>=20 >>>> In the dynamic registration draft, a new token type is defined = called the "registration access token". Its use is intended to = facilitate clients being able to update their registration and obtain = new client credentials over time. The client credential is issued on = completion of the initial registration request by a particular client = instance. >>>>=20 >>>> It appears the need for the registration access token arises from = the implied assertion that client credentials should expire. >>>> --> Is anyone expiring client credentials? >>>>=20 >>>> To date, we haven't had much discussion about client credential = expiry. It leads me to the following questions: >>>>=20 >>>> 1. Is there technical value with client credential/token expiry? = Keep in mind that client credential is only used with the token endpoint = over TLS connection. It is NOT used to access resources directly. >>>>=20 >>>> 2. If yes, on what basis should client credential/token expire? >>>> a. Time? >>>> b. A change to the client software (e.g. version update)? >>>> c. Some other reason? >>>>=20 >>>> 3. Is it worth the complication to create a new token type = (registration access token) just to allow clients to obtain new client = tokens? Keep in mind that client tokens are only usable with the AS = token endpoint. Why not instead use a client token for dyn reg and = token endpoint with the rule that once a client token has expired (if = they expire), an expired token may still be used at the registration = end-point. >>>>=20 >>>> 4. Are there other reasons for the registration token? >>>>=20 >>>> Thanks, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From Michael.Jones@microsoft.com Fri May 17 16:34:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1D621F9673 for ; Fri, 17 May 2013 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yRLbgbMiHDl for ; Fri, 17 May 2013 16:34:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3336021F9672 for ; Fri, 17 May 2013 16:34:33 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.200) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.687.1; Fri, 17 May 2013 23:34:29 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Fri, 17 May 2013 23:34:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Fri, 17 May 2013 23:33:45 +0000 From: Mike Jones To: Phil Hunt , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOU0Vq52T5G6iNqEO/gOZQ7lhvS5kKADdw Date: Fri, 17 May 2013 23:33:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367734CE0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367734CE0TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(50854003)(377424003)(189002)(199002)(377454002)(66654002)(85644002)(54094003)(51914003)(24454002)(15454003)(51444003)(59766001)(16406001)(4396001)(81542001)(47736001)(15974865001)(47976001)(56776001)(79102001)(74662001)(53806001)(16236675002)(16601075002)(69226001)(65816001)(71186001)(15202345002)(81342001)(31966008)(20776003)(74502001)(47446002)(46102001)(80022001)(66066001)(44976003)(54316002)(63696002)(56816002)(15395725003)(54356001)(49866001)(50986001)(77982001)(76482001)(55846006)(512874002)(74366001)(561944002)(33656001)(6806003)(51856001)(74706001)(74876001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 May 2013 23:34:42 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367734CE0TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjIGV4aXN0cyB0byBlbmFibGUgdGhl IGRldmVsb3BlciBvZiBhIHBpZWNlIG9mIGNvZGUgdG8gcmVnaXN0ZXIgdGhhdCBjb2RlIHdpdGgg YW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gb2J0YWluIGEgY2xpZW50X2lkIChhbmQgc29tZXRp bWVzIGNsaWVudF9zZWNyZXQpIHNvIHRoYXQgdGhlIGNvZGUgY2FuIG1ha2UgYXV0aG9yaXphdGlv biByZXF1ZXN0cyB0byB0aGF0IEFTLiAgSXQgZW5hYmxlcyBPQXV0aCBjbGllbnQgcmVnaXN0cmF0 aW9ucyB0byB1c2Ugc3RhbmRhcmQgcHJvdG9jb2wgaW50ZXJhY3Rpb25zLCByYXRoZXIgdGhhbiBh bHdheXMgdXNpbmcgY3VzdG9tIHByb2NlZHVyZXMgYXQgZXZlcnkgQVMuICBUaGF0IHNlZW1zIHBy ZXR0eSB2YWx1YWJsZSB0byBtZS4NCg0KSWYgeW91IHNlZSBubyB2YWx1ZSBpbiBoYXZpbmcgY2xp ZW50cyBhbm9ueW1vdXNseSByZWdpc3RlcmluZyB3aXRoIEF1dGhvcml6YXRpb24gU2VydmVycyB0 byBvYnRhaW4gY2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0IHZhbHVlcywgdGhlbiB0aGF0IGlt cGxpZXMgdGhhdCB5b3Ugc2VlIG5vIHZhbHVlIGluIG9wZW4gaWRlbnRpdHkgaW50ZXJhY3Rpb25z IGluIHdoaWNoIFJlbHlpbmcgUGFydGllcyB0aGF0IGhhdmUgbm90IHByZXZpb3VzbHkgdXNlZCBh biBJZGVudGl0eSBQcm92aWRlciBjYW4gZHluYW1pY2FsbHkgY29ubmVjdCB0byB0aGF0IHByb3Zp ZGVyIGFuZCB1c2UgYXNzZXJ0aW9ucyBpc3N1ZWQgYnkgdGhhdCBwcm92aWRlci4gIFlldCBJIGRv dWJ0IHRoYXQgdGhhdCB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdC4gIElmIHJwLmV4YW1wbGUuY29t IGhhc27igJl0IHVzZWQgaWRwLmV4YW1wbGUubmV0IGJlZm9yZSBhbmQgTWFyeSB3YW50cyB0byB1 c2UgaGVyIG1hcnlAaWRwLmV4YW1wbGUubmV0IGlkZW50aXR5IHRvIHNpZ24gaW50byBycC5leGFt cGxlLmNvbSwgdGhpcyBpcyBleGFjdGx5IHdoYXTigJlzIG5lZWRlZC4gIE1heWJlIHlvdSB3YW50 IHRvIHJldmlzZSB5b3VyIHN0YXRlbWVudCBhYm91dCDigJxzZWVpbmcgbm8gdmFsdWXigJ0gdG8g c29tZXRoaW5nIG1vcmUgcHJhZ21hdGljIGxpa2Ug4oCcSSBmb3Jlc2VlIGNpcmN1bXN0YW5jZXMg aW4gd2hpY2ggaXQgd291bGQgYmUgdmFsdWFibGUgdG8gbWFuYWdlIGluc3RhbmNlcyBvZiBhbiBP QXV0aCBjbGllbnQu4oCdPw0KDQpJIGRvbuKAmXQgc2VlIHlvdXIgc3RhdGVtZW50IGFib3V0IOKA nHRoZSBuZXcgZHJhZnQgdGhhdCBkb2VzIHNvbHZlIGl0IHdvdWxkIGxpa2VseSBiZSA5NSUgb3Zl cmxhcOKAnSBhcyBhIG5lZ2F0aXZlIOKAkyByYXRoZXIsIEkgc2VlIGl0IGFzIHlvdSBzYXlpbmcg dGhhdCB0aGUgY3VycmVudCBkcmFmdCBhbHJlYWR5IHByb3ZpZGVzIDk1JSBvZiB0aGUgZnVuY3Rp b25hbGl0eSBuZWVkZWQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBjbGllbnQgaW5zdGFuY2VzLiAgVGhl IG1ldGFkYXRhIGZpZWxkIHNldCBpcyBpbnRlbnRpb25hbGx5IGV4dGVuc2libGUuICBSYXRoZXIg dGhhbiBkdXBsaWNhdGluZyB0aGUgOTUlLCBJIHN1c3BlY3QgdGhhdCB0aGUgbmV3IGRyYWZ0IHRo YXQgeW91IGVudmlzaW9uIHdvdWxkIGFjdHVhbGx5IGp1c3QgZGVmaW5lIGV4dGVuc2lvbnMgZm9y IHRoZSBhZGRpdGlvbmFsIDUlIGZ1bmN0aW9uYWxpdHkgbmVlZGVkIGZvciB0aGF0IHVzZSBjYXNl LCBhbmQgdXNlIHRoZSBleGlzdGluZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9u Lg0KDQpEbyB5b3UgaGF2ZSBhIGNvbmNyZXRlIHByb3Bvc2FsIGZvciB3aGF0IHRoZSBhZGRpdGlv bmFsIDUlIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlPyAgV2l0aG91dCB1bmRlcnN0YW5kaW5nIHdo YXQgbmV3IG9iamVjdHMgYW5kIG9wZXJhdGlvbnMgdGhhdCB5b3UgYmVsaWV2ZSB3ZSB3b3VsZCB3 YW50IHRvIGhhdmUgZm9yIHRoaXMgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5LCB0aGUgZGlzY3Vz c2lvbnMgd2lsbCByZW1haW4gYXQgYSBoeXBvdGhldGljYWwgcGxhbmUsIGF0IGJlc3QuDQoNCkkg YWxzbyBiZWxpZXZlIHRoYXQgd2hhdCB5b3Ugd2FudCB1cyB0byB3b3JrIG9uIGlzIHJlYWxseSBP QXV0aCBDbGllbnQgSW5zdGFuY2UgTWFuYWdlbWVudCBmdW5jdGlvbmFsaXR5IOKAkyBvZiB3aGlj aCByZWdpc3RyYXRpb24gaXMgb25seSBvbmUgcGFydC4gIEnigJlkIHJlYWxseSBsaWtlIHRvIHNl ZSBhIGNvbmNyZXRlIHByb3Bvc2FsIGFsbC11cCDigJMgcHJlZmVyYWJseSBhcyBhbiBJbnRlcm5l dCBEcmFmdCDigJMgYmVmb3JlIHdlIGV2ZW4gY29uc2lkZXIgZG9pbmcgdGhlIHJlZ2lzdHJhdGlv biBwaWVjZSBvZiBpdC4gIE90aGVyd2lzZSB3ZeKAmXJlIGNlcnRhaW4gdG8gbWlzcyB0aGluZ3Mg YW5kIGdldCBpdCB3cm9uZyBpZiB3ZSBhdHRlbXB0IHRoaXMgb24gYSBwaWVjZW1lYWwgYmFzaXMu DQoNCkFnYWluLCBJ4oCZbSBub3QgZGViYXRpbmcgdGhhdCBjbGllbnQgaW5zdGFuY2UgbWFuYWdl bWVudCBjb3VsZCBiZSB2YWx1YWJsZSBpbiBzb21lIHVzZSBjYXNlcy4gIEluIGZhY3QsIEnigJlt IHN1cmUgdGhhdCB0aGF04oCZcyB0aGUgY2FzZS4gIEJ1dCBJIGJlbGlldmUgdGhhdCB0aGlzIGlz IGEgc2lnbmlmaWNhbnQgZW5vdWdoIHdvcmsgaXRlbSB0aGF0IGl0IHNob3VsZCBoYXZlIGl0cyBv d24gZHJhZnQocykgYW5kIGJlIGRlYmF0ZWQgb24gaXRzIG93biBtZXJpdHMuDQoNCldlIHNob3Vs ZG7igJl0IGhvbGQgdXAgdGhlIGV4aXN0aW5nIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBz cGVjIGZvciB0aGlzIG5vdC13cml0dGVuLWRvd24gYW5kIHNwZWN1bGF0aXZlIGZ1bmN0aW9uYWxp dHkgd2hlbiBpdOKAmXMgYWxyZWFkeSBiZWVuIGRlbW9uc3RyYXRlZCB0byB3b3JrIHdlbGwgZm9y IGR5bmFtaWNhbGx5IHJlZ2lzdGVyaW5nIGNsaWVudHMsIHdoZXJlIHRoZSBjbGllbnRzIGFyZSBh cyBkZWZpbmVkIGluIFJGQyA2NzQ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUGhpbCBIdW50DQpTZW50OiBGcmlkYXksIE1heSAxNywgMjAxMyAyOjI3IFBN DQpUbzogb2F1dGhAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFtPQVVUSC1XR10gQ2xpZW50IEluc3Rh bmNlcyBvZiBBbiBBcHBsaWNhdGlvbiAtIFdhczogUmU6IExhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEwDQoNCk1pa2UsDQoNClJhdGhlciB0aGVuIGVtYmVkIGNv bW1lbnRzIGluIGFuIGV4dGVuZGVkIHRocmVhZCwgSSdkIGxpa2UgdG8gb3BlbiB1cCBhIHNwZWNp ZmljIGRpc2N1c3Npb24gb24gdGhlIG9iamVjdGl2ZSBvZiBkeW4gcmVnLg0KDQpJIHNlZSBsaW1p dGVkIHRvIG5vIHZhbHVlIGluIGhhdmluZyBjbGllbnRzIGNvbXBsZXRlbHkgYW5vbnltb3VzbHkg cmVnaXN0ZXJpbmcgYW5kIHJlY2VpdmluZyB0b2tlbnMgd2l0aG91dCBhbnkgYWJpbGl0eSB0byBj b3JyZWxhdGUgYXBwbGljYXRpb25zIGJldHdlZW4gYXBwbGljYXRpb25zLg0KDQpBc3NvY2lhdGlu ZyBjbGllbnRfaWQncyB3aXRoIGtub3duIGNsaWVudCBhcHBsaWNhdGlvbnMgdG8gYWxsb3cgYWRt aW5zIHRvIGtub3cgd2hvIGlzIHJ1bm5pbmcgd2hhdCB2ZXJzaW9uIG9mIGNsaWVudHMgc2VlbXMg dG8gYmUgdGhlIG1vc3QgZnVuZGFtZW50YWwgcGFydCBvZiB0aGUgcmVhc29uIGZvciBkeW5hbWlj IHJlZy4gSG93IGNhbiB5b3UgcmV2b2tlIGFjY2VzcyB0byBwYXJ0aWN1bGFyIGNsaWVudCBhcHAg dHlwZXM/ICBBcyBKdXN0aW4gYWxyZWFkeSB0YWxrZWQgYWJvdXQgaW4gaGlzIEJsdWUgQnV0dG9u KyBzY2VuYXJpbywgdGhlcmUgYXJlIG9mdGVuIGxpZmUgYW5kIGRlYXRoIHNpdHVhdGlvbnMgd2hl cmUgcGFydGljdWxhciBzZXRzIG9mIGNsaWVudHMgbmVlZCB0byBiZSByZXZva2VkLg0KDQpPciBw dXQgYW5vdGhlciB3YXkuIEkgYmVsaWV2ZSB0aGlzIHdpbGwgYmUgYSBjcml0aWNhbCBvcGVyYXRp b25hbCByZXF1aXJlbWVudCBnb2luZyBmb3J3YXJkcy4gSWYgdGhlIHNwZWMgaXMgcHVibGlzaGVk IGFzIGlzLCBpdCB3aWxsIGJlIHF1aWNrbHkgaW52YWxpZGF0ZWQgYnkgb25lIHRoYXQgZG9lcyBh dCBsZWFzdCBwYXJ0aWFsbHkgYWRkcmVzcyB0aGUgcHJvYmxlbS4NCg0KV2UncmUgYWhlYWQgb2Yg c2NoZWR1bGUsIGxldHMgdGFsayB0aHJvdWdoIHRoZSByZXF1aXJlbWVudC4NCg0KQXMgSSBtZW50 aW9uZWQgaW4gbXkgY29tbWVudHMgdG8gdGhlIG90aGVyIHRocmVhZC4gTGV0J3Mgc2F5IHdlIGFn cmVlIG5vdCBkbyB0aGlzIG5vdy4gV2VsbCwgdGhlbiB0aGUgbmV3IGRyYWZ0IHRoYXQgZG9lcyBz b2x2ZSBpdCB3b3VsZCBsaWtlbHkgYmUgOTUlIG92ZXJsYXAuICBUaHVzIEkgc2VlIHRoaXMgaXNz dWUgYXMgd2l0aGluIGNoYXJ0ZXIgYW5kIHNob3VsZCBiZSBzb2x2ZWQgbm93IHJhdGhlciB0aGVu IHdhaXRpbmcgZm9yIGEgVjIgZHluIHJlZyBpbiB0aGUgbmV4dCBjaGFydGVyLg0KDQpQaGlsDQoN CkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbT4NCg0KDQoNCg0KT24gMjAxMy0wNS0xNywgYXQgMTowOCBQTSwgTWlrZSBKb25lcyB3cm90 ZToNCg0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCBmZWVkYmFjaywgUGhpbC4gIFNvcnJ5IGZv ciB0aGUgZGVsYXllZCByZXNwb25zZSDigJMgSSB3YXMgcHJldHR5IGZ1bGx5IGVuZ2FnZWQgYXQg dGhlIEV1cm9wZWFuIElkZW50aXR5IENvbmZlcmVuY2UgKHdoZXJlIE9BdXRoIDIuMCB3b24gdGhl IGF3YXJkIGZvciBiZXN0IG5ldyBzdGFuZGFyZDxodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0x MDI2PiDimLopLiAgTXkgZmVlZGJhY2sgb24gdGhlIHBvaW50cyByYWlzZWQgaXMgaW5saW5lIGlu IGdyZWVu4oCmDQoNCihQZXJoYXBzIGlmIGFueSBvZiB5b3UgcmVwbHkgdG8gdGhpcyB0aHJlYWQs IHlvdSBjb3VsZCBhbHNvIGNob29zZSBhIGRpc3RpbmN0IGNvbG9yIGZvciB5b3VyIGlubGluZSBy ZXBsaWVzLCBzbyB0aGF0IGl0IHdpbGwgYmUgZWFzaWx5IGV2aWRlbnQgd2hvIHNhaWQgd2hhdC4g IEFzIGl0IGlzLCBqdXN0IHRoZSBiYWNrLWFuZC1mb3J0aCBiZXR3ZWVuIFBoaWwgYW5kIEp1c3Rp biBpcyBhbHJlYWR5IHZlcnkgZGlmZmljdWx0IHRvIGZvbGxvdy4gIFRoYW5rcy4pDQoNCkZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2Vu dDogVGh1cnNkYXksIE1heSAxNiwgMjAxMyAxMjo1NCBQTQ0KVG86IFJpY2hlciwgSnVzdGluIFAu DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRw0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gTGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWR5bi1y ZWctMTANCg0KSnVzdGluLA0KDQpUaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBNb3JlIGNvbW1l bnRzIGJlbG93Li4uDQoNCkJUVy4gSSdtIGhhcHB5IHRvIGNvbnRyaWJ1dGUgdGV4dC4gSnVzdCB3 YW50IHRvIGdldCB0byBzb21lIHJvdWdoIGFncmVlbWVudCBmaXJzdC4gIEZvciBleGFtcGxlLCBJ IHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBhIGF3YXkgdG8gcmVjb2duaXplIHR3byBwaWVjZXMgb2Yg c29mdHdhcmUgYXMgYmVpbmcgdGhlIHNhbWUgKGV2ZW4gaWYgc2VsZi1hc3NlcnRlZCkuICBPbmNl IGRlZmluZWQsIEkgY2FuIHB1dCB0b2dldGhlciBzb21lIGludHJvIHRleHQsIGV0Yy4NCg0KUGhp bA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPg0KDQpPbiAyMDEzLTA1LTE2LCBhdCA1OjE2IEFNLCBSaWNoZXIsIEp1c3RpbiBQ LiB3cm90ZToNCg0KT24gTWF5IDE1LCAyMDEzLCBhdCAxMDozMCBQTSwgUGhpbCBIdW50IDxwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KIHdyb3RlOg0K DQpPbiAyMDEzLTA1LTE1LCBhdCA1OjUzIFBNLCBSaWNoZXIsIEp1c3RpbiBQLiB3cm90ZToNCg0K UGhpbCwgbWFueSB0aGFua3MgZm9yIHRoZSBleHRyZW1lbHkgdGhvcm91Z2ggcmV2aWV3ISBJdCBp cyB2ZXJ5IHVzZWZ1bCBpbmRlZWQuDQoNCk15IGNvbW1lbnRzIGFuZCByZXNwb25zZXMgdG8gZWFj aCBwb2ludCBhcmUgaW5saW5lLg0KDQpPbiBNYXkgMTUsIDIwMTMsIGF0IDQ6MzAgUE0sIFBoaWwg SHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4g d3JvdGU6DQoNCkl0IHNlZW1zIHVuZm9ydHVuYXRlIHRoYXQgSSBoYXZlIG5vdCBnb3R0ZW4gYSBj aGFuY2UgdG8gZ2V0IGludG8gdGhpcyBsZXZlbCBvZiBkZXRhaWwgbXVjaCBlYXJsaWVyLiBCdXQg dGhlbiwgSSBndWVzcyB0aGF0J3Mgd2hhdCBMQyByZXZpZXcgaXMgZm9yISBNeSBhcG9sb2dpZXMg Zm9yIG5vdCBnZXR0aW5nIG1hbnkgb2YgdGhlc2UgY29uY2VybnMgdG8gdGhlIFdHIG11Y2ggZWFy bGllci4NCg0KT3ZlcmFsbA0KLS0tLS0tLS0tLS0NCkkgdGhpbmsgZHluYW1pYyByZWdpc3RyYXRp b24gaXMgYSBjcml0aWNhbCBwYXJ0IG9mIHRoZSBPQXV0aCBmcmFtZXdvcmsgbm93IHRoYXQgd2Ug YXJlIHN0YXJ0aW5nIHRvIGNvbnNpZGVyIGhvdyBpbmRpdmlkdWFsIGNsaWVudCBhcHBsaWNhdGlv bnMgc2hvdWxkIG9wZXJhdGUgd2hlbiB0aGVyZSBpcyBvbmUgb3IgbW9yZSBkZXBsb3ltZW50cyBv ZiBhIHBhcnRpY3VsYXIgcmVzb3VyY2UgQVBJLiBXZSd2ZSBtb3ZlZCBmcm9tIHRoZSBzaW1wbGUg dXNlIGNhc2Ugb2YgYSBzaW5nbGUgQVBJIHByb3ZpZGVyIGxpa2UgRmFjZWJvb2sgb3IgRmxpY2ty IGFuZCBtb3ZlZCBvbiB0byBzdGFuZGFyZHMgYmFzZWQsIG9wZW4gc291cmNlIGJhc2VkLCBhbmQg Y29tbWVyY2lhbCBiYXNlZCBkZXBsb3ltZW50cyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgc2Vy dmljZSBlbmRwb2ludHMgYW5kIG1hbnkgY2xpZW50cyB0byBtYW5hZ2UuDQoNClRoZSBkeW5hbWlj IHJlZ2lzdHJhdGlvbiBzcGVjIGlzIGFjdHVhbGx5IGRlYWxpbmcgd2l0aCBhIGNvdXBsZSBvZiBp c3N1ZXMgdGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIG1hZGUgbW9yZSBjbGVhciBpbiBlYXJseSBw YXJ0IG9mIHRoZSBzcGVjOg0KDQoxLiAgSG93IGlzIGEgbmV3IGNsaWVudCBhcHBsaWNhdGlvbiBy ZWNvZ25pemVkIGZvciB0aGUgZmlyc3QgdGltZSB3aGVuIGRlcGxveWVkIGFnYWluc3QgYSBwYXJ0 aWN1bGFyIFNQIGVuZHBvaW50PyAgU2hvdWxkIGNsaWVudHMgYWN0dWFsbHkgYXNzZXJ0IGFuIGFw cGxpY2F0aW9uX2lkIFVVSUQgdGhhdCBuZXZlciBjaGFuZ2VzIGFuZCBwb3NzaWJseSBhIHZlcnNp b24gaWQgdGhhdCBkb2VzIGNoYW5nZSB3aXRoIHZlcnNpb25zPw0KDQpJbiB0aGUgZ2VuZXJhbCBj YXNlLCB3aHkgaXMgYW55IHJlY29nbml0aW9uIHJlcXVpcmVkPyBJZiB5b3UncmUgZG9pbmcgdGhp bmdzIGFzIHBhcnQgb2YgYSBsYXJnZXIgcHJvdG9jb2wgZWNvc3lzdGVtLCBsaWtlIEJsdWUgQnV0 dG9uKyBvciBhIHBhcnRpY3VsYXIgT3BlbklEIENvbm5lY3QgcHJvdmlkZXIsIHRoZW4geW91IGNh biBkZWZpbmUgc2VtYW50aWNzIGZvciB0eWluZyB0b2dldGhlciBjbGFzc2VzIG9mIGNsaWVudHMg KHNlZSBiZWxvdyBmb3IgbW9yZSBkaXNjdXNzaW9uIG9uIHRoaXMgdmVyeSBwb2ludCkuIEJ1dCBp biBnZW5lcmFsLCBhIGNsaWVudCBpcyBqdXN0IGdvaW5nIHRvIHNob3cgdXAgYXMgYSBuZXcgaW5z dGFuY2UgdG8gdGhlIEFTIGFuZCBnZXQgaXNzdWVkIGEgbmV3LCB1bmlxdWUgY2xpZW50X2lkLCBh bmQgdGhhdCdzIHRoYXQuDQoNCkkgdGhpbmsgd2UgaGF2ZSB0byBkZWZpbmUgbW9yZSBjbGVhcmx5 IHdoYXQgYW4gImluc3RhbmNlIiBpcy4gRm9yIG1lLCB0aGVyZSBhcmUgYXBwbGljYXRpb25zIGFu ZCB0aGVyZSBhcmUgaW5zdGFuY2VzIG9mIHRoYXQgYXBwbGljYXRpb24uICBJdCBpcyB1c2VmdWwg dG8gdW5kZXJzdGFuZCB0aGF0IGEgY2xpZW50IGFwcGxpY2F0aW9uIHJlcHJlc2VudHMgYSBzZXQg b2YgY29kZSB0aGF0IHNob3VsZCBiZWhhdmUgaW4gYSBjb25zaXN0ZW50IHdheS4gIEl0IHNlZW1z IHRvIG1lIHRoZSBmaXJzdCB0aW1lIGEgbmV3IGFwcGxpY2F0aW9uIHNob3dzIHVwIGlzIHZlcnkg ZGlmZmVyZW50IGZyb20gdGhlIHN1YnNlcXVlbnQgaW5zdGFuY2VzIHRoYXQgcmVnaXN0ZXIuIEZv ciBleGFtcGxlLCBhZnRlciB0aGUgZmlyc3QgcmVnaXN0cmF0aW9uLCBzdWJzZXF1ZW50IGluc3Rh bmNlcyBkb24ndCBuZWVkIHNwZWNpYWwgcmV2aWV3IG9yIGFwcHJvdmFsIHRvIHRoZSBzYW1lIGRl Z3JlZS4NCg0KQnV0IHdpdGhvdXQgb3RoZXIgbWVjaGFuaXNtcyB0byB0aWUgdGhpbmdzIHRvZ2V0 aGVyLCB0aGVyZSdzIG5vIHdheSBmb3IgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8ga25vdyBp ZiBhbnkgY2xpZW50IGluc3RhbmNlIGlzIHRpZWQgdG8gYW55IG90aGVyIGNsaWVudCBpbnN0YW5j ZS4gVGhlcmVmb3JlLCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBhbiBBUywgdGhlIGZpcnN0IGlu c3RhbmNlIG9mIGFuIGFwcGxpY2F0aW9uIChpLmUuLCBwYXJ0aWN1bGFyIGNvbmZpZ3VyYXRpb24g b2YgYSBzZXQgb2YgY29kZSkgdG8gcmVnaXN0ZXIgaXMgbm8gZGlmZmVyZW50IHRvIHN1YnNlcXVl bnQgaW5zdGFuY2VzIG9mIHRoYXQgc2FtZSBhcHBsaWNhdGlvbi4gSG93IHdlcmUgeW91IGVudmlz aW9uaW5nIGFuIEFTIGtub3dpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZmlyc3QgYW5k IHN1YnNlcXVlbnQgaW5zdGFuY2VzIG9mIGFuIGFwcGxpY2F0aW9uLCBzcGVjaWZpY2FsbHk/IElm IHRoZXJlJ3MgYW4gImFwcGxpY2F0aW9uX2lkIiBsaWtlIHlvdSBtZW50aW9uIGFib3ZlLCBJIHRo aW5rIGl0IHJhaXNlcyBtb3JlIHF1ZXN0aW9ucyB0aGFuIGl0IHJlc29sdmVzOiBXaG8gaXNzdWVz IHRoZSBhcHBsaWNhdGlvbl9pZCwgc29tZSBzZXJ2ZXIgb3IgdGhlIGFwcGxpY2F0aW9uIGl0c2Vs Zj8gSXMgaXQgdmFsaWRhdGVkIGF0IGFsbD8gU2hvdWxkIGl0IGJlIGNvbnNpZGVyZWQgc2VjcmV0 PyBXaGF0IGhhcHBlbnMgd2hlbiBzb21lb25lIHNpbXBseSBzdGVhbHMgYW4gYXBwbGljYXRpb25f aWQ/IERvZXMgYW4gQVMgaGF2ZSB0byBkbyBhbnl0aGluZyB0byBjaGVjayB3aXRoIGFueSBvdGhl ciBBUyB0byBzZWUgaWYgdGhlIGFwcGxpY2F0aW9uX2lkIGhhcyBhbHJlYWR5IGJlZW4gdXNlZCBl bHNld2hlcmU/DQoNCkkgZG8gYWdyZWUgdGhhdCBhIGRpc2N1c3Npb24gb2YgImluc3RhbmNlIHZz LiBhcHBsaWNhdGlvbiIgd291bGQgYmUgaGVscGZ1bCBpbiBjbGVhcmluZyB0aGlzIHVwLCBJJ2xs IG1ha2UgYSBub3RlIHRvIGFkZCB0ZXh0IHRvIHRoYXQgZWZmZWN0LiAoV2UgaGFkIHRvIGRvIHNv bWV0aGluZyBzaW1pbGFyIGZvciBCQispDQoNCkkgdGhpbmsgaXQgaXMgc2ltcGxlIGVub3VnaCB0 byBhdCBsZWFzdCBhZGQgYSBzZWxmIGdlbmVyYXRlZCBVVUlEIGZvciB0aGUgYXBwbGljYXRpb24g SUQuICBUaG91Z2ggSSB3b3VsZCBhbGxvdyBmb3IgY2FzZXMgd2hlcmUgdGhlIGFwcGxpY2F0aW9u IElEIGlzIGFzc2lnbmVkIHdoZW4gdGhlIGNsaWVudCBkZXZlbG9wZXIgYW5kIHRoZSBBUElzIG93 bmVyIGRvIGEgZm9ybWFsIGFzc2lnbm1lbnQgb2YgYXBwbGljYXRpb24gSURzLg0KDQpJbiBhIHNl bnNlIHRoaXMgaXMganVzdCBhIGxvd2VyIHRlY2ggd2F5IG9mIGRvaW5nIGl0IHRoYW4gd2hhdCB5 b3UgZGVzY3JpYmVkIGFzIHRoZSBpbml0aWFsIGNsaWVudCBjcmVkZW50aWFsIGluIEJsdWUgQnV0 dG9uKyB3aGVyZSB5b3UgZW5jb2RlZCBleHRyYSBjbGFpbXMgaW50byB0aGUgaW5pdGlhbCBhcHAg Y3JlZGVudGlhbC4NCg0KV2hhdCB0aGUgVVVJRCBkb2VzIGlzIGxpbmsgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIGEgY2xpZW50IGFwcCB0b2dldGhlciBhcyB0aGUgc2FtZSAidGhpbmciIHRoYXQgc2hv dWxkIGhhdmUgc2ltaWxhciBoZXVyaXN0aWNzL2JlaGF2aW91cnMuICBUaGlzIGlzIHZlcnkgdXNl ZnVsIGlmIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gcmV2b2tlIGFjY2VzcyB0byBhIHNldCBvZiBj bGllbnRzIGlkZW50aWZpZWQgYnkgYXBwbGljYXRpb24gaWQgKG9yIGEgdmVyc2lvbiBvZiB0aGF0 IGFwcCkuDQoNCldoaWxlIEnigJltIHN5bXBhdGhldGljIHRvIHRoZSBPQXV0aCB3b3JraW5nIGdy b3VwIGV2ZW50dWFsbHkgZG9pbmcgd29yayBvbiBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBpbnN0 YW5jZXMgb2YgYW4gT0F1dGggY2xpZW50LCBJ4oCZbGwgbm90ZSB0aGF0IGluIFJGQyA2NzQ5IG9y IFJGQyA2NzUwIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYSBjbGllbnQgaW5zdGFuY2UuICBU aGVyZSBhcmUgb25seSBjbGllbnRzLCB3aGljaCBhcmUgaWRlbnRpZmllZCBieSBjbGllbnRfaWQg dmFsdWVzLiAgSWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIGNsaWVudCBpbnN0YW5jZXMsIHdlIHNo b3VsZCByZWNoYXJ0ZXIgdG8gYWRkIHRoaXMgbmV3IHdvcmsgYXMgYSB3b3JraW5nIGdyb3VwIGRl bGl2ZXJhYmxlLiAgV2Ugc2hvdWxkIG5vdCB0cnkgdG8gc2hvZWhvcm4gYml0cyBhbmQgcGllY2Vz IG9mIGl0IGludG8gdGhlIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNwZWMsIGFueSBtb3JlIHRoYW4g d2Ugc2hvdWxkIGhhdmUgdHJpZWQgdG8gc2hvZWhvcm4gaXQgaW50byBSRkMgNjc0OSBvciBSRkMg Njc1MC4gIE9hdXRoLWR5bi1yZWcgaXMgdGhlcmUgdG8gcmVnaXN0ZXIgY2xpZW50cyBhcyBkZWZp bmVkIGluIFJGQyA2NzQ5LiAgSXTigJlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8gZXh0ZW5kIHdo YXQgYW4gT0F1dGggY2xpZW50IGlzIGluIG5ldyB3YXlzLg0KDQoyLiAgSG93IGFyZSBjbGllbnQg Y3JlZGVudGlhbHMgbWFuYWdlZC4gQXJlIHdlIGFzc3VtaW5nIGNsaWVudCBjcmVkZW50aWFscyBo YXZlIGEgbGltaXRlZCBsaWZldGltZSBvciByb3RhdGlvbiBwb2xpY3k/DQoNClRoZSBpbnRlbnQg d2FzIHRoYXQgY2xpZW50X3NlY3JldCBjb3VsZCBiZSByb3RhdGVkLCBhcyBpbmRpY2F0ZWQgYnkg dGhlIGV4cGlyZXNfYXQgbWVtYmVyIG9mIHRoZSByZXNwb25zZS4gSWYgYSBjbGllbnQncyBzZWNy ZXQgZXhwaXJlcywgaXQgY2FsbHMgdGhlIHJlYWQgb3BlcmF0aW9uIG9uIHRoZSBDbGllbnQgQ29u ZmlndXJhdGlvbiBFbmRwb2ludCAowqc0LjIpIHRvIGdldCBpdHMgbmV3IGNsaWVudF9zZWNyZXQu IElmIHRoaXMgaXMgdW5jbGVhciBpbiB0aGUgY3VycmVudCB0ZXh0ICh3aGljaCBJIHN1c3BlY3Qg aXQgbWF5IGJlIGFmdGVyIG11bHRpcGxlIHJlZmFjdG9yaW5ncyksIHRoZW4gSSB3ZWxjb21lIHN1 Z2dlc3Rpb25zIGFuZCBzcGVjaWZpYyB0ZXh0IGFzIHRvIGhvdyB0byBtYWtlIHRoYXQgY2xlYXIu DQpTb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuDQoNClNob3VsZCB0 aGlzIGJlIHVwIGluIHRoZSBpbnRyb2R1Y3RvcnkgdGV4dCwgc29tZXdoZXJlIGVsc2UsIG9yIGhh dmUgaXRzIG93biBzZWN0aW9uPw0KDQpJJ20gc3RhcnRpbmcgdG8gdGhpbmsgY3JlZGVudGlhbCBt YW5hZ2VtZW50IGlzIGEga2V5IHBhcnQgb2YgdGhlIGRyYWZ0LiBJdCBtYXkgYmUgd29ydGggaW50 cm9kdWNpbmcgYSBzcGVjaWZpYyBzZWN0aW9uIG91dGxpbmcgdGhlIHJlZ2lzdHJhdGlvbiBsaWZl LWN5Y2xlLCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIHVzYWdlLCBhbmQgY2xpZW50IHRva2Vu IHVzYWdlIGFuZCBib290c3RyYXBwaW5nLg0KDQpJIHRoaW5rIHRoYXQgYWRkaW5nIGEgZGlzY3Vz c2lvbiBvbiB0aGlzIHdvdWxkIGJlIGZpbmUsIGFzIGl0IGNvdWxkIGhlbHAgZGV2ZWxvcGVycyB1 bmRlcnN0YW5kIHRoZSB3b3JrZmxvdyBvZiByZWdpc3RlcmluZywgdXNpbmcsIGFuZCB1cGRhdGlu ZyByZWdpc3RlcmVkIGNsaWVudHMuDQoNCkhvdyBkb2VzIGEgY2xpZW50IGF1dGhlbnRpY2F0ZSB0 aGUgZmlyc3QgdGltZSBhbmQgc3Vic2VxdWVudCB0aW1lcyB0byB0aGUgcmVnaXN0cmF0aW9uIHNl cnZpY2U/DQoNClRoaXMgaXMgYSBzZXBhcmF0ZSBxdWVzdGlvbiBhbGwgdG9nZXRoZXIsIGFzIGl0 IGRvZXMgbm90IGludm9sdmUgdGhlIGNsaWVudF9zZWNyZXQgb3IgY2xpZW50X2lkIGF0IGFsbC4g UmF0aGVyLCB0aGUgZmlyc3QgdGltZSB0aGUgY2xpZW50IHNob3dzIHVwIHRvIHRoZSByZWdpc3Ry YXRpb24gc2VydmljZSwgaXQgbWF5IGVpdGhlcjoNCiAgLSBOb3QgYXV0aGVudGljYXRlIGF0IGFs bCAodGhpcyBpcyB0aGUgdHJ1ZSBwdWJsaWMsIG9wZW4gcmVnaXN0cmF0aW9uLCBhbmQgaXQgaXMg cmVjb21tZW5kZWQgdGhhdCBzZXJ2ZXJzIGRvIHRoaXMpDQogLSBBdXRoZW50aWNhdGUgdXNpbmcg YW4gT0F1dGggMi4wIHRva2VuICh3aGljaCBBVE0gbWVhbnMgYSBiZWFyZXIgdG9rZW4pLiBIb3cg dGhlIGNsaWVudCBnZXRzIHRoYXQgYmVhcmVyIHRva2VuIGFuZCB3aGF0IHRoZSBiZWFyZXIgdG9r ZW4gbWVhbnMgdG8gdGhlIEFTIGJleW9uZCAidGhpcyBjbGllbnQgaXMgYXV0aG9yaXplZCB0byBy ZWdpc3RlciIgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgc3BlYywgYnkgZGVzaWduLg0KDQpTdWJz ZXF1ZW50IHRpbWVzIHRoYXQgdGhlIHNhbWUgcmVnaXN0ZXJlZCBjbGllbnQgKGJ5IHdoaWNoIHdl IG1lYW4gdGhlIHNhbWUgaW5zdGFuY2Ugb2YgYSBjbGllbnQgd2l0aCBhIHBhcnRpY3VsYXIgY2xp ZW50X2lkKSBzaG93cyB1cCBhdCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IChhY3R1YWxseSwg dGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50KSwgaXQgdXNlcyBpdHMgUmVnaXN0cmF0 aW9uIEFjY2VzcyBUb2tlbiB0aGF0IGl0IHdhcyBpc3N1ZWQgb24gaW5pdGlhbCByZWdpc3RyYXRp b24uIFRoaXMgaXMgYW4gT0F1dGggMi4wIEJlYXJlciB0b2tlbiB0aGF0IGlzIHVuaXF1ZSB0byB0 aGUgY2xpZW50IGluc3RhbmNlLg0KDQpTb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0 aGUgZHJhZnQuDQoNCk9LLCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiBjYW4gYmUgZXhwYW5kZWQsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIHJlc3Qgb2YgaXQg aXMgYWxyZWFkeSBpbiB0aGVyZSBpbiDCpzMuIEknZCB3ZWxjb21lIHN1Z2dlc3Rpb25zIG9uIHdo aWNoIGJpdHMgb2YgdGhpcyBjb3VsZCBiZSBtYWRlIGNsZWFyZXIuDQoNClNlZSB0aGUgZGlzY3Vz c2lvbiBvbiB3aGF0IHRoZSByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGlzIGluIHRoZSB0aHJl YWQg4oCcQ2xpZW50IENyZWRlbnRpYWwgRXhwaXJ5IGFuZCBuZXcgUmVnaXN0cmF0aW9uIEFjY2Vz cyBUb2tlbiAtIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMOKAnS4gIEkgd2lsbCB3b3JrIHdp dGggSnVzdGluIHRvIGFwcGx5IHRoZXNlIGNsYXJpZmljYXRpb25zIHRvIHRoZSBzcGVjaWZpY2F0 aW9uLiAgVGhpcyBtYXkgZ28gaW50byB0aGUgcHJvcG9zZWQgY3JlZGVudGlhbCBtYW5hZ2VtZW50 IG92ZXJ2aWV3IHNlY3Rpb24gZGlzY3Vzc2VkIGFib3ZlLg0KDQozLiAgSG93IGlzIHZlcnNpb25p bmcgb2YgY2xpZW50cyBtYW5hZ2VkPyBTaG91bGQgZWFjaCBuZXcgdmVyc2lvbiBvZiBhIGNsaWVu dCByZXF1aXJlIGEgY2hhbmdlIGluIGNsaWVudCByZWdpc3RyYXRpb24gaW5jbHVkaW5nIHBvc3Np Ymx5IGNoYW5naW5nIGNsaWVudF9pZCBhbmQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbD8gSSBk b24ndCBoYXZlIGEgc3Ryb25nIGZlZWxpbmcsIGJ1dCBpdCBpcyBzb21ldGhpbmcgdGhhdCBpbXBs ZW1lbnRvcnMgc2hvdWxkIGNvbnNpZGVyLg0KDQpUaGlzIGlzIHVwIHRvIHRoZSBBUywgcmVhbGx5 LCBhbmQgSSBkb24ndCB0aGluayB0aGF0IGFueSBnbG9iYWwgcG9saWN5IHdvdWxkIGV2ZXIgZmx5 IGhlcmUuIEVzcGVjaWFsbHkgaWYgeW91IGNvbnNpZGVyIHRoYXQgdGhlIGVudGlyZSBub3Rpb24g b2YgInZlcnNpb24iIGlzIG1vcmUgZmx1aWQgdGhlc2UgZGF5cyB0aGFuIGl0IGV2ZXIgaGFzIGJl ZW4uIEkgd291bGRuJ3QgbWluZCBhZGRpbmcgYSBkaXNjdXNzaW9uIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBpZiBpdCBtZXJpdHMgbWVudGlvbmluZyB0aG91Z2gsIHNvIHRoYXQgd2Ug Y2FuIGhlbHAgYm90aCBjbGllbnQgZGV2ZWxvcGVycyBhbmQgc2VydmVyIGRldmVsb3BlcnMgaW5z dGl0dXRlIHJlYXNvbmFibHkgZ29vZCBwb2xpY3kuDQoNCkkgZ3Vlc3MgdGhlIGlzc3VlIGlzIHRo YXQgd2hlbiBhIGNsaWVudCB1cGdyYWRlcyBpdCBtYXkgaGF2ZSBhY2Nlc3MgdG8gdGhlIG9sZCBj cmVkZW50aWFscy4gV2hhdCBpcyB0aGUgaW50ZW50IHRoZW4gb2YgcmVnaXN0cmF0aW9uLiAgU2lu Y2UgeW91IGhhdmUgYW4gdXBkYXRlIGFyZSBjbGllbnRzIGV4cGVjdGVkIHRvIHVwZGF0ZSAvcmUt cmVnaXN0ZXIgb3Igbm90PyAgSSdtIG5vdCBzdXJlIHRoaXMgaXMgYSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIGJ1dCBtb3JlIHBhcnQgb2YgdGhlIHdob2xlIGNoYW5nZSBtYW5hZ2VtZW50IGZ1bmN0 aW9uIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHN1cHBvcnRzLg0KDQpJZiB5b3VyIHVwZ3JhZGVkIHZl cnNpb24gb2YgdGhlIGNsaWVudCBzdGlsbCBoYXMgYWNjZXNzIHRvIGl0cyBvbGQgY3JlZGVudGlh bHMsIHdoeSB3b3VsZG4ndCBpdCBqdXN0IHVzZSB0aG9zZT8gSSBkb24ndCBzZWUgYSByZWFzb24g Zm9yIGZvcmNpbmcgYSByZS1yZWdpc3RyYXRpb24uIE5vciBkbyBJIHNlZSBhbnkgd2F5IHRoYXQg YW4gQVMgd291bGQgZXZlbiBiZSBhYmxlIHRvIHRlbGwgdGhhdCBhIGNsaWVudCBoYWQgYmVlbiB1 cGdyYWRlZC4gQW4gdXBncmFkZWQgY2xpZW50IGFsd2F5cyBoYXMgdGhlICpvcHRpb24qIG9mIHJl LXJlZ2lzdGVyaW5nIGl0c2VsZiBhbmQgZ2V0dGluZyBhIG5ldyBjbGllbnRfaWQuDQpJIHRoaW5r IHRoZSBjb25jZXJuIGhlcmUgaXMgdGhhdCByb3RhdGlvbiBvZiBjbGllbnQgY3JlZGVudGlhbCBp cyBub3Qgc29tZXRoaW5nIGRpc2N1c3NlZCBiZWZvcmUuIEJlZm9yZSB3ZSBwdXQgaXQgaW4gdGhl IHNwZWMgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSByZWFzb25zIGZvciBkb2luZyBpdCBhbmQgd2hh dCBwcm9ibGVtcyBpdCBzb2x2ZXMuDQoNCkkgdGhpbmsgdGhpcyBtYXkgYmUganVzdCBhIGNhc2Ug b2YgbGV0dGluZyBwZW9wbGUgZXhjaGFuZ2UgY3JlZGVudGlhbHMgZm9yIHdoYXRldmVyIHJlYXNv biB0aGV5IGZlZWwgaXMgYXBwcm9wcmlhdGUuICBUaGUgdmVyc2lvbiB1cGdyYWRlIHRoaW5nIHN1 Z2dlc3RzIHRoYXQgd2hlbiBhIGNsaWVudCBpcyB1cGdyYWRlZCBpdCBzaG91bGQgZ28gdG8gdGhl IHJlZ2lzdHJhdGlvbiBzZXJ2ZXIgdG8gInJlLXJlZ2lzdGVyIi4gIERlcGVuZGluZyBvbiB0aGUg cG9saWN5IG9mIHRoZSBzZXJ2ZXIsIGl0IG1heSAob3IgbWF5IG5vdCkgcmVjZWl2ZSBhIG5ldyBj bGllbnRfaWQgYW5kL29yIG5ldyBjcmVkZW50aWFsLg0KDQpPbmUgb2YgdGhlIGJlc3QgYmVuZWZp dHMgSSBjYW4gdGhpbmsgb2YgaXMgaWYgeW91IGRpc2NvdmVyIGEgdmVyc2lvbiBvZiBhIGNsaWVu dCBoYXMgYSBwcm9ibGVtLCBiZWluZyBhYmxlIHRvIHNlbGVjdCBhIGdyb3VwIG9mIGNsaWVudHMg Ynkgc29mdHdhcmUgYW5kIHZlcnNpb24gaXMgaW1wb3J0YW50LiBUaHVzIGlmIGNsaWVudF9pZCBk b2Vzbid0IHRyYWNlIHRvIGEgcGFydGljdWxhciBzb2Z0d2FyZSBhbmQgdmVyc2lvbiwgdGhhdCBt YWtlcyBpdCBoYXJkIHRvIGRvLiAgSSAgdGhpbmsgeW91IHRhbGtlZCBhYm91dCB0aGlzIGFzIGFu IGlzc3VlIGZvciBCbHVlIEJ1dHRvbisNCg0KQWdhaW4sIFJGQyA2NzQ5IGRlZmluZXMgbm8gY2xp ZW50IGluc3RhbmNlcyBvciBncm91cHMgb2YgY2xpZW50cywgdGhlcmVmb3JlIEkgYmVsaWV2ZSB0 aGF0IGl04oCZcyBpbmFwcHJvcHJpYXRlIHRvIGRvIHNvIGhlcmUuICBXZSBkb27igJl0IG5lZWQg dG8gYm9pbCB0aGUgb2NlYW4uICBJZiBhIG5ldyBjaGFydGVyIGl0ZW0gaXMgYXBwcm92ZWQgdG8g ZG8gd29yayBvbiBjbGllbnQgaW5zdGFuY2VzIGFuZCBwcm90b2NvbCBlbGVtZW50cyB0byB1c2Ug YW5kIGV4cHJlc3MgdGhlbSwgdGhhdOKAmXMgdGhlIHRpbWUgZm9yIHRoZSB3b3JraW5nIGdyb3Vw IHRvIGNvbnNpZGVyIHRoYXQgcG9zc2liaWxpdHkg4oCTIG5vdCBhcyBwYXJ0IG9mIER5bmFtaWMg Q2xpZW50IFJlZ2lzdHJhdGlvbi4NCg0KNC4gIFdoYXQgaXMgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nl c3MgdG9rZW4/IFdoeSBpcyBpcyB1c2VkPyBXaGF0IGlzIGl0cyBsaWZlLWN5Y2xlPyAgV2hlbiBp cyBpdCBpc3N1ZWQsIHdoZW4gaXMgaXQgY2hhbmdlZD8gV2hlbiBpcyBpdCBkZWxldGVkPw0KDQpT ZWUgdGhlIHJlc3BvbnNlIGFib3ZlIGFib3ZlIGFuZCB0aGUgZGVmaW5pdGlvbiBpbiDCpzEuMjoN Cg0KUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjogQW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBp c3N1ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRocm91Z2ggdGhlIENsaWVudCBSZWdp c3RyYXRpb24gRW5kcG9pbnQgd2hpY2ggaXMgdXNlZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRp Y2F0ZSBpdHNlbGYgZHVyaW5nIHJlYWQsIHVwZGF0ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiBU aGlzIHRva2VuIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgQ2xpZW50Lg0KDQpJZiB0 aGlzIGNhbiBiZSBjbGFyaWZpZWQsIEkgd2VsY29tZSB0ZXh0IHN1Z2dlc3Rpb25zLg0KDQpUaGUg bGF0dGVyIHBhcnQgb2YgMS4yIGRpZG4ndCBzZWVtIGxpa2UgdGVybWlub2xvZ3kgYnV0IHJhdGhl ciBhcmNoaXRlY3R1cmUgb3IgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRoYXQgZGVzY3JpYmVz IHdoYXQgdGhlIHNwZWMgZG9lcy4gVGhlIHRoaXJkIHBvaW50IGRvZXNuJ3Qgc2VlbSB0byBmaXQg d2l0aCB0aGUgb3RoZXIgdHdvIGV4Y2VwdCB0byBzYXkgdGhhdCB0aGUgZHluYW1pYyByZWdpc3Ry YXRpb24gZW5kcG9pbnRzIHVzZSB0aGVpciBvd24gYWNjZXNzIHRva2VucyBjYWxsZWQgcmVnaXN0 cmF0aW9uIGFjY2VzcyB0b2tlbnMuDQoNCg0KQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludDog VGhlIE9BdXRoIDIuMCBFbmRwb2ludCB0aHJvdWdoIHdoaWNoDQoNCiAgICAgIGEgQ2xpZW50IGNh biByZXF1ZXN0IG5ldyByZWdpc3RyYXRpb24uICBUaGUgbWVhbnMgb2YgdGhlIENsaWVudA0KDQog ICAgICBvYnRhaW5pbmcgdGhlIFVSTCBmb3IgdGhpcyBlbmRwb2ludCBhcmUgb3V0IG9mIHNjb3Bl IGZvciB0aGlzDQoNCiAgICAgIHNwZWNpZmljYXRpb24uDQoNCg0KDQogICBvICBDbGllbnQgQ29u ZmlndXJhdGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIuMCBFbmRwb2ludCB0aHJvdWdoDQoNCiAg ICAgIHdoaWNoIGEgc3BlY2lmaWMgQ2xpZW50IGNhbiBtYW5hZ2UgaXRzIHJlZ2lzdHJhdGlvbiBp bmZvcm1hdGlvbiwNCg0KICAgICAgcHJvdmlkZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVy IHRvIHRoZSBDbGllbnQuICBUaGlzIFVSTCBmb3INCg0KICAgICAgdGhpcyBlbmRwb2ludCBpcyBj b21tdW5pY2F0ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbg0KDQogICAgICBT ZXJ2ZXIgaW4gdGhlIENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25zZS4NCg0KDQoNCiAgIG8gIFJl Z2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVk IGJ5IHRoZQ0KDQogICAgICBBdXRob3JpemF0aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGllbnQg UmVnaXN0cmF0aW9uIEVuZHBvaW50DQoNCiAgICAgIHdoaWNoIGlzIHVzZWQgYnkgdGhlIENsaWVu dCB0byBhdXRoZW50aWNhdGUgaXRzZWxmIGR1cmluZyByZWFkLA0KDQogICAgICB1cGRhdGUsIGFu ZCBkZWxldGUgb3BlcmF0aW9ucy4gIFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoIGENCg0K ICAgICAgcGFydGljdWxhciBDbGllbnQuDQoNClRoaXMgc2VjdGlvbiBpcyBtZWFudCB0byBqdXN0 IGludHJvZHVjZSB0aGUgbmV3IHRlcm1zIHRoYXQgYXJlIHRoZW4gZXhwbGFpbmVkIGluIGdyZWF0 ZXIgZGV0YWlsIHRocm91Z2hvdXQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBZZXMsIGl0J3Mg YSBiaXQgYXJjaGl0ZWN0dXJlLCBidXQgb25seSBpbiB0aGUgc2Vuc2UgdGhhdCB5b3UgbmVlZCB0 byBkZWZpbmUgdGhlIHRlcm1zIHRoYXQgbWFrZSB1cCB5b3VyIGFyY2hpdGVjdHVyZS4gSG93IHdv dWxkIHlvdSBzdWdnZXN0IHRoYXQgaXQgY2hhbmdlPw0KDQpQcm9iYWJseSB0aGlzIGlzIG1vcmUg YSBtYXR0ZXIgb2Ygc3R5bGUuICBCdXQsIHdoYXQgaGFwcGVuZWQgZm9yIG1lIGlzIEkgbmF0dXJh bGx5IHNraXBwZWQgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24sIGFzIEkgd2Fzbid0IGV4cGVjdGlu ZyBwcm90b2NvbCBjb21wb25lbnRzIHRvIGJlIHRoZXJlLiAgInRlcm1pbm9sb2d5IiBpcyBzb21l dGhpbmcgSSB0aGluayBwZW9wbGUgdGVuZCB0byB1c2UgYXMgYSBkaWN0aW9uYXJ5IHJhdGhlciB0 aGFuIGFzIHByb3RvY29sIGNvbXBvbmVudCBkZXNjcmlwdGlvbi4gIE1heWJlIHRoZSBjaGFpcnMg Y2FuIGFkdmlzZT8NCg0KSWYgd2UgZGlzdGluZ3Vpc2ggYmV0d2VlbiBmaXJzdCB0aW1lIHJlZ2lz dHJhdGlvbiBvZiBhIHBhcnRpY3VsYXIgY2xpZW50IHNvZnR3YXJlIHBhY2thZ2UsIGl0IGlzIHBv c3NpYmxlIHRoYXQgc29tZXRoaW5ncyBsaWtlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUg bmVnb3RpYXRlIGluIG9yIG91dC1vZi1iYW5kIGF0IHRoYXQgdGltZS4gU3Vic2VxdWVudCByZWdp c3RyYXRpb25zIHNob3VsZCBvbmx5IGhhdmUgcGFyYW1ldGVycyBmb3IgaXRlbXMgdGhhdCBjb3Vs ZCBjaGFuZ2UgcGVyIGRlcGxveW1lbnQgKGxpa2UgdG9zX3VyaSkuICBJIHRoaW5rIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kIGlzIG9uZSB0aGluZyB0aGF0IHNob3VsZCBub3QgYmUgbmVnb3Rp YXRlZCBwZXIgaW5zdGFuY2UuDQoNCldoZW4gc3Vic2VxdWVudCBpbnN0YW5jZXMgcmVnaXN0ZXIs IEkgaGF2ZSB0byBhc2sgdGhlIHF1ZXN0aW9uLCBmb3IgZXhhbXBsZSB3aGVuIHdvdWxkIHRoaW5n cyBsaWtlICJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCIgYmUgbmVnb3RpYXRlZCBvciBiZSBk aWZmZXJlbnQgZm9yIHRoZSBzYW1lIGNsaWVudCBzb2Z0d2FyZT8gU2hvdWxkIG5vdCBhbGwgaW5z dGFuY2VzIHVzZSB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkknbSBjb25mdXNl ZCBieSB0aGlzIC0tIGFzIGZhciBhcyB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBpcyBj b25jZXJuZWQsIGFsbCBpbnN0YW5jZXMgYXJlIHNlcGFyYXRlIGZyb20gZWFjaCBvdGhlci4gQWxs IHBhcmFtZXRlcnMgY2hhbmdlIHBlciBpbnN0YW5jZS4gQW5kIGluc3RhbmNlLCB5b3Ugc2hvdWxk IGtlZXAgaW4gbWluZCwgaXMgZGVmaW5lZCBhcyBhbnkgb25lIGNvcHkgb2YgdGhlIGNsaWVudCBj b2RlIGNvbm5lY3RpbmcgdG8gYW55IG5ldyBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhhdCBwYWly aW5nIGNyZWF0ZXMgdGhlIGNsaWVudF9pZCwgYW5kIHRoZXJlZm9yZSB0aGUgaW5zdGFuY2UsIGFu ZCB0aGVyZWZvcmUgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4sIGFuZCB0aGVyZWZvcmUg dGhlIHJlZ2lzdHJhdGlvbiBpdHNlbGYgYXQgYSBjb25jZXB0dWFsIGxldmVsLiBTbyB0aGVyZSBp cyBubyB3YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9yIGEgY2xpZW50IHRvIGFzayBmb3Ig YSBwYXJ0aWN1bGFyIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kLiBXaGVyZSBlbHNlIHdvdWxk IHRoZSBBUyBmaW5kIG91dCBhYm91dCBpdD8NCg0KV2Ugc3RpbGwgZGlzYWdyZWUgb24gdGhpcy4g SXQgaXMgbXkgYXNzZXJ0aW9uIHRoYXQgY2xpZW50cyBzaG91bGQgTkVWRVIgYXNrIGZvciBhIHBh cnRpY3VsYXIgdG9rZW4gYXV0aCBtZXRob2QuIFNpbmNlIGl0IGlzIHRoZSBBUyB0aGF0IGlzIGF1 dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQsIHRoZW4gaXQgaXMgdGhlIEFTJ3MgcmlnaHQgdG8gc2V0 IHRoZSBhdXRoZW50aWNhdGlvbiBwb2xpY3kuICBUaGUgcm9sZSBvZiBkeW5hbWljIHJlZyBlbmRw b2ludCBpcyB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgZG8uICBNeSBhc3N1bXB0 aW9uIGlzIHRoYXQgZHVyaW5nIHRoZSBmaXJzdCB0aW1lIGEgcGllY2Ugb2Ygc29mdHdhcmUgaXMg cmVnaXN0ZXJlZCAodGhlIGZpcnN0IGluc3RhbmNlKSwgdGhlcmUgY291bGQgYmUgc29tZSBPT0Ig ZGlzY3Vzc2lvbiBieSBhbiBhZG1pbmlzdHJhdG9yIHRvIGFwcHJvdmUgdGhlIHBhcnRpY3VsYXIg YXV0aGVudGljYXRpb24gdHlwZSBmb3IgdGhlIEFTIGluIHF1ZXN0aW9uLg0KDQpJIGhhdmVuJ3Qg aGVhcmQgYSByZWFzb24ganVzdGlmeWluZyB0aGlzIHBhcmFtZXRlciBvdGhlciB0aGVuICJpdCBp cyBuZWVkZWQiLiAgV2h5Pw0KDQpUaGUgcm9sZSBvZiB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24g cHJvdG9jb2wgaXMgdHdvZm9sZDogaGFsZiBvZiB0aGF0IGlzIHRoZSBzZXJ2ZXIgaW5mb3JtaW5n IHRoZSBjbGllbnQgd2hhdCBpdCBtdXN0IGRvLiBCdXQgdGhlIG90aGVyIGhhbGYgaXMgdGhlIGNs aWVudCBpbmZvcm1pbmcgdGhlIHNlcnZlciB3aGF0IGl0ICpjYW4qIGRvLCBvciB3aGF0IGl0ICp3 YW50cyogdG8gZG8uDQoNCkFuZCBhZ2FpbiwgdGhlcmUncyBubyB3YXkgdG8gZGlzdGluZ3Vpc2gg YSBmaXJzdCBpbnN0YW5jZSBmcm9tIGEgc3Vic2VxdWVudCBpbnN0YW5jZSB1bmxlc3MgeW91J3Jl IGRvaW5nIHNvbWV0aGluZyBpbiBhZGRpdGlvbi4gTm90aGluZyBpcyBzdG9wcGluZyB0aGUgc2Ft ZSBhcHBsaWNhdGlvbiBmcm9tIHJlZ2lzdGVyaW5nIGEgbmV3IGluc3RhbmNlIG9mIGl0c2VsZiBm b3IgZXZlcnkgc2luZ2xlIHVzZXIgb3IgZXZlcnkgc2luZ2xlIHRva2VuIHRoYXQgaXQgd2FudHMg dG8gZ2V0IGFjY2VzcyBmb3IuIFRoYXQncyBjb21wbGljYXRlZCBhbmQgd2FzdGVmdWwgYW5kIG5v dCBhIGdyZWF0IGlkZWEsIHN1cmUsIGJ1dCAgdGhlcmUncyBubyB1c2VmdWwgd2F5IHRvIHByZXZl bnQgdGhhdCBraW5kIG9mIGJlaGF2aW9yIGlmIHlvdSBhbHNvIHdhbnQgb3BlbiByZWdpc3RyYXRp b24gb2YgY2xpZW50cy4NCg0KSSB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgaG93IHJlY29nbml6aW5n IHN1YnNlcXVlbnQgaW5zdGFuY2VzIGlzIGVhc2lseSBkb25lLg0KDQpBcyBJIG1lbnRpb25lZCBp biB0aGUgb3RoZXIgdGhyZWFkLCBpZiBhIGRldmVsb3BlciBjaG9vc2VzIHRvIGxpbWl0IHRoZSBj YXBhYmlsaXRpZXMgb2YgdGhlIGNsaWVudCBpdCBtdXN0IGRvIHNvIGJ5IGxvb2tpbmcgdG8gdGhl IGRldmVsb3BlciBvciBzdGFuZGFyZCBiZWhpbmQgdGhlIEFQSS4gIE90aGVyd2lzZSB0aGV5IGFy ZSB0YWtpbmcgdGhlIGNoYW5jZS4gIFRoZXJlJ3Mgbm8gd2F5IGEgZGV2ZWxvcGVyIGNhbiBxdWVy eSBhbGwgdGhlIHBvdGVudGlhbCBkZXBsb3llcnMgdG8gYXNrIHdoYXQgYXV0aG4gdHlwZXMgd2ls bCB5b3UgdXNlLiBBcyBJIHNhaWQsIHRoZSBuZXQgZWZmZWN0IGluIHRoZSBhYnNlbmNlIG9mIGFu IEFQSSBzdGFuZGFyZCBkaWN0YXRpbmcgd2hhdCBzaG91bGQgYmUgc3VwcG9ydGVkLCB0aGUgZGV2 ZWxvcGVyIHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgYWxsIG1ldGhvZHMuDQoNCk15IHBvaW50IGhl cmUgaXMgdGhhdCBub25lIG9mIHRoaXMgaXMgaGVscGVkIGJ5IHRoZSBjbGllbnQgYXBwIHNheWlu ZyB3aGF0IGl0IHN1cHBvcnRzLiBBIGRldmVsb3BlciB3aG8gdGFrZXMgdGhlIHJvdXRlIG9mIGxp bWl0aW5nIGltcGxlbWVudGF0aW9uIHRha2VzIHRoZSBjaGFuY2UgdGhhdCB0aGUgc2VydmVyIHdp bGwgbm90IGFjY2VwdC4gIFNvIHdoeSBuZWdvdGlhdGUgd2l0aGluIHJlZ2lzdHJhdGlvbj8NCg0K QW5kIHRoZXJlJ3Mgbm8gd2F5IG90aGVyIHRoYW4gcGVyLWluc3RhbmNlIGZvciB0aGUgc2VydmVy IHRvIHRlbGwgdGhlIGNsaWVudCB3aGljaCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCB0byB1 c2UuIEFsbCBpbnN0YW5jZXMgd2lsbCBwcm9iYWJseSBhc2sgZm9yIHRoZSBzYW1lIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kIGZyb20gYWxsIGF1dGggc2VydmVycyB0aGV5IHRhbGsgdG8sIHJp Z2h0PyBBbmQgZWFjaCBBUyB3aWxsIHRlbGwgZWFjaCBpbnN0YW5jZSB0aGF0IHJlZ2lzdGVycyB3 aXRoIGl0IHRvIHVzZSBhIHBhcnRpY3VsYXIgYXV0aCBtZXRob2QuIFRoZXJlIGlzIG5vIHdheSB0 byB0aWUgdG9nZXRoZXIgZGlmZmVyZW50IGluc3RhbmNlcyBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0 aCBzZXJ2ZXJzIHdpdGhvdXQgc3BlY2lmeWluZyBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBvdGhl ciBtYWNoaW5lcnkuDQoNCldoaWNoIGlzIG5vdCB0byBzYXkgdGhhdCBpdCdzIG5vdCB1c2VmdWwg aW4gc29tZSBjaXJjdW1zdGFuY2VzIHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2Vz IG9mIHRoZSBzYW1lIGNvZGUgYWNyb3NzIChvciB3aXRoaW4pIGF1dGggc2VydmVycy4gVGhpcyBp cyB3aHksIHdpdGggQmx1ZSBCdXR0b24rLCB3ZSBzcGVjaWZpZWQgYSBzcGVjaWZpYyB0b2tlbiBm b3JtYXQgZm9yIHRoZSBpbml0aWFsIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBjbGllbnRzIHVzZSB0 byBjYWxsIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgdGhlIGZpcnN0IHRpbWUsICBhcyB3ZWxs IGFzIGEgZGlzY292ZXJ5IHByb3RvY29sIGFnYWluc3QgYSBjZW50cmFsaXplZCBzZXJ2ZXIgdGhh dCBoYW5kbGVzIHByZS1yZWdpc3RyYXRpb24uIEFsbCBvZiB0aGlzIG1hY2hpbmVyeSBpcywgaW4g bXkgb3BpbmlvbiwgYSBzdHVwZW5kb3VzIG92ZXJraWxsIGZvciB0aGUgZ2VuZXJhbCBjYXNlLCB0 aG91Z2ggaWYgc29tZSBmb2xrcyBmaW5kIHVzZSBmb3IgaXQgb3V0c2lkZSBvZiBCQisgdGhlbiBp dCdkIGJlIGEgZ29vZCB0aGluZyB0byBhYnN0cmFjdCBvdXQgYW5kIG1ha2UgaXRzIG93biBzcGVj IHRoYXQgZXh0ZW5kcyB0aGUgRHluIFJlZyBzcGVjIGluIGEgZnVsbHkgY29tcGF0aWJsZSB3YXku IEZ1cnRoZXJtb3JlLCBldmVuIGluIEJsdWUgQnV0dG9uKyB3ZSBzcGVjaWZ5IHRoYXQgYWxsIGF1 dGggc2VydmVycyBNVVNUIGFsc28gYWNjZXB0IG9wZW4gcmVnaXN0cmF0aW9uLCB3aXRob3V0IGFu IGluaXRpYWwgYWNjZXNzIHRva2VuLCB3aGVyZSB0aGUgY2xpZW50IHNpbXBseSBzaG93cyB1cCBh bmQgc2F5cyAiaGV5LCBoZXJlIGFyZSBteSBwYXJhbWV0ZXJzLiIgVGhlIGF1dGggc2VydmVyIGhh cyBubyB3YXkgdG8ga25vdyBpbiB0aGlzIGNhc2UgYW55IGtpbmQgb2Ygb3V0LW9mLWJhbmQgbmVn b3RpYXRpb24gZm9yIGRpZmZlcmVudCB0aGluZ3MuIEluIEJCKyB3ZSBhcmUgd3JpdGluZyB2ZXJ5 IHNwZWNpZmljIHBvbGljeSBndWlkZWxpbmVzIGFib3V0IGhvdyB0byBwcmVzZW50IHRoZSBVWCBh bmQgdGhpbmdzIHRvIHRoZSBlbmQgdXNlciBmb3IgYWxsIG9mIHRoZXNlIGRpZmZlcmVudCBjYXNl cy4gQnV0IGFnYWluLCBhbGwgb2YgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUgQkIrIHVzZSBjYXNl LCBhbmQgSSBkb24ndCBzZWUgdmFsdWUgaW4gZHJhZ2dpbmcgaXQgaW4gdG8gdGhlIHJlZ2lzdHJh dGlvbiBzcGVjIG9uIGl0cyBvd24uIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBmYXIgdG9vIGxpbWl0 aW5nLg0KDQpTZWUgbXkgcHJldmlvdXMgY29tbWVudHMgb24gZGlmZmVyZW50aWF0aW5nIGNsaWVu dCBpbnN0YW5jZXMgYmVpbmcgb3V0IG9mIHNjb3BlIHdpdGhvdXQgcmVjaGFydGVyaW5nIHRvIGRv IHRoaXMgbmV3IHdvcmsgYW5kIG9uIHdoYXQgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4g aXMuICBJbiBzaG9ydCwgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMgYW4gUkZDIDY3 NTAgYmVhcmVyIHRva2VuIGlzc3VlZCB0byB0aGUgcGFydHkgcmVnaXN0ZXJpbmcgdGhlIGNsaWVu dCwgZW5hYmxpbmcgaXQgdG8gc3Vic2VxdWVudGx5IHJldHJpZXZlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCB0byBwb3RlbnRpYWxseSB1cGRhdGUgdGhlIHJl Z2lzdHJhdGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhhdCByZWdpc3RlcmVkIGNsaWVudC4gIEFnYWlu LCBJ4oCZbGwgd29yayB3aXRoIEp1c3RpbiB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIGlzIGFzIGNs ZWFyIGFzIHBvc3NpYmxlIGluIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQpGaW5hbGx5LCB0aGVyZSBz ZWVtcyB0byBiZSBhbiBpbmNvbnNpc3RlbnQgc3R5bGUgYXBwcm9hY2ggd2l0aCBkcmFmdC1oYXJk am9uby1vYXV0aC1yZXNvdXJjZS1yZWc8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhh cmRqb25vLW9hdXRoLXJlc291cmNlLXJlZy0wMC50eHQ+IHdoaWNoIHVzZXMgRVRhZ3MuIFNob3Vs ZCB0aGlzIGRyYWZ0IGRvIHNvIGFzIHdlbGw/DQoNClRoYXQncyBhbiBpbmRpdmlkdWFsIHN1Ym1p c3Npb24sIG5vdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIE5vYm9keSBoYXMsIHVudGlsIG5vdywg ZXZlbiBtZW50aW9uZWQgdGhlIHVzZSBvZiBFVGFncyBoZXJlLiBVTUEgKHdoZXJlIHRoZSByZXNv dXJjZSByZWdpc3RyYXRpb24gZHJhZnQgY29tZXMgZnJvbSkgdXNlcyBFVGFncywgaGVuY2UgdGhl aXIgaW5jbHVzaW9uIHRoZXJlLiBJIHBlcnNvbmFsbHkgZG9uJ3Qgc2VlIHRoZWlyIHV0aWxpdHkg aGVyZSwgdGhvdWdoLCBhbmQgSSB3b3VsZG4ndCB3YW50IHRvIGluY2x1ZGUgYSB3aG9sbHkgbmV3 IG1lY2hhbmlzbSB0aGlzIGxhdGUuDQoNClllcy4gVGhvbWFzJyBkcmFmdCBpcyBub3QgYSBXRyBk b2N1bWVudC4gQnV0IHRoYXQgZG9lc24ndCBtZWFuIGhlIGRvZXNuJ3QgaGF2ZSBhIHBvaW50LiBJ dCdzIHdvcnRoIGRpc2N1c3NpbmcuDQoNCk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHRoZSBwb2ludCBv ZiBhbiBFVGFnIGlzIHRoYXQgaXQgaXMgdXNlZnVsIGZvciBjaGFuZ2UgZGV0ZWN0aW9uIHdoZW4g dGhlcmUgYXJlIG11bHRpcGxlIHdyaXRlcnMgdG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlLiAgSW4g dGhlIGRlc2lnbiBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCwgdGhlcmUgc2hvdWxk IG9ubHkgYmUgb25lIHdyaXRlciAtLSB0aGUgY2xpZW50LiBUaGlzIGlzIGFuIGltcG9ydGFudCBv YnNlcnZhdGlvbi4NCg0KVGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdGhhdCBoYW5kbGUgdGhp cyAtLSBuYW1lbHksIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGFuZCB0aGUgY2xpZW50 X2lkLiBNYW55IGluc3RhbmNlcyBpbmNsdWRlIHRoZSBjbGllbnRfaWQgaW4gc29tZSBmb3JtIGlu IHRoZSBjbGllbnQgY29uZmlndXJhdGlvbiBlbmRwb2ludCdzIFVSTCBmb3Igc2FuaXR5IGNoZWNr aW5nLCBhcyBkZXNjcmliZWQgaW4gwqc0LjEuDQoNCklmIGV2ZXJ5b25lIGFncmVlcywgSSdtIGlu IGFncmVlbWVudC4gQnV0IGl0IHdpbGwgbGlrZWx5IG1lYW4gY2hhbmdlcyBmb3IgdGhlIHJlc291 cmNlIHJlZyBkcmFmdCBpZiBhZG9wdGVkLg0KDQpFVGFncyBzZWVtIGxpa2UgYW4gdW5uZWNlc3Nh cnkgYWRkaXRpb24gKGFuZCBwb3RlbnRpYWwgY29tcGxpY2F0aW9uKSB0byB0aGUgc3BlY2lmaWNh dGlvbi4gIEl04oCZcyBhbHJlYWR5IHdvcmtpbmcgZmluZSBhcy1pcy4NCg0KU3BlY2lmaWMgaXRl bXM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCIN Cg0KVGhlcmUgaXMgc29tZSBjb25mdXNpb24gYXMgdG8gd2hldGhlciB0aGlzIGFwcGxpZXMgdG8g c2VydmVyIG9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFN1Z2dlc3QgcmVuYW1pbmcgcGFyYW1l dGVyIHRvICJ0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QiDQoNClRoaXMgaXMgdGhl IGZpcnN0IEkndmUgaGVhcmQgb2YgdGhpcyBwYXJ0aWN1bGFyIGNvbmZ1c2lvbi4gSSdtIGZpbmUg d2l0aCBlaXRoZXIgbmFtZSBidXQgYXQgdGhpcyBzdGFnZSBJIGRvbid0IHdhbnQgdG8gbWFrZSBz eW50YXggY2hhbmdlcyB3aXRob3V0IHZlcnksIHZlcnkgY29tcGVsbGluZyByZWFzb25zIHRvIGRv IHNvLg0KDQpUaGUgcXVlc3Rpb24gd2FzIHJhaXNlZCB0byBtZSBieSBzb21lIG5ldyBkZXZlbG9w ZXJzLiBJdCBzZWVtcyBvYnZpb3VzIHRvIHVzIGFzIGV4cGVyaWVuY2VkIE9BdXRoIHBlcnNvbnMs IGJ1dCB0byBuZXcgZGV2ZWxvcGVycyBpdCBzZWVtcyB1bmNsZWFyLiAgQWxzbywgbm93IHRoYXQg eW91IGFyZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRpb24gYXV0aGVudGljYXRpb24sIHRoZSB3aG9s ZSB0aGluZyBnZXRzIHZlcnkgY29uZnVzaW5nLiBTbyBpdCBpcyB1c2VmdWwgZGlzYW1iaWd1YXRl IGFsbCB0aGUgcGFyYW1ldGVycyB3aGVyZSBwb3NzaWJsZS4gIFRoYXQgc2FpZCwgSSB3b3VsZG4n dCBtaW5kIHNob3J0ZXIgbmFtZXMgKG1heWJlIG5vdCBxdWl0ZSBhcyBzaG9ydCBhcyB0aGUgSk9T RSBzdHVmZiA7LSkNCg0KRmFpciBlbm91Z2gsIGJ1dCBhZ2FpbiwgSSBvbmx5IHdhbnQgdG8gZG8g c3ludGF4IGNoYW5nZXMgaWYgdGhlIHJlc3Qgb2YgdGhlIFdHICpyZWFsbHkqIHdhbnRzIHRvLg0K DQpJIGFncmVlIHdpdGggSnVzdGluIGhlcmUuICBJ4oCZbSBmaW5lIGNsYXJpZnlpbmcgdGhlIGRl c2NyaXB0aW9uIG9mIHRoaXMgcGFyYW1ldGVyIHRvIHJlc29sdmUgdGhlIHBvdGVudGlhbCBhbWJp Z3VpdGllcyB0aGF0IHlvdSBjaXRlLCBQaGlsLiAgSeKAmW0gbm90IE9LIHJldmlzaW5nIHRoZSBz eW50YXggd2l0aG91dCBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLg0KDQoqIEN1cnJlbnRs eSwgdGhlIEFQSSBvbmx5IHN1cHBvcnRzIGEgc2luZ2xlIHZhbHVlIGluc3RlYWQgb2YgYW4gYXJy YXkuICBJZiB0aGUgcHVycG9zZSBpcyB0byBhbGxvdyB0aGUgY2xpZW50IHRvIGtub3cgd2hhdCBh dXRoIG1ldGhvZHMgaXQgc3VwcG9ydHMsIHRoaXMgc2hvdWxkIGJlIGFuIGFycmF5IGluZGljYXRl ZCB3aGF0IG1ldGhvZHMgdGhlIGNsaWVudCBzdXBwb3J0cyAtIG9yIGl0IHNob3VsZCBub3QgYmUg dXNlZC4NCg0KSSB3b3VsZCByYXRoZXIgbGlrZSB0aGlzIHRvIGJlIGFuIGFycmF5LCBwZXJzb25h bGx5LCBhbmQgYnJvdWdodCBpdCB1cCB3aXRoIHRoZSBPcGVuSUQgQ29ubmVjdCB3b3JraW5nIGdy b3VwIGFib3V0IHNpeCBtb250aHMgYWdvLiBCdXQgdGhlcmUgaXQgd2FzIGRlY2lkZWQgdGhhdCBh IHNpbmdsZSB2YWx1ZSB3YXMgc2ltcGxlciBhbmQgc3VmZmljaWVudCBmb3IgdGhlIHB1cnBvc2Uu IFRoZSBJRVRGIGRyYWZ0IGhhcyBpbmhlcml0ZWQgdGhpcyBkZWNpc2lvbi4gSSAqYmVsaWV2ZSog KHRob3VnaCBhbSBub3QgMTAwJSBwb3NpdGl2ZSkgdGhhdCBJIGJyb3VnaHQgdXAgdGhpcyB2ZXJ5 IGlzc3VlIGluIHRoZSBXRyBoZXJlIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhbnkgdHJhY3Rpb24gb24g aXQsIHNvIHNpbmdsZSBpdCByZW1haW5zLg0KDQpJIGNhbiBnZXQgYmVoaW5kIG11bHRpcGxlIHZh bHVlcy4gSW4gdGhpcyBjYXNlLCBpdCBjaGFuZ2VzIHRoZSBtZWFuaW5nIG9mIHRoZSBwYXJhbWV0 ZXIuIEluc3RlYWQgb2YgdGhlIGNsaWVudCBmb3JjaW5nIHRoZSBzZXJ2ZXIgdG8gdXNlIGEgcGFy dGljdWxhciBtZXRob2QsIHRoZSBjbGllbnQgaXMgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIgYWJvdXQg d2hhdCBtZXRob2RzIGl0IGNhbiBwZXJmb3JtLiBUaGlzIGFsbG93cyB0aGUgc2VydmVyIHRvIGFz c2lnbiB0aGUgYXBwcm9wcmlhdGUgbWV0aG9kIGJhc2VkIG9uIGl0cyBvd24gcG9saWN5Lg0KDQoN CkFsc28gbm90ZSB0aGF0IHRoaXMgZmllbGQsIGxpa2UgYWxsIG90aGVycyBpbiDCpzIsIHJlcHJl c2VudHMgdHdvIHRoaW5nczogdGhlIGNsaWVudCB0ZWxsaW5nIHRoZSBzZXJ2ZXIgIkkgd2FudCB0 byB1c2UgdGhpcyB2YWx1ZSBmb3IgdGhpcyBmaWVsZCIsIGFuZCB0aGUgc2VydmVyIHRlbGxpbmcg dGhlIGNsaWVudCAidGhpcyBpcyB0aGUgdmFsdWUgeW91IGhhdmUgZm9yIHRoaXMgZmllbGQiLiBJ dCdzIG5vdCBleGFjdGx5IGEgbmVnb3RpYXRpb24sIG1vcmUgbGlrZSBtYWtpbmcgYSBwb2xpdGUg cmVxdWVzdCB0byBhbiBhYnNvbHV0ZSBkaWN0YXRvciB3aG8gaGFzIHRoZSBsYXN0IHdvcmQgYW55 d2F5LiBCdXQgYXQgbGVhc3QgdGhpcyBkaWN0YXRvciBpcyBuaWNlIGVub3VnaCB0byB0ZWxsIHlv dSB3aGF0IHRoZWlyIGRlY2lzaW9uIHdhcyBpbnN0ZWFkIG9mIGp1c3QgZGVjYXBpdGF0aW5nIHlv dS4NCg0KVGhpcyBpcyB0aGUgaGVhcnQgb2YgbXkgb2JqZWN0aW9uLiBUaGlzIGZ1enppbmVzcyBp cyBpcyBnb2luZyB0byBsZWFkIHRvIGludGVyb3AgaXNzdWVzLg0KDQpUaGVyZSBpcyBubyBmdXp6 aW5lc3MgdGhhdCBJIGNhbiBzZWUgaGVyZS4gSXQncyBwYXJhbGxlbGlzbSBiZXR3ZWVuIHdoYXQg Z29lcyBpbiB0byB0aGUgZW5kcG9pbnQgYW5kIHdoYXQgY29tZXMgb3V0IG9mIGl0LiBUaGUgc2Vt YW50aWNzIGZvciB0aGUgcmVxdWVzdCBhbmQgdGhlIHJlc3BvbnNlIGFyZSBkaWZmZXJlbnQsIGFu ZCBkaWZmZXJlbnRpYWJsZSBieSB0aGUgZmFjdCB0aGF0IG9uZSBpcyBhIHJlcXVlc3QgYW5kIHRo ZSBvdGhlciBpcyBhIHJlc3BvbnNlLg0KDQpUaGUgaW50ZXItb3AgaXNzdWUgSSB3b3VsZCBsaWtl IHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZSBzcGVjIGRvZXMgbm90IGN1cnJlbnRseSBzcGVjaWZ5 IGlmIHBhcnRpY3VsYXIgaW5wdXQgdmFsdWVzIGFyZSBzaW5ndWxhciBvciBtdWx0aXBsZS4gIElm IGFuIGltcGxlbWVudGVyIGFzc3VtZXMgc2luZ3VsYXIgYW5kIGNsaWVudHMgYXNzdW1lIG11bHRp cGxlLCB3ZSBoYXZlIGlzc3Vlcy4NCg0KVGhlIG11bHRpcGxlL3NpbmdsZSBkaXNjdXNzaW9uIGFi b3ZlIGdldHMgdG8gdGhlIGhlYXJ0IG9mIHdoYXQgSSAqZG8qIGJlbGlldmUgaXMgYSBkZWZpY2ll bmN5IGluIHRoZSBzcGVjaWZpY2F0aW9uLCBhcyBpdOKAmXMgY3VycmVudGx5IHdyaXR0ZW4uICBU aGUgYXV0aG9ycywgbXlzZWxmIGluY2x1ZGVkLCBoYXZlIGZhaWxlZCB0byBtYWtlIGl0IDEwMCUg Y2xlYXIgdGhhdCBkaXNjb3Zlcnkgb2YgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgZnVuY3Rpb25hbGl0 eSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi4gIEkgc3Ryb25nbHkgYmVs aWV2ZSB0aGF0IHdlIG5lZWQgdG8gYWRkIGEgY2xlYXIgc3RhdGVtZW50IHRvIHRoaXMgZWZmZWN0 IGluIHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIHNwZWNpZmljYXRpb24uDQoNClRoZSBwdXJwb3Nl IG9mIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBpcyBmb3Ig dGhlIGNsaWVudCB0byByZWdpc3RlciB3aXRoIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQg dG8gaW5mb3JtIGl0IG9mIHByb3BlcnRpZXMgb2YgdGhlIGNsaWVudCB0aGF0IHRoZSBBUyBtYXkg d2FudC9uZWVkIHRvIGJlIGF3YXJlIG9mLiAgSXQgKmlzIG5vdCogdGhlIHB1cnBvc2Ugb2YgdGhp cyBzcGVjaWZpY2F0aW9uIGZvciBpdCB0byBiZSB1c2VkIGJ5IGNsaWVudHMgaW4gYW55IG1hbm5l ciB0byBkaXNjb3ZlciBmZWF0dXJlcyBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuICBUaGF0 IHNob3VsZCBiZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZS4NCg0KQ3VycmVudGx5LCBjbGllbnRz IGFyZSBpbnN0cnVjdGVkIGJ5IFJGQyA2NzQ5IHRvIGRpc2NvdmVyIGluZm9ybWF0aW9uIGFib3V0 IEF1dGhvcml6YXRpb24gU2VydmVycyB0aGV5IGludGVyYWN0IHdpdGggYnkgY29uc3VsdGluZyB0 aGUg4oCcc2VydmljZSBkb2N1bWVudGF0aW9u4oCdIChSRkMgNjc0OSwgU2VjdGlvbnMgMy4xIGFu ZCAzLjIpLiAgVGhleSBjYW4gYWxzbyBsZWFybiBpbmZvcm1hdGlvbiBhYm91dCBBdXRob3JpemF0 aW9uIFNlcnZlcnMgaW4gc3BlY2lmaWMgY29udGV4dHMgdGhyb3VnaCBkaXNjb3ZlcnkgcHJvdG9j b2xzIHN1Y2ggYXMgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5IChodHRwOi8vb3BlbmlkLm5ldC9z cGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwpIGFuZCBVTUEgRGlzY292ZXJ5 IChUQkQpLg0KDQpJIHN1c3BlY3QgdGhhdCBhdCBzb21lIHBvaW50LCBzb21lb25lIGluIHRoZSBP QXV0aCB3b3JraW5nIGdyb3VwIHdpbGwgcHJvcG9zZSBkZXZlbG9waW5nIGEgZ2VuZXJpYyBPQXV0 aCBkaXNjb3ZlcnkgbWVjaGFuaXNtLCB3aGljaCB3aWxsIGxlYWQgdG8gYSByZWNoYXJ0ZXJpbmcg dG8gaW5jbHVkZSB0aGlzIHdvcmsgaW4gdGhlIHdvcmtpbmcgZ3JvdXDigJlzIHNldCBvZiBkZWxp dmVyYWJsZXMuICBJIHdvdWxkIHN1cHBvcnQgZG9pbmcgdGhpcyB3b3JrIGFuZCB0aGUgbmVjZXNz YXJ5IHJlY2hhcnRlcmluZyB0byBkbyBzby4NCg0KVGhhdCBiZWluZyBzYWlkLCBJIHN0cm9uZ2x5 IG9wcG9zZSB0cnlpbmcgdG8gc2hvZWhvcm4gcGllY2VtZWFsIGFzcGVjdHMgb2YgZGlzY292ZXJ5 IGludG8gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uLiAgSXQg aXMgZGlzdGluY3QgZnVuY3Rpb25hbGl0eSBhbmQgZGVzZXJ2ZXMgZmlyc3QtY2xhc3MgYW5kIHNl cGFyYWJsZSB0cmVhdG1lbnQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuICBEaXNjb3ZlcnkgaXMgZm9y IHBvdGVudGlhbCBjbGllbnRzIHRvIGxlYXJuIHByb3BlcnRpZXMgb2YgdGhlIEFTIGJlZm9yZSBy ZWdpc3RyYXRpb24uICBSZWdpc3RyYXRpb24gaXMgZm9yIHBvdGVudGlhbCBjbGllbnRzIHRvIGlu Zm9ybSB0aGUgQVMgb2YgaXRzIHByb3BlcnRpZXMsIGNyZWF0aW5nIGEgcmVnaXN0ZXJlZCBjbGll bnQuICBEaXNjb3Zlcnkgc2VuZHMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEFTIHRvIHRoZSBDbGll bnQuICBSZWdpc3RyYXRpb24gc2VuZHMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIENsaWVudCB0byB0 aGUgQVMuICBUaGF04oCZcyBhIGNsZWFuIHNlcGFyYXRpb24uICBXZSBzaG91bGQgc3Ryb25nbHkg cmVzaXN0IG11ZGR5aW5nIHRoZSB0d28gZnVuY3Rpb25zLg0KDQpPQXV0aCAyLjAgaXMgYSBzdWNj ZXNzIGJlY2F1c2UgaXQgZGlkbuKAmXQgdHJ5IHRvIGJvaWwgdGhlIG9jZWFuLiAgSXQgc3BlY2lm aWVkIGhvdyB0byBkbyBvbmUgdGhpbmcgd2VsbCBpbiBhIHNpbXBsZSwgd2ViLWZyaWVuZGx5IG1h bm5lci4gIFdlIHNob3VsZCBkbyB0aGUgc2FtZSDigJMgZm9jdXNpbmcgb24gc3BlY2lmeWluZyBp bnRlcm9wZXJhYmxlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiwgd2hpbGUgbWFraW5nIGl0 IGNsZWFyIHRoYXQgdGhpcyBpcyBkaXN0aW5jdCBmcm9tIGRpc2NvdmVyeSBhYm91dCBBdXRob3Jp emF0aW9uIFNlcnZlciBwcm9wZXJ0aWVzLCBhbmQgbWFraW5nIGl0IGNsZWFyIHRoYXQgZGlzY292 ZXJ5IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyB3b3JrLg0KDQpJIGFwb2xvZ2l6ZSBhdCB0aGlz IHBvaW50IG9uIGJlaGFsZiBvZiBteXNlbGYgYW5kIHRoZSBvdGhlciBzcGVjIGVkaXRvcnMgZm9y IG5vdCBiZWluZyAxMDAlIGNsZWFyIHRoYXQgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkgaXMgZXhw bGljaXRseSBvdXQgb2Ygc2NvcGUgZm9yIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbi4gIElm IHdlIGhhZCBkb25lIHNvLCBJ4oCZbSBzdXJlIHRoYXQgbWFueSBvZiB0aGUgY3VycmVudCBxdWVz dGlvbnMgYW5kIGNvbmZ1c2lvbnMgd291bGQgbm90IGhhdmUgYXJpc2VuLiAgSSB0aGluayB3ZeKA mWQgYXNzdW1lZCB0aGF0IHRoaXMgd2FzIG9idmlvdXMsIGJ1dCBmcm9tIHRoZSBjdXJyZW50IGRp c2N1c3Npb25zLCBpdOKAmXMgYXBwYXJlbnQgdGhhdCBpdOKAmXMgbm90IG9idmlvdXMuICBJIHdp bGwgcGVyc29uYWxseSBjb21taXQgdG8gY2xhcmlmeWluZyB0aGUgc3BlY2lmaWNhdGlvbiBhdCB0 aGlzIHBvaW50IHRvIGVsaW1pbmF0ZSB0aGlzIHBvdGVudGlhbCBwb2ludCBvZiBjb25mdXNpb24u DQoNCkdldHRpbmcgYmFjayB0byB0aGUgc3BlY2lmaWNzLCB0aGUgb25seSB1c2VmdWwgcHVycG9z ZSBvZiBhIG11bHRpLXZhbHVlZCDigJx0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2Ti gJ0gbWVtYmVyIHdvdWxkIGJlIHRvIGVuYWJsZSB0aGUgY2xpZW50IHRvIGRpc2NvdmVyIGluZm9y bWF0aW9uIGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIHN1cHBvcnRlZCBieSB0aGUg QVMgYWZ0ZXIgdGhlIHJlZ2lzdHJhdGlvbiBoYWQgYmVlbiBwZXJmb3JtZWQuICBCdXQgdGhhdCBp cyBhIGRpc2NvdmVyeSBmdW5jdGlvbiwgYW5kIHNvIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBkaXNj b3Zlcnkgd29yayDigJMgbm90IHRoaXMgc3BlY2lmaWNhdGlvbi4gIFdlIHNob3VsZCByZXNpc3Qg c2hvZWhvcm5pbmcgaW4gYml0cyBvZiBkaXNjb3ZlcnkgaW50byB0aGlzIHNwZWNpZmljYXRpb24u ICBJdCAqaXMqIGEgd29ydGh3aGlsZSB0b3BpYywgYnV0IGRlc2VydmVzIGZ1bGwgY29uc2lkZXJh dGlvbiBieSB0aGUgd29ya2luZyBncm91cCBpbiBpdHMgb3duIHJpZ2h0LiAgVGhlcmVmb3JlLCB0 aGlzIG1lbWJlciBtdXN0IHJlbWFpbiBzaW5nbGUtdmFsdWVkLCBhbmQgYmUgY2xlYXJseSBzcGVj aWZpZWQgYXMgdGhlIG1ldGhvZCBieSB3aGljaCBhIGNsaWVudCBpbmZvcm1zIHRoZSBBUyB3aGlj aCB0b2tlbiBlbmRwb2ludCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaXQgd2lsbCB1c2UuICBBbnl0 aGluZyBlbHNlIHdvdWxkIGJlIHNjb3BlIGNyZWVwLCBhbmQgcmVzdWx0IGluIGFuIHVubmVjZXNz YXJpbHkgY29tcGxpY2F0ZWQgc3BlY2lmaWNhdGlvbiBhbmQgdW5uZWNlc3NhcmlseSBjb21wbGlj YXRlZCBjbGllbnRzLg0KDQoqIFRoZXJlIGlzIG5vIGF1dGhuIG1ldGhvZCBmb3IgImNsaWVudF9z ZWNyZXRfc2FtbCIgb3IgInByaXZhdGVfa2V5X3NhbWwiLg0KDQpOb2JvZHkgaGFzIHJlYWxseSBh c2tlZCB0aGF0IHRoZXNlIHR3byBiZSBpbmNsdWRlZCBvciBzcGVjaWZpZWQuIFRoZSBleHRlbnNp b24gbWVjaGFuaXNtICh1c2luZyBhbiBhYnNvbHV0ZSBVUkkpIHdvdWxkIGFsbG93IHNvbWVvbmUg ZWxzZSB0byBkZWZpbmUgdGhlc2UuIElzIHRoZSBkZWZpbml0aW9uIGluIHRoZSBTQU1MIEFzc2Vy dGlvbiBkcmFmdCBzdWZmaWNpZW50IGZvciB0aGVpciB1c2U/DQoNCkkgdGhpbmsgdGhpcyBpcyBj b21pbmcgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgSldUIGJlYXJlciBkcmFmdCBhbmQg YSBTQU1MIGJlYXJlciBkcmFmdC4gIFRoZSB0cnV0aCBpcyB5b3UgYXJlIGRlZmluaW5nIGFuIGF1 dGhlbnRpY2F0aW9uIHRoYXQgaXNuJ3QgZXZlbiBkZWZpbmVkLg0KDQpUaGVyZSBhcmUgbm8gcHJv ZmlsZXMgcmVmZXJlbmNlZCBvciBkZWZpbmVkIGZvciAiY2xpZW50X3NlY3JldF9qd3QiIG9yICJw cml2YXRlX2tleV9qd3QiLiBOZWl0aGVyIG9mIHRoZSBKV1Qgb3IgU0FNTCBCZWFyZXIgZHJhZnRz IHJlZmVyZW5jZWQgY292ZXIgdGhlc2UgdHlwZXMgb2YgZmxvd3MuIFRoZXkgb25seSBjb3ZlciBi ZWFyZXIgZmxvd3MuICAiY2xpZW50X3NlY3JldF9qd3QiIGFuZCAicHJpdmF0ZV9rZXlfand0IiBz ZWVtIHRvIGhhdmUgc29tZSBtZWFuaW5nIHdpdGhpbiBPcGVuSUQgQ29ubmVjdCwgYnV0IEkgbm90 ZSB0aGF0IE9JREMgZG9lcyBub3QgZnVsbHkgZGVmaW5lIHRoZXNlIGVpdGhlci4NCg0KVGhlIEpX VCBhc3NlcnRpb24gZHJhZnQgZG9lcyBzYXkgaG93IHRvIHVzZSBhIEpXVCBmb3IgY2xpZW50IGF1 dGhlbnRpY2F0aW9uLCBhbmQgdGhlIER5blJlZyB0ZXh0IGRpZmZlcmVudGlhdGVzIGJldHdlZW4g YSBjbGllbnQgc2lnbmluZyBzYWlkIEpXVCB3aXRoIGl0cyBvd24gc2VjcmV0IHN5bW1ldHJpY2Fs bHkgdnMuIGEgY2xpZW50IHVzaW5nIGl0cyBvd24gcHJpdmF0ZSBrZXksIGFzeW1tZXRyaWNhbGx5 Lg0KDQpBY3R1YWxseSBteSBpbnRlcnByZXRhdGlvbiBpcyB0aGUgSldUIGRyYWZ0IGFzc3VtZXMg dGhlIEpXVCBCZWFyZXIgaXMgYSBiZWFyZXIgdG9rZW4uICBUaGUgYXNzdW1wdGlvbiBpcyB0aGF0 IGlmIGEgY2xpZW50IGhhcyB0aGUgYXNzZXJ0aW9uIGl0IGhhcyB0aGUgcmlnaHQgdG8gcHJlc2Vu dCBpdC4gIElPVy4gVGhlIEpXVCBCZWFyZXIgRHJhZnQgaXMgbW9zdCBkZWZpbml0aXZlbHkgbm90 IGEgSldUIEhvSyBEcmFmdC4gIDotKQ0KDQpSZWdhcmRsZXNzLCB5b3UgYXJlIGludHJvZHVjaW5n IGEgbmV3IHByb2ZpbGUgd2hpY2ggaXMgdW5kZWZpbmVkLg0KDQpJIHRoaW5rIEkgc2VlIHRoZSBw b2ludCB0aGF0IHlvdSdyZSBtYWtpbmcgbm93LCBsZXQgbWUgdHJ5IHRvIHJlLXN0YXRlIGl0Og0K DQpXaGlsZSB0aGUgYmFzaWNzIG9mICJob3cgdG8gcHJlc2VudCBhIEpXVCBhcyBhIGNsaWVudCBj cmVkZW50aWFsIiBpcyBkZWZpbmVkIGhlcmU6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUuaHRtbCNyZmMuc2VjdGlvbi4yLjIgLCBpdCdzIG5v dCBjb21wbGV0ZWx5IHNwZWNpZmllZCBpbiB0aGF0IGl0IGRvZXNuJ3QgZnVsbHkgcmVzdHJpY3Qg dGhlIHNpZ25hdHVyZSBzZWNyZXQgc291cmNlLCB0aGUgYXVkaWVuY2UgY2xhaW0sIGFuZCBvdGhl ciB0aGluZ3MgdGhhdCB0aGUgQVMgd291bGQgbmVlZCB0byBjaGVjayBhbmQgdmFsaWRhdGUuIFJp Z2h0PyBUaGUgZHluYW1pYyByZWdpc3RyYXRpb24gZHJhZnQgY2FuIGRlZmluZSB0aG9zZSBjYXNl cyBpbiBncmVhdGVyIGRldGFpbCBpZiBuZWVkZWQgKHRob3VnaCBJIHRoaW5rIGl0IGRvZXMgc28g c3VmZmljaWVudGx5IGFzLWlzLCBJIHdlbGNvbWUgbW9yZSBjbGFyaXR5KS4NCg0KSSdkIGJlIE9L IHdpdGggYWRkaW5nIHRoZSBTQU1MIGJpdCwgZ29pbmcgaW50byBncmVhdGVyIGRldGFpbCBvbiB0 aGUgSldUIGJpdHMsIG9yIGRyb3BwaW5nIHRoZSBKV1QgYml0cywgaWYgdGhlIFdHIHdhbnRzIHRv IGRvIGFueSBvZiB0aG9zZSBhY3Rpb25zLiBNeSBvYmplY3Rpb24gaXMgdGhhdCB0aGUgSldUIHN0 dWZmIGlzIGFscmVhZHkgaW4gdXNlIGFuZCBmdW5jdGlvbmluZyBhbmQgaXQnZCBiZSBhIHNoYW1l IHRvIGxlYXZlIGl0IG91dC4NCg0KSSBndWVzcyB0aGVuIHRoZSBtaXN0YWtlIHRoZSBKV1QgQmVh cmVyIGFuZCBTQU1MIEJlYXJlciBkcmFmdHMgYXV0aG9ycyBtYWRlIGlzIHRoZXkgYXNzdW1lZCBl dmVyeW9uZSBoYWQgdGhlIHNhbWUgZGVmaW5pdGlvbiBvZiBiZWFyZXIgdG9rZW4uICBUbyBtZSBh IGJlYXJlciB0b2tlbiBvcGFxdWUgdG8gdGhlIGNsaWVudC4gSXQgdGhlcmVmb3JlIGNhbm5vdCBk byBhbnkgc2lnbmF0dXJlIHdvcmsgd2l0aCByZWdhcmRzIHRvIHRoZSB0b2tlbiBpdHNlbGYuICBO b3csIHRoYXQncyBub3QgdG8gc2F5IGEgcHJvb2YgZGlkbid0IG9jY3VyIGJldHdlZW4gdGhlIGNs aWVudCBhbmQgdGhlIHRva2VuIGlzc3VlciwgYnV0IHdoZW4gdGhlIGNsaWVudCB3aWVsZHMgdGhl IHRva2VuLCBpdCBpcyBoYW5kbGluZyBhbiBvcGFxdWUgc3RyaW5nLg0KDQpUaGUgY29uY2VwdCBv ZiBjbGllbnRfc2VjcmV0X2p3dCBzdWdnZXN0cyBhbiBIb0sgcHJvZmlsZS4gIFRoZXJlZm9yZSBv ZiBjb3Vyc2UgdGhlIGJlYXJlciBkcmFmdHMgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lmaWVkIHdo ZW4gaXQgY29tZXMgdG8gSG9LIHByb2ZpbGVzLg0KDQpTbyBmb3IgZXhhbXBsZSwgeW91IG5lZWQg YSBkcmFmdCBsaWtlIHRoZSBNQUMgZHJhZnQgZm9yIHRoaXMuDQoNCkknbSBoYXZpbmcgdHJvdWJs ZSBvdmVyYWxsIGhlcmUuIEl0IHNlZW1zIHRoZSBhdXRobiB0eXBlcyBzdWdnZXN0IE9OTFkgc3Ry b25nIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnRzLCB5ZXQgZHVyaW5nIHRoZSByZWdpc3RyYXRp b24gcHJvY2VzcyB0aGUgY3VycmVudCBkcmFmdCBpc24ndCBhYmxlIHRvIGNvcnJlbGF0ZSBtdWx0 aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgc29mdHdhcmUgKGV2ZW4gaW4gYSBzZWxmLWFzc2Vy dGVkIHdheSkuICBJZiB5b3UgaGF2ZW4ndCBhdXRoZW50aWNhdGVkIHRoZSBzb2Z0d2FyZSBhdCBh bGwsIHdoeSBoYXZlIHN0cm9uZyBjbGllbnQgYXV0aD8NCg0KVGhlcmUgaXMgbm8gYXV0aGVudGlj YXRpb24gbWV0aG9kIGRlZmluZWQgZm9yICJjbGllbnRfYmVhcmVyX3NhbWwiIG9yICJjbGllbnRf YmVhcmVyX2p3dCIgb3IgImNsaWVudF9iZWFyZXJfcmVmIi4gIFNpbmNlIHRoZSBiZWFyZXIgc3Bl Y3Mgc2F5IHRoaXMgaXMgYWNjZXB0YWJsZSwgIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVj IHNob3VsZCBhY2NlcHQgdGhlc2UuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGJpdCAtLSB3 aGVyZSBhcmUgdGhlc2UgZGVmaW5lZCBpbiBSRkM2NzUwPyBJIGRvbid0IGV2ZW4ga25vdyB3aGF0 IGNsaWVudF9iZWFyZXJfcmVmIHdvdWxkIHJlZmVyIHRvLg0KDQo2NzUwIHNheXMgeW91IGNhbiB1 c2UgYSBiZWFyZXIgYXNzZXJ0aW9uIChlLmcuIG9idGFpbmVkIGZyb20gYW4gSURQKSBhbmQgd2ll bGQgaXQgYXMgYW4gYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uLiAgVGhlIGNsaWVudCBpcyBOT1Qg Y3JlYXRpbmcgb3IgbW9kaWZ5aW5nIHRoZSBhc3NlcnRpb24uIFRoZSBjbGllbnQgaXMgc2ltcGx5 IHBhc3Npbmcgb25lIGl0IHByZXZpb3VzbHkgb2J0YWluZWQuDQoNCldoYXQgeW91IGFyZSBkZXNj cmliaW5nIGlzIG5vdCBiZWFyZXIuIEl0IGlzIGhvbGRlciBvZiBrZXkuIFZlcnkgdmVyeSBkaWZm ZXJlbnQuDQoNCg0KQSBwb3NzaWJsZSBzdWdnZXN0aW9uIGlzIHRvIHJlbW92ZSBjbGllbnRfc2Vj cmV0X2p3dCBhbmQgcHJpdmF0ZV9rZXlfand0IGFuZCBkZWZpbmUgdGhvc2UgYXMgcmVnaXN0ZXIg ZXh0ZW5zaW9ucyBzaW5jZSB0aGVzZSBwcm9maWxlcyBhcmUgbm90IGRlZmluZWQuDQoNClRoYXQn cyBwb3NzaWJsZSwgYnV0IHRoZXkgYXJlIGluIGFjdGl2ZSB1c2UgYWxyZWFkeS4NCg0KVGhhdCBt YXkgYmUgdHJ1ZS4gQnV0IHRoZW4geW91IG5lZWQgdG8gd3JpdGUgYW5vdGhlciBkcmFmdCBzbyB0 aGUgcmVzdCBvZiB1cyBjYW4gaW1wbGVtZW50IGl0IGluIGFuIGludGVyb3BlcmFibGUgd2F5LiAg TWUgSSBwcmVmZXIgbm90IHRvIGd1ZXNzIHdoYXQgeW91IGFyZSBkb2luZy4NCg0KVGhpcyBtdWNo IEkgYWdyZWUgd2l0aC4NCg0KSnVzdGluLCBKb2huLCBhbmQgSSBkaXNjdXNzZWQgdGhpcyBpc3N1 ZSBhbmQgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24sIFBoaWwuICBTaW5jZSB0aGV5IGFyZSBu b3QgY29tcGxldGVseSBzcGVjaWZpZWQsIHdlIHdpbGwgcmVtb3ZlIHRoZSBjbGllbnRfc2VjcmV0 X2p3dCBhbmQgcHJpdmF0ZV9rZXlfand0IG1ldGhvZHMgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiBh bmQgYWRkIGEgcmVnaXN0cnksIGVuYWJsaW5nIHNwZWNpZmljYXRpb24gdGhhdCBkbyBmdWxseSBz cGVjaWZ5IHRoZXNlIGFuZCBvdGhlciB0b2tlbiBlbmRwb2ludCBhdXRoZW50aWNhdGlvbiBtZXRo b2RzLCBpbmNsdWRpbmcgcG90ZW50aWFsIG1ldGhvZHMgdXNpbmcgU0FNTCBhc3NlcnRpb25zLCB0 byByZWdpc3RlciB0aGVtIGluIHRoZSByZWdpc3RyeSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGJh a2UgdGhlbSBpbnRvIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlv bi4NCg0KQWJvdXQgInRvc191cmkiIGFuZCAicG9saWN5X3VyaSINCg0KVGhlIGRpc3RpbmN0aW9u IGJldHdlZW4gdG9zX3VyaSBhbmQgcG9saWN5X3VyaSBpcyB1bmNsZWFyLiAgQ2FuIHdlIGNsYXJp Znkgb3IgY29tYmluZSB0aGVtPw0KDQpUZXJtcyBvZiBzZXJ2aWNlIGFuZCBwb2xpY3kgYXJlIHR3 byBkaWZmZXJlbnQgZG9jdW1lbnRzLiBPbmUgaXMgc29tZXRoaW5nIHRoYXQgYSB1c2VyIGFjY2Vw dHMgKGdlbmVyYWxseSBkZXNjcmliaW5nIHdoYXQgdGhlIHVzZXIgd2lsbCBkbyksIG9uZSBpcyBh IHN0YXRlbWVudCBvZiB3aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChpbiB0aGlzIGNhc2UsIHRo ZSBjbGllbnQpIHdpbGwgZG8uIE1vcmUgaW1wb3J0YW50bHksIHdlIHVzZWQgdG8gaGF2ZSBvbmx5 IG9uZSwgYW5kIHNldmVyYWwgcGVvcGxlIGFza2VkIGZvciB0aGVtIHRvIGJlIHNwbGl0Lg0KDQpT ZXZlcmFsIGRldmVsb3BlcnMgd2VyZSBjb25mdXNlZCBieSB0aGlzLiBJbiBwYXJ0aWN1bGFyIHRo ZXkgY291bGRuJ3QgZmlndXJlIG91dCB3aGljaCB3YXMgdXNlZCBmb3Igd2hhdC4gIEp1c3QgcGFz c2luZyBhbG9uZyB0aGUgZmVlZGJhY2suDQoNCk9LLCB0aGUgZGlzdGluY3Rpb24gdGhhdCBJIHNl ZSBpcyB0aGF0IHRoZSBUT1MgaXMgY29udHJhY3R1YWwsIHRoZSBQb2xpY3kgaXMgYSBzdGF0ZW1l bnQuIFJlLXJlYWRpbmcgdGhlIGRlZmluaXRpb25zIGluIHRoZXJlIHJpZ2h0IG5vdywgdGhhdCBj YW4gYmUgbWFkZSBtdWNoIGNsZWFyZXIuIChJdCBldmVuIGxvb2tzIGxpa2Ugc29tZSBPSURDIHRl eHQgbGVha2VkIGludG8gdGhlIGRlZmluaXRpb24gb2YgcG9saWN5X3VyaSBhbmQgdGhhdCBoYWRu J3QgYmVlbiBjYXVnaHQgeWV0LikNCg0KSSBzdXBwb3J0IGNsYXJpZnlpbmcgdGhlIGxhbmd1YWdl IG9uIHRoZXNlIGRlZmluaXRpb25zLCBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIHRvIGRvIHNv Lg0KDQpBbHNvLCBhcmVuJ3QgdGhlc2UgcmVhbGx5IFVSSXMgb3IgYXJlIHRoZXkgbWVhbnQgdG8g YmUgVVJMcz8NCg0KVGhlcmUgd2FzIGFscmVhZHkgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRo ZSBsaXN0OiBUaGUgSUVURiBpcyBhcHBhcmVudGx5IHRyeWluZyB0byBkZXByZWNhdGUgVVJMIGlu IGZhdm9yIG9mIFVSSSBpbiBuZXcgc3BlY3MuIFNvIGluIHByYWN0aWNlIHRoZXknbGwgbmVhcmx5 IGFsd2F5cyBiZSBVUkxzLCBidXQgc2luY2UgYWxsIFVSTHMgYXJlIFVSSXMgd2UncmUgbm90IHRl Y2huaWNhbGx5IGluY29ycmVjdCBpbiBmb2xsb3dpbmcgdGhlIG5ldyBwb2xpY3kuIEFuZCBpdCBt YWtlcyB0aGUgSUVTRyBsZXNzIG1hZCBhdCB1cywgd2hpY2ggaXMgYSBwbHVzLg0KDQpBcmcuIE5p Y2UuICBUaGVuIHRoZSB0ZXh0IHNob3VsZCBzYXkgdGhlIHZhbHVlIHBhc3NlZCBtdXN0IHJlc29s dmUgdG8gYSB2YWxpZCB3ZWIgcGFnZSwgZG9jdW1lbnQsIHdoYXRldmVyLg0KDQpUaGF0J3MgZmFp ciwgYW5kIGl0J3Mgc29tZXRoaW5nIHRoYXQgdGhlIEFTIGNhbiBldmVuIGNoZWNrIGlmIGl0IHdh bnRzIHRvLg0KDQpBZ3JlZWQgb24gdGhpcyBjbGFyaWZpY2F0aW9uLg0KDQpBYm91dCAiandrc191 cmkiDQoNCkEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wOSBpcyBuZWVkZWQuDQoNClllcywgeW91 J3JlIGNvcnJlY3QsIEknbGwgYWRkIHRoYXQuDQoNClNob3VsZCBiZSBVUkwgaW5zdGVhZCBvZiBV Ukk/DQoNClNlZSBhYm92ZS4gOikNCg0KQWdyZWVkIG9uIGFkZGluZyB0aGlzIHJlZmVyZW5jZS4N Cg0KU2VjdGlvbiAyLjENCg0KSW4gdGhlIHRhYmxlIHVybjppZXRmOnBhcmFtczpvYXV0aDpncmFu dC10eXBlOmp3dC1iZWFyZXINCmlzIG1pc3NpbmcuDQoNCkl0J3MgdGhlcmUgaW4gdGhlIGNvcHkg b2YgLTEwIEknbSByZWFkaW5nIG9mZiBvZiBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmcvPiByaWdo dCBub3cg4oCmID8NCicNClNvcnJ5IEkgbWVhbnQ6IHVybjppZXRmOnBhcmFtczpvYXV0aDpncmFu dC10eXBlOnNhbWwtYmVhcmVyDQoNCkFoLCB0aGF0IG1ha2VzIG1vcmUgc2Vuc2UuIElmIHRoZSBX RyB3YW50cyB0byBhZGQgaW4gU0FNTCBzdXBwb3J0IHRvIHBhcmFsbGVsIHRoZSBKV1Qgc3VwcG9y dCwgSSdkIGJlIE9LIHdpdGggdGhhdC4NCg0K4oCcQXMgc3VjaCwgYSBzZXJ2ZXIgc3VwcG9ydGlu ZyB0aGVzZSBmaWVsZHMgU0hPVUxEIHRha2Ugc3RlcHMgdG8gZW5zdXJlIHRoYXQgYSBjbGllbnQg Y2Fubm90IHJlZ2lzdGVyIGl0c2VsZiBpbnRvIGFuIGluY29uc2lzdGVudCBzdGF0ZS7igJ0NCg0K V2UgbWF5IHdhbnQgdG8gZGVmaW5lIG1vcmUgZGV0YWlsZWQgSFRUUCBlcnJvciByZXNwb25zZS4g RS5nLiA0MDAgc3RhdHVzIGNvZGUgKyBkZWZpbmVkIGVycm9yIGNvZGUgKOKAnGludmFsaWRfY2xp ZW50X21ldGFkYXRh4oCdKT8NCg0KSSdkIGJlIGZpbmUgd2l0aCBkZWZpbmluZyBhIG1vcmUgZXhw bGljaXQgZXJyb3Igc3RhdGUgaW4gdGhpcyBjYXNlLiBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgaW50 ZXJvcCBmb3IgdGhlIHNlcnZlcnMgdGhhdCB3YW50IHRvIGVuZm9yY2UgZ3JhbnQtdHlwZSBhbmQg cmVzcG9uc2UtdHlwZSByZXN0cmljdGlvbnMsIGJ1dCBzZXJ2ZXJzIHRoYXQgY2FuJ3Qgb3IgZG9u J3QgY2FyZSBhYm91dCByZXN0cmljdGluZyBncmFudHMgdHlwZXMgYW5kIHdoYXRub3QgZG9uJ3Qg aGF2ZSB0byBkbyBhbnl0aGluZyBzcGVjaWFsLg0KDQpJICp0aGluayogdGhhdCB0aGlzIGdvZXMg YXdheSB3aXRoIHRoZSBkZWxldGlvbiBvZiBjbGllbnRfc2VjcmV0X2p3dCBhbmQgcHJpdmF0ZV9r ZXlfand0IGluIGZhdm9yIG9mIHRoZSByZWdpc3RyeeKApiAgSeKAmWxsIGRvIGEgY29uc2lzdGVu Y3kgY2hlY2sgYW5kIHZlcmlmeSB0aGF0IHdoZW4gdGhlIHNwZWMgaXMgdXBkYXRlZCBhY2NvcmRp bmdseS4NCg0KU2VjdGlvbiAyLjINCg0KTWF5IHdhbnQgdG8gYWRkOg0KDQpXaGVuIOKAnCPigJ0g bGFuZ3VhZ2UgdGFnIGlzIG1pc3NpbmcsIChlLmcuIOKAnCNlbuKAnSBpcyBtaXNzaW5nIGluIOKA nGNsaWVudF9uYW1l4oCdLCBpbnN0ZWFkIG9mIOKAnGNsaWVudF9uYW1lI2Vu4oCdKSB0aGUgT0F1 dGggc2VydmVyIG1heSB1c2UgaW50ZXJwcmV0IHRoZSBsYW5ndWFnZSB1c2VkIGJhc2VkIG9uIHNl cnZlciBjb25maWd1cmF0aW9uIG9yIGhldXJpc3RpY3MuDQoNClRoYXQgc2VlbXMgaW5jb25zaXN0 ZW50IHdpdGggd2hhdCB3ZSBhbHJlYWR5IGhhdmU6DQoNCklmIGFueSBodW1hbi1yZWFkYWJsZSBm aWVsZCBpcyBzZW50IHdpdGhvdXQgYSBsYW5ndWFnZSB0YWcsIHBhcnRpZXMgdXNpbmcgaXQgTVVT VCBOT1QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIg c2V0LCBvciBzY3JpcHQgb2YgdGhlIHN0cmluZyB2YWx1ZSwgYW5kIHRoZSBzdHJpbmcgdmFsdWUg TVVTVCBiZSB1c2VkIGFzLWlzIHdoZXJldmVyIGl0IGlzIHByZXNlbnRlZCBpbiBhIHVzZXIgaW50 ZXJmYWNlLg0KDQpXaGljaCBpcyB0byBzYXksIHRyZWF0IGl0IGFzIGEgcmF3IGJ5dGUtdmFsdWUt c3RyaW5nIGFuZCBkb24ndCB0cnkgdG8gZ2V0IGZhbmN5Lg0KDQpJIHdpbGwgZGlzY3VzcyB3aXRo IG91ciBkZXZlbG9wZXJzLiBJJ20gbm90IHN1cmUgdGhlIGFzLWlzIHdvcmtzLg0KDQpJcyBpdCB0 aGUgaW50ZW50IHRoYXQgd2hlbiB0aGUgY2xpZW50IGhhcyBsb2NhbGl6ZWQgImNsaWVudF9uYW1l IiBmb3IgZXhhbXBsZSwgaXQgc2hvdWxkIHBhc3MgYWxsIGxhbmd1YWdlIHZhcmlhdGlvbnMgaW4g YSBKU09OIGFycmF5Pw0KDQpPciwgc2hvdWxkIHBhcnQgb2YgdGhlIHJlZ2lzdHJhdGlvbiBiZSB0 byBpbmRpY2F0ZSB3aGljaCBpbnRlcmZhY2UgbGFuZ3VhZ2UgdGhlIGNsaWVudCB3aXNoZXMgdG8g dXNlPyAgVGhlbiBpdCBvbmx5IHBhc3NlcyBhIHNpbmdsZSB2YWx1ZSBmb3IgdGhhdCByZWdpc3Ry YXRpb24/DQoNCg0KTm8sIHRoZSBjbGllbnQgc2hvdWxkIHBhc3MgcGFyYW1ldGVycyBhcyBtdWx0 aXBsZSBzZXBhcmF0ZSB2YWx1ZXMuIENvbm5lY3QgaGFzIHRoaXMgaW4gaXRzIGV4YW1wbGU6DQoN Cg0KICAgImNsaWVudF9uYW1lIjogIk15IEV4YW1wbGUiLA0KDQogICAiY2xpZW50X25hbWUjamEt SnBhbi1KUCI6DQoNCiAgICAgIuOCr+ODqeOCpOOCouODs+ODiOWQjSIsDQpTaG91bGQgd2UgYWRk IHRoYXQgdG8gYXQgbGVhc3Qgb25lIG9mIHRoZSBleGFtcGxlcyBpbiBEeW5SZWc/IChUaGUgbGFu Z3VhZ2UgdGFncyBhcmUgYSBsYXRlIGFkZGl0aW9uLCBzbyB0aGUgZXhhbXBsZXMgZG9uJ3QgcmVm bGVjdCBpdC4pDQoNCkFuIGV4YW1wbGUgd291bGQgZGVmaW5pdGVseSBoZWxwLg0KSWYgdGhlIGNs aWVudCBwYXNzZXMgb25seSBhIHNpbmdsZSB1bmFkb3JuZWQgZmllbGQsIHRoZSBBUyBjYW4ndCBt YWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHdoYXQgbGFuZ3VhZ2UgaXQgaXMuIFRoaW5rIG9mIHRo aXMgYXMgdGhlIGludGVybmF0aW9uYWxpemVkIHZhbHVlIG9mIHRoZSBmaWVsZCB3aGlsZSB0aGUg bGFuZ3VhZ2UgdGFncyBhcmUgdGhlIGxvY2FsaXplZCB2ZXJzaW9ucyBvZiB0aGUgZmllbGQuIFRo aXMgaXMgd2h5IHdlIHJlY29tbWVuZCB0aGF0IHRoZSBiYXJlLXZhbHVlIGFsd2F5cyBiZSBzZW50 IGJ5IHRoZSBjbGllbnQsIHNvIHRoYXQgaW4gdGhlIGxhY2sgb2YgYW55dGhpbmcgbW9yZSBzcGVj aWZpYywgdGhlIEFTIGNhbiBhdCBsZWFzdCBkbyAqc29tZXRoaW5nKiB3aXRoIGl0Lg0KDQpQYXNz aW5nIGluIGEgImRlZmF1bHQiIGxhbmd1YWdlIGZpZWxkIChsaWtlIGRlZmF1bHRfbG9jYWxlIG9y IHRoZSBsaWtlKSBpcyBvbmx5IGdvaW5nIHRvIGxlYWQgdG8gcGFpbiBmb3IgaW1wbGVtZW50b3Jz IG9mIGJvdGggY2xpZW50cyBhbmQgc2VydmVycywgYW5kIGl0J3MgZ29pbmcgdG8gaHVydCB0aGUg aW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgaHVtYW4tcmVhZGFibGUgZmllbGRzLg0KDQpJIHRoaW5r IHdoYXQgSSBtZWFudCBpcyBzaW5jZSB5b3UgYXJlIGFsbG93aW5nIGVhY2ggY2xpZW50IHRvIHJl Z2lzdGVyIGRpZmZlcmVudCB0aGluZ3MsIEFORCB0aGUgY2xpZW50IGxpa2VseSBhbHJlYWR5IGtu b3dzIHRoZSB1c2VyJ3MgcHJlZmVycmVkIGxhbmd1YWdlLCB3aHkgd291bGRuJ3QgdGhlIGNsaWVu dCBqdXN0IHBhc3MgdGV4dCB2YWx1ZXMgaW4gb25lIGxhbmd1YWdlIGFuZCBhbm90aGVyIHBhcmFt ZXRlciBpbmRpY2F0aW5nIHByZWZlcnJlZCBsYW5ndWFnZSBpbiB0aGUgY2FzZSBvZiBhbnkgc2Vy dmljZSBnZW5lcmF0ZWQgdGV4dC4NCg0KSXMgdGhlIHJlYXNvbiB5b3UgYXJlIHBhc3NpbmcgbXVs dGlwbGUgbG9jYWxpemF0aW9ucyBpcyBzbyB0aGF0IHlvdSBjYW4gdXNlIHRoZSBwcmVmZXJyZWQg bGFuZ3VhZ2Ugb2YgdGhlIHJlc291cmNlIG93bmVyIHJhdGhlciB0aGVuIHRoZSBjbGllbnQgdXNl cj8gSSB3b25kZXIgaWYgdGhhdCBpcyBjb3JyZWN0LiAgSWYgdGhlIGxhbmd1YWdlIHByZWZlcmVu Y2VzIGFyZSBpbiBmYWN0IGRpZmZlcmVudCwgd2hhdCB3b3VsZCB0aGUgdXNlciBvZiB0aGUgY2xp ZW50IGFwcCBleHBlY3Q/DQoNCi0tLS0+IGFueSBtdWx0aS1saW5ndWFsIHBlb3BsZSBoYXZlIGFu eSBvcGluaW9ucyBoZXJlPw0KDQpXaXRob3V0IHNwZWNpZmljIHByb3Bvc2VkIHRleHQgY2hhbmdl cyB0byByZXZpZXcsIGl04oCZcyBoYXJkIHRvIGtub3cgd2hhdCB0byB0aGluayBhYm91dCB0aGlz IGNvbW1lbnQuICBVbmxlc3MgYSBzcGVjaWZpYyBwcm9wb3NlZCB0ZXh0IGNoYW5nZSBpcyBzZW50 IHRvIHRoZSBsaXN0IHdpdGggY2xlYXIgcmF0aW9uYWxlIGZvciB3aHkgaXTigJlzIGJldHRlciB0 aGFuIHdoYXTigJlzIHRoZXJlIG5vdyBhbmQgcmV2aWV3ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAs IEkgZG9u4oCZdCBiZWxpZXZlIHdlIHNob3VsZCBjaGFuZ2UgdGhlIHNwZWNpZmljYXRpb24gaW4g cmVzcG9uc2UgdG8gdGhpcyBjb21tZW50Lg0KDQpTZWN0aW9uIDMNCg0KRXhpc3RpbmcgdGV4dDoN Cg0K4oCcSW4gb3JkZXIgdG8gc3VwcG9ydCBvcGVuIHJlZ2lzdHJhdGlvbiBhbmQgZmFjaWxpdGF0 ZSB3aWRlciBpbnRlcm9wZXJhYmlsaXR5LCB0aGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2lu dCBTSE9VTEQgYWxsb3cgaW5pdGlhbCByZWdpc3RyYXRpb24gcmVxdWVzdHMgd2l0aCBubyBhdXRo ZW50aWNhdGlvbi4gIFRoZXNlIHJlcXVlc3RzIE1BWSBiZSByYXRlLWxpbWl0ZWQgb3Igb3RoZXJ3 aXNlIGxpbWl0ZWQgdG8gcHJldmVudCBhIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFjayBvbiB0aGUg Q2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludC7igJ0NCg0KSSB3b3VsZCBzdWdnZXN0IHRvIGNo YW5nZSB0aGUgZmlyc3Qg4oCcU0hPVUxE4oCdIHRvIOKAnE1BWeKAnS4gICBJbiBtb3N0IGNsb3Vk IHNlcnZpY2VzLCB0aGUgZmlyc3QgY2xpZW50IGlzIHJlZ2lzdGVyZWQgYnkgYSBodW1hbiB1c2Vy LiBUaGVuLCBvdGhlciBjbGllbnRzIGNhbiBiZSBmdXJ0aGVyIHVzZWQgdG8gYXV0b21hdGUgb3Ro ZXIgY2xpZW50IHJlZ2lzdHJhdGlvbi4gIFNvLCB0aGUgZmlyc3QgcmVxdWVzdCB3b3VsZCB0eXBp Y2FsbHkgY29tZSB3aXRoIGFuIGF1dGhlbnRpY2F0ZWQgdXNlciBpZGVudGl0eS4NCg0KSSB0aGlu ayB0aGUgd2VpZ2h0IG9mICJTSE9VTEQiIGlzIGFwcHJvcHJpYXRlIGhlcmUsIGJlY2F1c2UgSSBi ZWxpZXZlIHRoYXQgdHVybmluZyBvZmYgb3BlbiByZWdpc3RyYXRpb24gYXQgdGhlIEFTICh3aGlj aCBpcyB3aGF0IHRoaXMgaXMgdGFsa2luZyBhYm91dCkgcmVhbGx5IG91Z2h0IHRvIGJlIHRoZSBl eGNlcHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUuDQoNCkkgdGhpbmsgeW91IGFyZSByZWFkaW5n IGl0IHdyb25nIC0tIGEgZG91YmxlLW5lZ2F0aXZlIGlzc3VlLiBUaGUgZW5kIG9mIHRoZSBzZW50 ZW5jZSBpcyAibm8gYXV0aGVudGljYXRpb24iLiAgWW91IGFyZSBpbXBseWluZyB0aGF0IE5PIEF1 dGhlbnRpY2F0aW9uIHVzIHdoYXQgc2hvdWxkIG5vcm1hbGx5IGJlIGRvbmUuIEkgdGhpbmsgeW91 IGludGVuZCBhbm9ueW1vdXMgYXV0aGVudGljYXRpb24gdG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRo ZXIgdGhhbiB0aGUgcnVsZSBkb24ndCB5b3U/DQoNCk5vLCBJIHRoaW5rIHRoYXQgYW5vbnltb3Vz IGF1dGhlbnRpY2F0aW9uIHNob3VsZCBiZSB0aGUgcnVsZS4gT3BlbiByZWdpc3RyYXRpb24gc2hv dWxkIGJlIGRlZmF1bHQuDQoNCkkgZGlzYWdyZWUuICBBZ2FpbiwgIHRoZSBzcGVjIHNlZW1zIGNv bnRyYWRpY3RvcnkuIEl0IHN1Z2dlc3RzIHN0cm9uZyBjbGllbnQgYXV0aCBtZXRob2RzIGFuZCBh dCB0aGUgc2FtZSB0aW1lIGFub255bW91cyByZWdpc3RyYXRpb24uICBZZXMgeW91IGdhaW4gdW5p cXVlbmVzcywgYnV0IHRoYXQncyBhYm91dCBpdC4NCg0KT24gdGhlIGZsaXAgc2lkZSwgdGhlIGVh cmxpZXIgcGFyYWdyYXBoOg0KDQrigJxUaGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludCBN QVkgYWNjZXB0IGFuIGluaXRpYWwgYXV0aG9yaXphdGlvbiBjcmVkZW50aWFsIGluIHRoZSBmb3Jt IG9mIGFuIE9BdXRoIDIuMCBbUkZDNjc0OV0gYWNjZXNzIHRva2VuIGluIG9yZGVyIHRvIGxpbWl0 IHJlZ2lzdHJhdGlvbiB0byBvbmx5IHByZXZpb3VzbHkgYXV0aG9yaXplZCBwYXJ0aWVzLiBUaGUg bWV0aG9kIGJ5IHdoaWNoIHRoaXMgYWNjZXNzIHRva2VuIGlzIG9idGFpbmVkIGJ5IHRoZSByZWdp c3RyYW50IGlzIGdlbmVyYWxseSBvdXQtb2YtYmFuZCBhbmQgaXMgb3V0IG9mIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbi7igJ0NCg0KSSB0ZW5kIHRvIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRl ciB0byBjaGFuZ2UgdGhpcyDigJxNQVnigJ0gdG8g4oCcU0hPVUxE4oCdLg0KDQpUaGF0IGFjY2Vz cyB0b2tlbiB3b3VsZCBjYXJyeSBhIGh1bWFuIHVzZXIgYXV0aGVudGljYXRlZCBpZGVudGl0eSBz b21laG93LiBJbiBzb21lIGNhc2VzLCBpdCBjYW4gYmUgYSBwdXJlIGF1dGhlbnRpY2F0ZWQgdXNl ciBhc3NlcnRpb24gdG9rZW4uDQoNCkFnYWluLCBkaXNhZ3JlZSwgZm9yIHRoZSBzYW1lIHJlYXNv bmluZyBhcyBhYm92ZS4NCg0KU2FtZSByZWFzb25pbmcuDQoNCg0KSSBhZ3JlZSB3aXRoIEp1c3Rp biBoZXJlLiAgVGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgb3BlbiByZWdpc3RyYXRpb25zIGFy ZSBlbmFibGVkLiAgVGhlIGV4Y2VwdGlvbiBjYXNlIGlzIHRoYXQgc3BlY2lmaWMgcGVybWlzc2lv bnMgYXJlIHJlcXVpcmVkIHRvIHBlcmZvcm0gZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uLg0K DQpBYm91dCBzZWN0aW9uIDQuMzoNCg0KDQpJZiB0aGUgY2xpZW50IGRvZXMgbm90IGV4aXN0IG9u IHRoaXMgc2VydmVyLCB0aGUgc2VydmVyIE1VU1QgcmVzcG9uZA0KDQogICB3aXRoIEhUVFAgNDAx IFVuYXV0aG9yaXplZCwgYW5kIHRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIHVzZWQgdG8N Cg0KICAgbWFrZSB0aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQuDQoN CklmIHRoZSBDbGllbnQgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzZXJ2ZXIsIHNob3VsZG4ndCBp dCByZXR1cm4gYSAiNDA0IE5vdCBGb3VuZCI/DQoNCklmIHJldm9raW5nIHRoZSByZWdpc3RyYXRp b24gYWNjZXNzIHRva2VuLCBpcyBpdCBib3VuZCB0byBhIHNpbmdsZSBjbGllbnQgcmVnaXN0cmF0 aW9uPyAgVGhpcyBpcyBub3QgY2xlYXIuICBXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9y bWF0aW9uIFJlc3BvbnNlIGluIHNlY3Rpb24gNS4xLg0KDQpUaGUgbGFuZ3VhZ2UgYWJvdXQgdGhl IDQwMSBoZXJlIChhbmQgaW4gb3RoZXIgbmVhcmJ5IHNlY3Rpb25zKSBpcyBzcGVjaWZpY2FsbHkg c28gdGhhdCB5b3UgdHJlYXQgYSBtaXNzaW5nIGNsaWVudCBhbmQgYSBiYWQgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbiB0aGUgc2FtZSB3YXkuIFlvdSBzZWUsIHJldHVybmluZyBhIDQwNCBoZXJl IGFjdHVhbGx5IGluZGljYXRlcyB0aGluZ3Mgd2VyZSBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGUu IE5hbWVseSwgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgc3RpbGwgdmFs aWQgYnV0IHRoZSBjbGllbnQgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMg YXR0YWNoZWQgdG8gZG9lc24ndCBleGlzdCBhbnltb3JlLiBUaGUgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiBpbiBtZWFudCB0byBiZSB0aWVkIHRvIGEgY2xpZW50J3MgaW5zdGFuY2UgKG9yIHJl Z2lzdHJhdGlvbiksIHNvIGl0J3MgYWN0dWFsbHkgbW9yZSBzZW5zaWJsZSB0byBhY3QgYXMgdGhv dWdoIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGlzbid0IHZhbGlkIGFueW1vcmUuIElu IGF0IGxlYXN0IHNvbWUgaW1wbGVtZW50YXRpb25zIChzcGVjaWZpY2FsbHkgb3VycyBhdCBNSVRS RSB0aGF0J3MgYnVpbHQgb24gU0VDT0FVVEggaW4gSmF2YSksIHlvdSdkIG5ldmVyIGJlIGFibGUg dG8gcmVhY2ggdGhlIDQwNCBzdGF0ZSBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0 aGUgaW5ib3VuZCB0b2tlbi4NCg0KU2luY2UgdGhlIGludGVudCBvZiB0aGUgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbiBpcyB0aGF0IGl0J3MgYm91bmQgdG8gYSBzaW5nbGUgaW5zdGFuY2UsIGl0 cyBsaWZlY3ljbGUgaXMgZ2VuZXJhbGx5IHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBiZWdpbnMgYXQg dGhlIGlzc3VhbmNlIG9mIGEgbmV3IGNsaWVudF9pZCB3aXRoIHRoYXQgaW5zdGFuY2UuIFRoYXQg dG9rZW4gbWlnaHQgYmUgcmV2b2tlZCBhbmQgYSBuZXcgb25lIGlzc3VlZCBvbiBSZWFkIGFuZCBV cGRhdGUgcmVxdWVzdHMgdG8gdGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50IChhbmQg dGhlIGNsaWVudCBuZWVkcyB0byBiZSBwcmVwYXJlZCBmb3IgdGhhdCAtLSBzYW1lIGFzIHRoZSBj bGllbnRfc2VjcmV0KSwgYW5kIGl0IHdpbGwgYmUgcmV2b2tlZCB3aGVuIHRoZSBjbGllbnQgaXMg ZGVsZXRlZCBlaXRoZXIgd2l0aCBhIERlbGV0ZSBjYWxsIHRvIHRoZSBDbGllbnQgQ29uZmlndXJh dGlvbiBFbmRwb2ludCBvciBzb21ldGhpbmcgaGFwcGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwg dGhlIGNsaWVudC4NCg0KU2hvdWxkIHdlIGFkZCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgdG8gdGhl IGRlZmluaXRpb24gaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdtIHZl cnkgb3BlbiB0byBjb25jcmV0ZSBzdWdnZXN0aW9ucyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9uJ3Qg dGhpbmsgaXQncyBhcyBjbGVhciBhcyB3ZSdkIGxpa2UuDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGxv b2sgYXQgaXQuDQoNCg0KRm9yIHNlY3VyaXR5IHJlYXNvbnMsIGl04oCZcyBnZW5lcmFsbHkgbm90 IGdvb2QgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiDigJxub3QgZm91bmTigJ0gYW5kIOKAnHVuYXV0 aG9yaXplZOKAnSBlcnJvcnMgaW4gcmVzcG9uc2VzLCBhcyB0aGF0IGNhbiBwcm92aWRlIHRoZSBh dHRhY2tlciBhbiBvcmFjbGUgdG8gcHJvYmUgd2hldGhlciBhIHBhcnRpY3VsYXIgZW50aXR5IGV4 aXN0cyAgSSBkb27igJl0IHRoaW5rIGEgY2hhbmdlIGlzIGNhbGxlZCBmb3IgaGVyZS4NCg0KQWJv dXQgc2VjdGlvbiA1LjE6DQpJcyByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIHVuaXF1ZT8gIE9y IGlzIGl0IHNoYXJlZCBieSBtdWx0aXBsZSBpbnN0YW5jZXM/ICAgSWYgc2hhcmVkLCB0aGVuIHJl Z2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gY2FuJ3QgYmUgcmV2b2tlZCBvbiBkZWxldGUgb2YgY2xp ZW50Lg0KDQpUaGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBpcyB1bmlxdWUgdG8gYSByZWdp c3RlcmVkIGNsaWVudCwgaW4gdGhlIFJGQyA2NzQ5IHNlbnNlIG9mIOKAnGNsaWVudOKAnS4gIEFn YWluLCBpZiB3ZSB3YW50IHRvIGRvIHdvcmsgb24g4oCcY2xpZW50IGluc3RhbmNlc+KAnSwgd2Ug bmVlZCB0byByZWNoYXJ0ZXIgYW5kIHRha2UgdGhpcyBkaXN0aW5jdCB3b3JrIGl0ZW0gdXAgZXhw bGljaXRseS4NCg0KU3VnZ2VzdCByZW5hbWUg4oCcZXhwaXJlc19hdOKAnSB0byDigJxjbGllbnRf c2VjcmV0X2V4cGlyZXNfYXTigJ0sDQoNClN1Z2dlc3QgdG8gcmVuYW1lIOKAnGlzc3VlZF9hdOKA nSB0byDigJxpZF9pc3N1ZWRfYXTigJ0NCg0KV2hpbGUgSSBkbyBsaWtlIHRoZSBzdWdnZXN0aW9u IG9mIGNoYW5naW5nIHRoZXNlIHRvIGNsaWVudF9zZWNyZXRfZXhwaXJlc19hdCBhbmQgY2xpZW50 X2lkX2lzc3VlZF9hdCwgYW5kIEkgdGhpbmsgdGhlc2UgYXJlIG1vcmUgY2xlYXIgYW5kIHJlYWRh YmxlLA0KDQoNCg0KSSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUgc3ludGF4IGR1cmluZyBsYXN0 IGNhbGwgdW5sZXNzIHRoZXJlIGlzIGEgY2xlYXIgbmVlZCBhbmQgYSBjbGVhciBjb25zZW5zdXMg Zm9yIGRvaW5nIHNvLg0KDQpUaGF0J3Mgd2h5IHdlIGFyZSBoYXZpbmcgbGFzdCBjYWxsLiBUbyBj b25maXJtIGNvbnNlbnN1cyBvbiB0aGUgZHJhZnQuDQoNClNhbWUgcmVhc29uaW5nIGFzIGVhcmxp ZXIuIFlvdSBub3cgaGF2ZSBtdWx0aXBsZSB0b2tlbnMgKHJlZ2lzdHJhdGlvbiBhY2Nlc3MgYW5k IGNsaWVudCkgaW4gcGxheS4gVGhlIHNwZWMgbmVlZHMgdG8gYmUgY2xlYXIgd2hpY2ggb25lIGl0 IGlzIHRhbGtpbmcgYWJvdXQuDQoNCkknbSBmaW5lIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2Ug YnV0IEkgd291bGQgbGlrZSBtb3JlIGZlZWRiYWNrIGZyb20gb3RoZXIgcGVvcGxlIGJlZm9yZSBt b3ZpbmcgZm9yd2FyZCB3aXRoIGl0LiBUaGVyZSdzIGEgbG90IG9mIHZhbHVlIGluICJqdXN0IHBp Y2sgYSBuYW1lIGFuZCBzaGlwIGl0IiBhcyB3ZWxsIHRob3VnaCwgYW5kIEkgZG9uJ3Qgd2FudCB0 byBkZXZvbHZlIGludG8gYmlrZSBzaGVkZGluZy4gKEknbSBub3QgYWNjdXNpbmcgeW91IG9mIGJp a2Ugc2hlZGRpbmcgcXVpdGUgeWV0LCBidHcsIGp1c3QgYWZyYWlkIG9mIGdldHRpbmcgaW50byBh IGxvbmcgZGViYXRlIG9uIG5hbWVzLikNCg0KQWdhaW4sIHRoaXMgd2FzIGEgcHJvYmxlbSByYWlz ZWQgYnkgcGVvcGxlIG5ldyB0byB0aGUgc3BlY2lmaWNhdGlvbi4gVGhleSBmb3VuZCBpdCBjb25m dXNpbmcuIEkgdGVuZCB0byBhZ3JlZS4gV2UncmUgbm90IHRhbGtpbmcgYWJvdXQgd2hhdCBjb2xv dXIgdG8gcGFpbnQgdGhlIHNoZWQuIFdlJ3JlIHRhbGtpbmcgYWJvdXQgd2hldGhlciB0aGUgYmlr ZSBzaGVkIGlzIGEgaG91c2UuICA6LSkNCg0KSSdtIG5vdCB0b28gZnVzc2VkIGFib3V0IHdoZXRo ZXIgeW91IGNhbGwgaXQgImNsX3NlY19leHBpcnkiIG9yICJjbGllbnRfc2VjcmV0X2V4cGlyZXNf YXQiLg0KDQoNCklmIHRoZSBkZWZpbml0aW9ucyBvZiDigJxleHBpcmVzX2F04oCdIG9yIOKAnGlz c3VlZF9hdOKAnSBhcmUgdW5jbGVhciwgd2Ugc2hvdWxkIGNsYXJpZnkgdGhlbS4gIElmIHlvdSBi ZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBQaGlsLCBjYW4geW91IHN1cHBseSBwcm9wb3Nl ZCBhbHRlcm5hdGl2ZSBkZWZpbml0aW9uIHRleHQgdGhhdCBpcyBjbGVhcmVyPyAgVGhhdCBiZWlu ZyBzYWlkLCBJIGJlbGlldmUgdGhhdCBhdCB0aGlzIHBvaW50IHdlIHNob3VsZCBzdGljayB3aXRo IHRoZSBleGlzdGluZyBwcm90b2NvbCBlbGVtZW50IG5hbWVzIHVubGVzcyBvdmVyd2hlbG1pbmcg d29ya2luZyBncm91cCBzZW50aW1lbnQgZW1lcmdlcyB0byBjaGFuZ2UgdGhlbS4gIFRoZXkgYXJl IGFscmVhZHkgd29ya2luZyBmaW5lIGFzLWlzIGluIHByb2R1Y3Rpb24gZGVwbG95bWVudHMuDQoN ClNlY3Rpb24gNw0KDQpXaGVuIGEgY2xpZW50X3NlY3JldCBleHBpcmVzIGlzIGl0IHRoZSBpbnRl bnQgdGhhdCBjbGllbnRzIGRvIGFuIHVwZGF0ZSBvciByZWZyZXNoIHRvIGdldCBhIG5ldyBjbGll bnQgc2VjcmV0Pw0KDQpZZXMsIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gZWl0aGVyIGNhbGwg dGhlIHJlYWQgb3IgdXBkYXRlIG1ldGhvZHMgb24gdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGVu ZHBvaW50IHRvIGdldCBpdHMgbmV3IHNlY3JldC4gQXMgZGlzY3Vzc2VkIGFib3ZlLCBJJ20gbm90 IHN1cmUgdGhhdCdzIGFzIGNsZWFyIGFzIGl0IG5lZWRzIHRvIGJlLCBhbmQgSSB3ZWxjb21lIHN1 Z2dlc3Rpb25zIG9uIGhvdyB0byBjbGFyaWZ5IHRoaXMuDQoNCkVpdGhlciBpcyBhIHJlYXNvbmFi bGUgYmVoYXZpb3Igb24gdGhlIGJlaGFsZiBvZiBjbGllbnRzLCBkZXBlbmRpbmcgdXBvbiBjb250 ZXh0LiAgSSBzdXBwb3J0IGFkZGluZyB0ZXh0IHRvIGNsYXJpZnkgdGhpcy4NCg0KQWdhaW4sIHRo YW5rcyBmb3IgdGhlIHZlcnkgdGhvcm91Z2ggcmVhZCB0aHJvdWdoLiBIYXZlIHlvdSBpbXBsZW1l bnRlZCBhbnkgb2YgdGhlIHNwZWMgeWV0LCBlaXRoZXIgYXMtaXMgb3Igd2l0aCBhbnkgb2YgeW91 ciBzdWdnZXN0ZWQgY2hhbmdlcz8NCg0KWWVzLiBNdWNoIG9mIHRoZSBmZWVkYmFjayBpcyBjb21p bmcgZnJvbSBvdXIgZGV2ZWxvcG1lbnQgY29tbXVuaXR5Lg0KDQpBaCwgdmVyeSBjb29sLiBEZXZl bG9wZXIgZXhwZXJpZW5jZSBpcyB0aGUgbW9zdCB2YWx1YWJsZSBmZWVkYmFjaywgaW4gbXkgb3Bp bmlvbi4gSWYgeW91IGNhbid0IGFjdHVhbGx5IGJ1aWxkIHRoZSBibGFzdGVkIHRoaW5nLCB3aGF0 IGdvb2QgaXMgaXQ/IDopDQoNCkdsYWQgdG8gaGVhciB0aGF0IHlvdeKAmXJlIHdvcmtpbmcgd2l0 aCBkZXZlbG9wZXJzIGJ1aWxkaW5nIHRoZSBzcGVjLiAgUGxlYXNlIHRoYW5rIHRoZW0gZm9yIHRo ZSBmZWVkYmFjay4NCg0KIC0tIEp1c3Rpbg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0K --_000_4E1F6AAD24975D4BA5B168042967394367734CE0TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDEx IDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0K c3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVy dGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIER5bmFtaWMg Q2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjIGV4aXN0cyB0byBlbmFibGUgdGhlIGRldmVsb3BlciBv ZiBhIHBpZWNlIG9mIGNvZGUgdG8gcmVnaXN0ZXIgdGhhdCBjb2RlIHdpdGggYW4gQXV0aG9yaXph dGlvbiBTZXJ2ZXIgdG8gb2J0YWluIGEgY2xpZW50X2lkDQogKGFuZCBzb21ldGltZXMgY2xpZW50 X3NlY3JldCkgc28gdGhhdCB0aGUgY29kZSBjYW4gbWFrZSBhdXRob3JpemF0aW9uIHJlcXVlc3Rz IHRvIHRoYXQgQVMuJm5ic3A7IEl0IGVuYWJsZXMgT0F1dGggY2xpZW50IHJlZ2lzdHJhdGlvbnMg dG8gdXNlIHN0YW5kYXJkIHByb3RvY29sIGludGVyYWN0aW9ucywgcmF0aGVyIHRoYW4gYWx3YXlz IHVzaW5nIGN1c3RvbSBwcm9jZWR1cmVzIGF0IGV2ZXJ5IEFTLiZuYnNwOyBUaGF0IHNlZW1zIHBy ZXR0eSB2YWx1YWJsZSB0bw0KIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgeW91IHNlZSBubyB2YWx1ZSBpbiBo YXZpbmcgY2xpZW50cyBhbm9ueW1vdXNseSByZWdpc3RlcmluZyB3aXRoIEF1dGhvcml6YXRpb24g U2VydmVycyB0byBvYnRhaW4gY2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0IHZhbHVlcywgdGhl biB0aGF0IGltcGxpZXMgdGhhdA0KIHlvdSBzZWUgbm8gdmFsdWUgaW4gb3BlbiBpZGVudGl0eSBp bnRlcmFjdGlvbnMgaW4gd2hpY2ggUmVseWluZyBQYXJ0aWVzIHRoYXQgaGF2ZSBub3QgcHJldmlv dXNseSB1c2VkIGFuIElkZW50aXR5IFByb3ZpZGVyIGNhbiBkeW5hbWljYWxseSBjb25uZWN0IHRv IHRoYXQgcHJvdmlkZXIgYW5kIHVzZSBhc3NlcnRpb25zIGlzc3VlZCBieSB0aGF0IHByb3ZpZGVy LiAmbmJzcDtZZXQgSSBkb3VidCB0aGF0IHRoYXQgeW91IHJlYWxseSBiZWxpZXZlIHRoYXQuJm5i c3A7DQogSWYgcnAuZXhhbXBsZS5jb20gaGFzbuKAmXQgdXNlZCBpZHAuZXhhbXBsZS5uZXQgYmVm b3JlIGFuZCBNYXJ5IHdhbnRzIHRvIHVzZSBoZXIgbWFyeUBpZHAuZXhhbXBsZS5uZXQgaWRlbnRp dHkgdG8gc2lnbiBpbnRvIHJwLmV4YW1wbGUuY29tLCB0aGlzIGlzIGV4YWN0bHkgd2hhdOKAmXMg bmVlZGVkLiZuYnNwOyBNYXliZSB5b3Ugd2FudCB0byByZXZpc2UgeW91ciBzdGF0ZW1lbnQgYWJv dXQg4oCcc2VlaW5nIG5vIHZhbHVl4oCdIHRvIHNvbWV0aGluZyBtb3JlIHByYWdtYXRpYw0KIGxp a2Ug4oCcSSBmb3Jlc2VlIGNpcmN1bXN0YW5jZXMgaW4gd2hpY2ggaXQgd291bGQgYmUgdmFsdWFi bGUgdG8gbWFuYWdlIGluc3RhbmNlcyBvZiBhbiBPQXV0aCBjbGllbnQu4oCdPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBkb27igJl0IHNlZSB5b3VyIHN0YXRlbWVudCBhYm91dCDigJw8L3NwYW4+dGhlIG5ldyBkcmFm dCB0aGF0IGRvZXMgc29sdmUgaXQgd291bGQgbGlrZWx5IGJlIDk1JSBvdmVybGFwPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnQ0KIGFzIGEgbmVnYXRpdmUg4oCT IHJhdGhlciwgSSBzZWUgaXQgYXMgeW91IHNheWluZyB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IGFs cmVhZHkgcHJvdmlkZXMgOTUlIG9mIHRoZSBmdW5jdGlvbmFsaXR5IG5lZWRlZCBmb3IgcmVnaXN0 cmF0aW9uIG9mIGNsaWVudCBpbnN0YW5jZXMuJm5ic3A7IFRoZSBtZXRhZGF0YSBmaWVsZCBzZXQg aXMgaW50ZW50aW9uYWxseSBleHRlbnNpYmxlLiZuYnNwOyBSYXRoZXIgdGhhbiBkdXBsaWNhdGlu ZyB0aGUgOTUlLCBJIHN1c3BlY3QgdGhhdA0KIHRoZSBuZXcgZHJhZnQgdGhhdCB5b3UgZW52aXNp b24gd291bGQgYWN0dWFsbHkganVzdCBkZWZpbmUgZXh0ZW5zaW9ucyBmb3IgdGhlIGFkZGl0aW9u YWwgNSUgZnVuY3Rpb25hbGl0eSBuZWVkZWQgZm9yIHRoYXQgdXNlIGNhc2UsIGFuZCB1c2UgdGhl IGV4aXN0aW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E byB5b3UgaGF2ZSBhIGNvbmNyZXRlIHByb3Bvc2FsIGZvciB3aGF0IHRoZSBhZGRpdGlvbmFsIDUl IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlPyZuYnNwOyBXaXRob3V0IHVuZGVyc3RhbmRpbmcgd2hh dCBuZXcgb2JqZWN0cyBhbmQgb3BlcmF0aW9ucyB0aGF0IHlvdSBiZWxpZXZlDQogd2Ugd291bGQg d2FudCB0byBoYXZlIGZvciB0aGlzIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSwgdGhlIGRpc2N1 c3Npb25zIHdpbGwgcmVtYWluIGF0IGEgaHlwb3RoZXRpY2FsIHBsYW5lLCBhdCBiZXN0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhbHNvIGJlbGlldmUgdGhhdCB3aGF0IHlvdSB3YW50IHVzIHRvIHdvcmsgb24gaXMg cmVhbGx5IE9BdXRoIENsaWVudCBJbnN0YW5jZSBNYW5hZ2VtZW50IGZ1bmN0aW9uYWxpdHkg4oCT IG9mIHdoaWNoIHJlZ2lzdHJhdGlvbiBpcyBvbmx5IG9uZSBwYXJ0LiZuYnNwOyBJ4oCZZCByZWFs bHkNCiBsaWtlIHRvIHNlZSBhIGNvbmNyZXRlIHByb3Bvc2FsIGFsbC11cCDigJMgcHJlZmVyYWJs eSBhcyBhbiBJbnRlcm5ldCBEcmFmdCDigJMgYmVmb3JlIHdlIGV2ZW4gY29uc2lkZXIgZG9pbmcg dGhlIHJlZ2lzdHJhdGlvbiBwaWVjZSBvZiBpdC4mbmJzcDsgT3RoZXJ3aXNlIHdl4oCZcmUgY2Vy dGFpbiB0byBtaXNzIHRoaW5ncyBhbmQgZ2V0IGl0IHdyb25nIGlmIHdlIGF0dGVtcHQgdGhpcyBv biBhIHBpZWNlbWVhbCBiYXNpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFnYWluLCBJ4oCZbSBub3QgZGViYXRpbmcg dGhhdCBjbGllbnQgaW5zdGFuY2UgbWFuYWdlbWVudCBjb3VsZCBiZSB2YWx1YWJsZSBpbiBzb21l IHVzZSBjYXNlcy4mbmJzcDsgSW4gZmFjdCwgSeKAmW0gc3VyZSB0aGF0IHRoYXTigJlzIHRoZSBj YXNlLiZuYnNwOyBCdXQgSSBiZWxpZXZlIHRoYXQgdGhpcw0KIGlzIGEgc2lnbmlmaWNhbnQgZW5v dWdoIHdvcmsgaXRlbSB0aGF0IGl0IHNob3VsZCBoYXZlIGl0cyBvd24gZHJhZnQocykgYW5kIGJl IGRlYmF0ZWQgb24gaXRzIG93biBtZXJpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaG91bGRu4oCZdCBob2xk IHVwIHRoZSBleGlzdGluZyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3BlYyBmb3IgdGhp cyBub3Qtd3JpdHRlbi1kb3duIGFuZCBzcGVjdWxhdGl2ZSBmdW5jdGlvbmFsaXR5IHdoZW4gaXTi gJlzIGFscmVhZHkgYmVlbiBkZW1vbnN0cmF0ZWQNCiB0byB3b3JrIHdlbGwgZm9yIGR5bmFtaWNh bGx5IHJlZ2lzdGVyaW5nIGNsaWVudHMsIHdoZXJlIHRoZSBjbGllbnRzIGFyZSBhcyBkZWZpbmVk IGluIFJGQyA2NzQ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg TWF5IDE3LCAyMDEzIDI6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnIFdHPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gQ2xpZW50IEluc3RhbmNlcyBvZiBBbiBBcHBs aWNhdGlvbiAtIFdhczogUmU6IExhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1k eW4tcmVnLTEwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWlrZSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhdGhl ciB0aGVuIGVtYmVkIGNvbW1lbnRzIGluIGFuIGV4dGVuZGVkIHRocmVhZCwgSSdkIGxpa2UgdG8g b3BlbiB1cCBhIHNwZWNpZmljIGRpc2N1c3Npb24gb24gdGhlIG9iamVjdGl2ZSBvZiBkeW4gcmVn LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHNlZSBsaW1pdGVkIHRvIG5vIHZhbHVlIGluIGhhdmluZyBjbGllbnRzIGNvbXBsZXRlbHkgYW5v bnltb3VzbHkgcmVnaXN0ZXJpbmcgYW5kIHJlY2VpdmluZyB0b2tlbnMgd2l0aG91dCBhbnkgYWJp bGl0eSB0byBjb3JyZWxhdGUgYXBwbGljYXRpb25zIGJldHdlZW4gYXBwbGljYXRpb25zLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B c3NvY2lhdGluZyBjbGllbnRfaWQncyB3aXRoIGtub3duIGNsaWVudCBhcHBsaWNhdGlvbnMgdG8g YWxsb3cgYWRtaW5zIHRvIGtub3cgd2hvIGlzIHJ1bm5pbmcgd2hhdCB2ZXJzaW9uIG9mIGNsaWVu dHMgc2VlbXMgdG8gYmUgdGhlIG1vc3QgZnVuZGFtZW50YWwgcGFydCBvZiB0aGUgcmVhc29uIGZv ciBkeW5hbWljIHJlZy4gSG93IGNhbiB5b3UgcmV2b2tlIGFjY2VzcyB0byBwYXJ0aWN1bGFyIGNs aWVudCBhcHANCiB0eXBlcz8gJm5ic3A7QXMgSnVzdGluIGFscmVhZHkgdGFsa2VkIGFib3V0IGlu IGhpcyBCbHVlIEJ1dHRvbiYjNDM7IHNjZW5hcmlvLCB0aGVyZSBhcmUgb2Z0ZW4gbGlmZSBhbmQg ZGVhdGggc2l0dWF0aW9ucyB3aGVyZSBwYXJ0aWN1bGFyIHNldHMgb2YgY2xpZW50cyBuZWVkIHRv IGJlIHJldm9rZWQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PciBwdXQgYW5vdGhlciB3YXkuIEkgYmVsaWV2ZSB0aGlzIHdpbGwg YmUgYSBjcml0aWNhbCBvcGVyYXRpb25hbCByZXF1aXJlbWVudCBnb2luZyBmb3J3YXJkcy4gSWYg dGhlIHNwZWMgaXMgcHVibGlzaGVkIGFzIGlzLCBpdCB3aWxsIGJlIHF1aWNrbHkgaW52YWxpZGF0 ZWQgYnkgb25lIHRoYXQgZG9lcyBhdCBsZWFzdCBwYXJ0aWFsbHkgYWRkcmVzcyB0aGUgcHJvYmxl bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2UncmUgYWhlYWQgb2Ygc2NoZWR1bGUsIGxldHMgdGFsayB0aHJvdWdoIHRoZSByZXF1aXJlbWVu dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXMgSSBtZW50aW9uZWQgaW4gbXkgY29tbWVudHMgdG8gdGhlIG90aGVyIHRocmVhZC4gTGV0J3Mg c2F5IHdlIGFncmVlIG5vdCBkbyB0aGlzIG5vdy4gV2VsbCwgdGhlbiB0aGUgbmV3IGRyYWZ0IHRo YXQgZG9lcyBzb2x2ZSBpdCB3b3VsZCBsaWtlbHkgYmUgOTUlIG92ZXJsYXAuICZuYnNwO1RodXMg SSBzZWUgdGhpcyBpc3N1ZSBhcyB3aXRoaW4gY2hhcnRlciBhbmQgc2hvdWxkIGJlIHNvbHZlZCBu b3cgcmF0aGVyIHRoZW4NCiB3YWl0aW5nIGZvciBhIFYyIGR5biByZWcgaW4gdGhlIG5leHQgY2hh cnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRl cGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxMy0wNS0xNywgYXQgMTow OCBQTSwgTWlrZSBKb25lcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGFua3MgZm9yIHRoZSBkZXRhaWxlZCBmZWVkYmFjaywgUGhpbC4mbmJzcDsgU29ycnkg Zm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlIOKAkyBJIHdhcyBwcmV0dHkgZnVsbHkgZW5nYWdlZCBh dCB0aGUgRXVyb3BlYW4gSWRlbnRpdHkgQ29uZmVyZW5jZSAod2hlcmU8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNz dWVkLmluZm8vP3A9MTAyNiI+T0F1dGgNCiAyLjAgd29uIHRoZSBhd2FyZCBmb3IgYmVzdCBuZXcg c3RhbmRhcmQ8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+KS4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDBCMDUwIj5NeQ0KIGZlZWRiYWNrIG9uIHRoZSBwb2ludHMgcmFpc2VkIGlzIGlubGluZSBpbiBn cmVlbuKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KFBlcmhhcHMg aWYgYW55IG9mIHlvdSByZXBseSB0byB0aGlzIHRocmVhZCwgeW91IGNvdWxkIGFsc28gY2hvb3Nl IGEgZGlzdGluY3Q8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPmNvbG9yPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Zm9yDQogeW91ciBpbmxpbmUg cmVwbGllcywgc28gdGhhdCBpdCB3aWxsIGJlIGVhc2lseSBldmlkZW50IHdobyBzYWlkIHdoYXQu Jm5ic3A7IEFzIGl0IGlzLCBqdXN0IHRoZSBiYWNrLWFuZC1mb3J0aCBiZXR3ZWVuIFBoaWwgYW5k IEp1c3RpbiBpcyBhbHJlYWR5IHZlcnkgZGlmZmljdWx0IHRvIGZvbGxvdy4mbmJzcDsgVGhhbmtz Lik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW47Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxm IE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Q aGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIE1heSAxNiwgMjAxMyAxMjo1NCBQTTxicj4NCjxi PlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmljaGVyLCBKdXN0aW4gUC48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ b2F1dGhAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPldHPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgtV0ddIExhc3QgY2FsbCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0aW4sPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24uIE1vcmUgY29tbWVudHMgYmVsb3cuLi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFcuIEknbSBoYXBweSB0byBjb250cmlidXRlIHRleHQuIEp1 c3Qgd2FudCB0byBnZXQgdG8gc29tZSByb3VnaCBhZ3JlZW1lbnQgZmlyc3QuICZuYnNwO0ZvciBl eGFtcGxlLCBJIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBhIGF3YXkgdG8gcmVjb2duaXplIHR3byBw aWVjZXMgb2Ygc29mdHdhcmUgYXMgYmVpbmcgdGhlIHNhbWUgKGV2ZW4gaWYgc2VsZi1hc3NlcnRl ZCkuICZuYnNwO09uY2UgZGVmaW5lZCwgSSBjYW4gcHV0IHRvZ2V0aGVyDQogc29tZSBpbnRybyB0 ZXh0LCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+d3d3LmluZGVw ZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTMtMDUt MTYsIGF0IDU6MTYgQU0sIFJpY2hlciwgSnVzdGluIFAuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTWF5IDE1LCAyMDEzLCBhdCAxMDozMCBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDt3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiAyMDEzLTA1LTE1LCBhdCA1OjUzIFBNLCBSaWNoZXIsIEp1c3Rp biBQLiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QaGlsLCBtYW55IHRoYW5rcyBmb3IgdGhlIGV4dHJlbWVseSB0aG9y b3VnaCByZXZpZXchIEl0IGlzIHZlcnkgdXNlZnVsIGluZGVlZC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TXkgY29tbWVudHMgYW5kIHJlc3BvbnNlcyB0byBlYWNoIHBvaW50IGFyZSBpbmxpbmUuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTWF5IDE1LCAyMDEzLCBhdCA0OjMwIFBNLCBQaGlsIEh1bnQgJmx0Ozxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIHVuZm9ydHVuYXRlIHRo YXQgSSBoYXZlIG5vdCBnb3R0ZW4gYSBjaGFuY2UgdG8gZ2V0IGludG8gdGhpcyBsZXZlbCBvZiBk ZXRhaWwgbXVjaCBlYXJsaWVyLiBCdXQgdGhlbiwgSSBndWVzcyB0aGF0J3Mgd2hhdCBMQyByZXZp ZXcgaXMgZm9yISBNeSBhcG9sb2dpZXMgZm9yIG5vdCBnZXR0aW5nIG1hbnkgb2YgdGhlc2UgY29u Y2VybnMgdG8gdGhlIFdHIG11Y2ggZWFybGllci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPk92ZXJhbGwgJm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgZHluYW1pYyByZWdpc3RyYXRpb24gaXMgYSBjcml0aWNhbCBwYXJ0IG9mIHRoZSBPQXV0 aCBmcmFtZXdvcmsgbm93IHRoYXQgd2UgYXJlIHN0YXJ0aW5nIHRvIGNvbnNpZGVyIGhvdyBpbmRp dmlkdWFsIGNsaWVudCBhcHBsaWNhdGlvbnMgc2hvdWxkIG9wZXJhdGUgd2hlbiB0aGVyZSBpcyBv bmUgb3IgbW9yZSBkZXBsb3ltZW50cyBvZiBhIHBhcnRpY3VsYXIgcmVzb3VyY2UgQVBJLiBXZSd2 ZSBtb3ZlZA0KIGZyb20gdGhlIHNpbXBsZSB1c2UgY2FzZSBvZiBhIHNpbmdsZSBBUEkgcHJvdmlk ZXIgbGlrZSBGYWNlYm9vayBvciBGbGlja3IgYW5kIG1vdmVkIG9uIHRvIHN0YW5kYXJkcyBiYXNl ZCwgb3BlbiBzb3VyY2UgYmFzZWQsIGFuZCBjb21tZXJjaWFsIGJhc2VkIGRlcGxveW1lbnRzIHdo ZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBzZXJ2aWNlIGVuZHBvaW50cyBhbmQgbWFueSBjbGllbnRz IHRvIG1hbmFnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHluYW1pYyByZWdpc3RyYXRpb24g c3BlYyBpcyBhY3R1YWxseSBkZWFsaW5nIHdpdGggYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSB3 b3VsZCBsaWtlIHRvIHNlZSBtYWRlIG1vcmUgY2xlYXIgaW4gZWFybHkgcGFydCBvZiB0aGUgc3Bl Yzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiAmbmJzcDtIb3cgaXMgYSBuZXcgY2xpZW50IGFwcGxp Y2F0aW9uIHJlY29nbml6ZWQgZm9yIHRoZSBmaXJzdCB0aW1lIHdoZW4gZGVwbG95ZWQgYWdhaW5z dCBhIHBhcnRpY3VsYXIgU1AgZW5kcG9pbnQ/ICZuYnNwO1Nob3VsZCBjbGllbnRzIGFjdHVhbGx5 IGFzc2VydCBhbiBhcHBsaWNhdGlvbl9pZCBVVUlEIHRoYXQgbmV2ZXIgY2hhbmdlcyBhbmQgcG9z c2libHkgYSB2ZXJzaW9uIGlkIHRoYXQgZG9lcyBjaGFuZ2Ugd2l0aA0KIHZlcnNpb25zPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGdlbmVyYWwgY2FzZSwgd2h5IGlzIGFueSBy ZWNvZ25pdGlvbiByZXF1aXJlZD8gSWYgeW91J3JlIGRvaW5nIHRoaW5ncyBhcyBwYXJ0IG9mIGEg bGFyZ2VyIHByb3RvY29sIGVjb3N5c3RlbSwgbGlrZSBCbHVlIEJ1dHRvbiYjNDM7IG9yIGEgcGFy dGljdWxhciBPcGVuSUQgQ29ubmVjdCBwcm92aWRlciwgdGhlbiB5b3UgY2FuIGRlZmluZSBzZW1h bnRpY3MgZm9yIHR5aW5nIHRvZ2V0aGVyIGNsYXNzZXMgb2YNCiBjbGllbnRzIChzZWUgYmVsb3cg Zm9yIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlzIHZlcnkgcG9pbnQpLiBCdXQgaW4gZ2VuZXJhbCwg YSBjbGllbnQgaXMganVzdCBnb2luZyB0byBzaG93IHVwIGFzIGEgbmV3IGluc3RhbmNlIHRvIHRo ZSBBUyBhbmQgZ2V0IGlzc3VlZCBhIG5ldywgdW5pcXVlIGNsaWVudF9pZCwgYW5kIHRoYXQncyB0 aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHdlIGhhdmUgdG8gZGVmaW5lIG1vcmUgY2xlYXJseSB3aGF0IGFuICZxdW90O2luc3Rh bmNlJnF1b3Q7IGlzLiBGb3IgbWUsIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgYW5kIHRoZXJlIGFy ZSBpbnN0YW5jZXMgb2YgdGhhdCBhcHBsaWNhdGlvbi4gJm5ic3A7SXQgaXMgdXNlZnVsIHRvIHVu ZGVyc3RhbmQgdGhhdCBhIGNsaWVudCBhcHBsaWNhdGlvbiByZXByZXNlbnRzIGEgc2V0IG9mIGNv ZGUgdGhhdCBzaG91bGQgYmVoYXZlDQogaW4gYSBjb25zaXN0ZW50IHdheS4gJm5ic3A7SXQgc2Vl bXMgdG8gbWUgdGhlIGZpcnN0IHRpbWUgYSBuZXcgYXBwbGljYXRpb24gc2hvd3MgdXAgaXMgdmVy eSBkaWZmZXJlbnQgZnJvbSB0aGUgc3Vic2VxdWVudCBpbnN0YW5jZXMgdGhhdCByZWdpc3Rlci4g Rm9yIGV4YW1wbGUsIGFmdGVyIHRoZSBmaXJzdCByZWdpc3RyYXRpb24sIHN1YnNlcXVlbnQgaW5z dGFuY2VzIGRvbid0IG5lZWQgc3BlY2lhbCByZXZpZXcgb3IgYXBwcm92YWwgdG8gdGhlIHNhbWUN CiBkZWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB3aXRob3V0 IG90aGVyIG1lY2hhbmlzbXMgdG8gdGllIHRoaW5ncyB0b2dldGhlciwgdGhlcmUncyBubyB3YXkg Zm9yIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGtub3cgaWYgYW55IGNsaWVudCBpbnN0YW5j ZSBpcyB0aWVkIHRvIGFueSBvdGhlciBjbGllbnQgaW5zdGFuY2UuIFRoZXJlZm9yZSwgZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgYW4gQVMsIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiBhbiBhcHBsaWNh dGlvbg0KIChpLmUuLCBwYXJ0aWN1bGFyIGNvbmZpZ3VyYXRpb24gb2YgYSBzZXQgb2YgY29kZSkg dG8gcmVnaXN0ZXIgaXMgbm8gZGlmZmVyZW50IHRvIHN1YnNlcXVlbnQgaW5zdGFuY2VzIG9mIHRo YXQgc2FtZSBhcHBsaWNhdGlvbi4gSG93IHdlcmUgeW91IGVudmlzaW9uaW5nIGFuIEFTIGtub3dp bmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZmlyc3QgYW5kIHN1YnNlcXVlbnQgaW5zdGFu Y2VzIG9mIGFuIGFwcGxpY2F0aW9uLCBzcGVjaWZpY2FsbHk/DQogSWYgdGhlcmUncyBhbiAmcXVv dDthcHBsaWNhdGlvbl9pZCZxdW90OyBsaWtlIHlvdSBtZW50aW9uIGFib3ZlLCBJIHRoaW5rIGl0 IHJhaXNlcyBtb3JlIHF1ZXN0aW9ucyB0aGFuIGl0IHJlc29sdmVzOiBXaG8gaXNzdWVzIHRoZSBh cHBsaWNhdGlvbl9pZCwgc29tZSBzZXJ2ZXIgb3IgdGhlIGFwcGxpY2F0aW9uIGl0c2VsZj8gSXMg aXQgdmFsaWRhdGVkIGF0IGFsbD8gU2hvdWxkIGl0IGJlIGNvbnNpZGVyZWQgc2VjcmV0PyBXaGF0 IGhhcHBlbnMgd2hlbiBzb21lb25lDQogc2ltcGx5IHN0ZWFscyBhbiBhcHBsaWNhdGlvbl9pZD8g RG9lcyBhbiBBUyBoYXZlIHRvIGRvIGFueXRoaW5nIHRvIGNoZWNrIHdpdGggYW55IG90aGVyIEFT IHRvIHNlZSBpZiB0aGUgYXBwbGljYXRpb25faWQgaGFzIGFscmVhZHkgYmVlbiB1c2VkIGVsc2V3 aGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIGFncmVlIHRoYXQgYSBkaXNjdXNzaW9uIG9m ICZxdW90O2luc3RhbmNlIHZzLiBhcHBsaWNhdGlvbiZxdW90OyB3b3VsZCBiZSBoZWxwZnVsIGlu IGNsZWFyaW5nIHRoaXMgdXAsIEknbGwgbWFrZSBhIG5vdGUgdG8gYWRkIHRleHQgdG8gdGhhdCBl ZmZlY3QuIChXZSBoYWQgdG8gZG8gc29tZXRoaW5nIHNpbWlsYXIgZm9yIEJCJiM0MzspPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgc2ltcGxlIGVub3Vn aCB0byBhdCBsZWFzdCBhZGQgYSBzZWxmIGdlbmVyYXRlZCBVVUlEIGZvciB0aGUgYXBwbGljYXRp b24gSUQuICZuYnNwO1Rob3VnaCBJIHdvdWxkIGFsbG93IGZvciBjYXNlcyB3aGVyZSB0aGUgYXBw bGljYXRpb24gSUQgaXMgYXNzaWduZWQgd2hlbiB0aGUgY2xpZW50IGRldmVsb3BlciBhbmQgdGhl IEFQSXMgb3duZXIgZG8gYSBmb3JtYWwgYXNzaWdubWVudCBvZiBhcHBsaWNhdGlvbg0KIElEcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhIHNlbnNlIHRoaXMgaXMganVzdCBhIGxvd2VyIHRlY2gg d2F5IG9mIGRvaW5nIGl0IHRoYW4gd2hhdCB5b3UgZGVzY3JpYmVkIGFzIHRoZSBpbml0aWFsIGNs aWVudCBjcmVkZW50aWFsIGluIEJsdWUgQnV0dG9uJiM0Mzsgd2hlcmUgeW91IGVuY29kZWQgZXh0 cmEgY2xhaW1zIGludG8gdGhlIGluaXRpYWwgYXBwIGNyZWRlbnRpYWwuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCB0aGUgVVVJRCBkb2VzIGlzIGxpbmsgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGEg Y2xpZW50IGFwcCB0b2dldGhlciBhcyB0aGUgc2FtZSAmcXVvdDt0aGluZyZxdW90OyB0aGF0IHNo b3VsZCBoYXZlIHNpbWlsYXIgaGV1cmlzdGljcy9iZWhhdmlvdXJzLiAmbmJzcDtUaGlzIGlzIHZl cnkgdXNlZnVsIGlmIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gcmV2b2tlIGFjY2VzcyB0byBhIHNl dCBvZiBjbGllbnRzIGlkZW50aWZpZWQgYnkgYXBwbGljYXRpb24NCiBpZCAob3IgYSB2ZXJzaW9u IG9mIHRoYXQgYXBwKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+V2hpbGUgSeKA mW0gc3ltcGF0aGV0aWMgdG8gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgZXZlbnR1YWxseSBkb2lu ZyB3b3JrIG9uIGRpZmZlcmVudGlhdGluZyBiZXR3ZWVuIGluc3RhbmNlcyBvZiBhbiBPQXV0aCBj bGllbnQsIEnigJlsbCBub3RlIHRoYXQgaW4gUkZDIDY3NDkgb3INCiBSRkMgNjc1MCB0aGVyZSBp cyBubyBzdWNoIHRoaW5nIGFzIGEgY2xpZW50IGluc3RhbmNlLiZuYnNwOyBUaGVyZSBhcmUgb25s eSBjbGllbnRzLCB3aGljaCBhcmUgaWRlbnRpZmllZCBieSBjbGllbnRfaWQgdmFsdWVzLiZuYnNw OyBJZiB3ZSB3YW50IHRvIGRvIHdvcmsgb24gY2xpZW50IGluc3RhbmNlcywgd2Ugc2hvdWxkIHJl Y2hhcnRlciB0byBhZGQgdGhpcyBuZXcgd29yayBhcyBhIHdvcmtpbmcgZ3JvdXAgZGVsaXZlcmFi bGUuJm5ic3A7IFdlIHNob3VsZCBub3QgdHJ5DQogdG8gc2hvZWhvcm4gYml0cyBhbmQgcGllY2Vz IG9mIGl0IGludG8gdGhlIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNwZWMsIGFueSBtb3JlIHRoYW4g d2Ugc2hvdWxkIGhhdmUgdHJpZWQgdG8gc2hvZWhvcm4gaXQgaW50byBSRkMgNjc0OSBvciBSRkMg Njc1MC4mbmJzcDsgT2F1dGgtZHluLXJlZyBpcyB0aGVyZSB0byByZWdpc3RlciBjbGllbnRzIGFz IGRlZmluZWQgaW4gUkZDIDY3NDkuJm5ic3A7IEl04oCZcyBub3QgdGhlIHJpZ2h0IHBsYWNlIHRv IGV4dGVuZCB3aGF0DQogYW4gT0F1dGggY2xpZW50IGlzIGluIG5ldyB3YXlzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiAmbmJzcDtIb3cgYXJlIGNsaWVudCBjcmVkZW50aWFs cyBtYW5hZ2VkLiBBcmUgd2UgYXNzdW1pbmcgY2xpZW50IGNyZWRlbnRpYWxzIGhhdmUgYSBsaW1p dGVkIGxpZmV0aW1lIG9yIHJvdGF0aW9uIHBvbGljeT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGludGVudCB3YXMgdGhhdCBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIHJvdGF0ZWQsIGFzIGluZGlj YXRlZCBieSB0aGUgZXhwaXJlc19hdCBtZW1iZXIgb2YgdGhlIHJlc3BvbnNlLiBJZiBhIGNsaWVu dCdzIHNlY3JldCBleHBpcmVzLCBpdCBjYWxscyB0aGUgcmVhZCBvcGVyYXRpb24gb24gdGhlIENs aWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50ICjCpzQuMikgdG8gZ2V0IGl0cyBuZXcgY2xpZW50 X3NlY3JldC4NCiBJZiB0aGlzIGlzIHVuY2xlYXIgaW4gdGhlIGN1cnJlbnQgdGV4dCAod2hpY2gg SSBzdXNwZWN0IGl0IG1heSBiZSBhZnRlciBtdWx0aXBsZSByZWZhY3RvcmluZ3MpLCB0aGVuIEkg d2VsY29tZSBzdWdnZXN0aW9ucyBhbmQgc3BlY2lmaWMgdGV4dCBhcyB0byBob3cgdG8gbWFrZSB0 aGF0IGNsZWFyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U29tZXRoaW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhpcyBiZSB1cCBpbiB0aGUgaW50cm9k dWN0b3J5IHRleHQsIHNvbWV3aGVyZSBlbHNlLCBvciBoYXZlIGl0cyBvd24gc2VjdGlvbj88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkn bSBzdGFydGluZyB0byB0aGluayBjcmVkZW50aWFsIG1hbmFnZW1lbnQgaXMgYSBrZXkgcGFydCBv ZiB0aGUgZHJhZnQuIEl0IG1heSBiZSB3b3J0aCBpbnRyb2R1Y2luZyBhIHNwZWNpZmljIHNlY3Rp b24gb3V0bGluZyB0aGUgcmVnaXN0cmF0aW9uIGxpZmUtY3ljbGUsIHJlZ2lzdHJhdGlvbiBhY2Nl c3MgdG9rZW4gdXNhZ2UsIGFuZCBjbGllbnQgdG9rZW4gdXNhZ2UgYW5kIGJvb3RzdHJhcHBpbmcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgdGhpbmsgdGhhdCBhZGRpbmcgYSBk aXNjdXNzaW9uIG9uIHRoaXMgd291bGQgYmUgZmluZSwgYXMgaXQgY291bGQgaGVscCBkZXZlbG9w ZXJzIHVuZGVyc3RhbmQgdGhlIHdvcmtmbG93IG9mIHJlZ2lzdGVyaW5nLCB1c2luZywgYW5kIHVw ZGF0aW5nIHJlZ2lzdGVyZWQgY2xpZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkb2VzIGEgY2xp ZW50IGF1dGhlbnRpY2F0ZSB0aGUgZmlyc3QgdGltZSBhbmQgc3Vic2VxdWVudCB0aW1lcyB0byB0 aGUgcmVnaXN0cmF0aW9uIHNlcnZpY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlz IGlzIGEgc2VwYXJhdGUgcXVlc3Rpb24gYWxsIHRvZ2V0aGVyLCBhcyBpdCBkb2VzIG5vdCBpbnZv bHZlIHRoZSBjbGllbnRfc2VjcmV0IG9yIGNsaWVudF9pZCBhdCBhbGwuIFJhdGhlciwgdGhlIGZp cnN0IHRpbWUgdGhlIGNsaWVudCBzaG93cyB1cCB0byB0aGUgcmVnaXN0cmF0aW9uIHNlcnZpY2Us IGl0IG1heSBlaXRoZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IC0gTm90IGF1dGhlbnRpY2F0ZSBhdCBhbGwgKHRoaXMgaXMgdGhlIHRydWUgcHVibGljLCBvcGVu IHJlZ2lzdHJhdGlvbiwgYW5kIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgc2VydmVycyBkbyB0aGlz KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gQXV0aGVudGljYXRl IHVzaW5nIGFuIE9BdXRoIDIuMCB0b2tlbiAod2hpY2ggQVRNIG1lYW5zIGEgYmVhcmVyIHRva2Vu KS4gSG93IHRoZSBjbGllbnQgZ2V0cyB0aGF0IGJlYXJlciB0b2tlbiBhbmQgd2hhdCB0aGUgYmVh cmVyIHRva2VuIG1lYW5zIHRvIHRoZSBBUyBiZXlvbmQgJnF1b3Q7dGhpcyBjbGllbnQgaXMgYXV0 aG9yaXplZCB0byByZWdpc3RlciZxdW90OyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBzcGVjLCBi eSBkZXNpZ24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Vic2VxdWVudCB0aW1lcyB0aGF0IHRoZSBz YW1lIHJlZ2lzdGVyZWQgY2xpZW50IChieSB3aGljaCB3ZSBtZWFuIHRoZSBzYW1lIGluc3RhbmNl IG9mIGEgY2xpZW50IHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVudF9pZCkgc2hvd3MgdXAgYXQgdGhl IHJlZ2lzdHJhdGlvbiBlbmRwb2ludCAoYWN0dWFsbHksIHRoZSBDbGllbnQgQ29uZmlndXJhdGlv biBFbmRwb2ludCksIGl0IHVzZXMgaXRzIFJlZ2lzdHJhdGlvbg0KIEFjY2VzcyBUb2tlbiB0aGF0 IGl0IHdhcyBpc3N1ZWQgb24gaW5pdGlhbCByZWdpc3RyYXRpb24uIFRoaXMgaXMgYW4gT0F1dGgg Mi4wIEJlYXJlciB0b2tlbiB0aGF0IGlzIHVuaXF1ZSB0byB0aGUgY2xpZW50IGluc3RhbmNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWV0aGluZyBsaWtl IHRoaXMgc2hvdWxkIGJlIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T0ssIHRoZSBkZWZpbml0aW9uIG9mIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2VuIGNhbiBiZSBleHBhbmRlZCwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgcmVzdCBvZiBpdCBpcyBh bHJlYWR5IGluIHRoZXJlIGluIMKnMy4gSSdkIHdlbGNvbWUgc3VnZ2VzdGlvbnMgb24gd2hpY2gg Yml0cyBvZiB0aGlzIGNvdWxkIGJlIG1hZGUgY2xlYXJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+U2VlIHRoZSBkaXNjdXNzaW9uIG9uIHdoYXQgdGhlIHJlZ2lzdHJhdGlvbl9h Y2Nlc3NfdG9rZW4gaXMgaW4gdGhlIHRocmVhZCDigJxDbGllbnQgQ3JlZGVudGlhbCBFeHBpcnkg YW5kIG5ldyBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIC0gZHJhZnQtaWV0Zi1vYXV0aC1keW4t cmVnLTEw4oCdLiZuYnNwOw0KIEkgd2lsbCB3b3JrIHdpdGggSnVzdGluIHRvIGFwcGx5IHRoZXNl IGNsYXJpZmljYXRpb25zIHRvIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBUaGlzIG1heSBnbyBp bnRvIHRoZSBwcm9wb3NlZCBjcmVkZW50aWFsIG1hbmFnZW1lbnQgb3ZlcnZpZXcgc2VjdGlvbiBk aXNjdXNzZWQgYWJvdmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiAmbmJzcDtIb3cgaXMgdmVyc2lv bmluZyBvZiBjbGllbnRzIG1hbmFnZWQ/IFNob3VsZCBlYWNoIG5ldyB2ZXJzaW9uIG9mIGEgY2xp ZW50IHJlcXVpcmUgYSBjaGFuZ2UgaW4gY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNsdWRpbmcgcG9z c2libHkgY2hhbmdpbmcgY2xpZW50X2lkIGFuZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFsPyBJ IGRvbid0IGhhdmUgYSBzdHJvbmcgZmVlbGluZywgYnV0IGl0IGlzIHNvbWV0aGluZw0KIHRoYXQg aW1wbGVtZW50b3JzIHNob3VsZCBjb25zaWRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdXAgdG8gdGhlIEFTLCByZWFsbHksIGFuZCBJIGRvbid0 IHRoaW5rIHRoYXQgYW55IGdsb2JhbCBwb2xpY3kgd291bGQgZXZlciBmbHkgaGVyZS4gRXNwZWNp YWxseSBpZiB5b3UgY29uc2lkZXIgdGhhdCB0aGUgZW50aXJlIG5vdGlvbiBvZiAmcXVvdDt2ZXJz aW9uJnF1b3Q7IGlzIG1vcmUgZmx1aWQgdGhlc2UgZGF5cyB0aGFuIGl0IGV2ZXIgaGFzIGJlZW4u IEkgd291bGRuJ3QgbWluZCBhZGRpbmcgYSBkaXNjdXNzaW9uDQogaW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGlmIGl0IG1lcml0cyBtZW50aW9uaW5nIHRob3VnaCwgc28gdGhhdCB3ZSBj YW4gaGVscCBib3RoIGNsaWVudCBkZXZlbG9wZXJzIGFuZCBzZXJ2ZXIgZGV2ZWxvcGVycyBpbnN0 aXR1dGUgcmVhc29uYWJseSBnb29kIHBvbGljeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBndWVzcyB0aGUgaXNzdWUgaXMgdGhhdCB3aGVuIGEgY2xpZW50IHVwZ3JhZGVz IGl0IG1heSBoYXZlIGFjY2VzcyB0byB0aGUgb2xkIGNyZWRlbnRpYWxzLiBXaGF0IGlzIHRoZSBp bnRlbnQgdGhlbiBvZiByZWdpc3RyYXRpb24uICZuYnNwO1NpbmNlIHlvdSBoYXZlIGFuIHVwZGF0 ZSBhcmUgY2xpZW50cyBleHBlY3RlZCB0byB1cGRhdGUgL3JlLXJlZ2lzdGVyIG9yIG5vdD8gJm5i c3A7SSdtIG5vdCBzdXJlIHRoaXMgaXMgYSBzZWN1cml0eQ0KIGNvbnNpZGVyYXRpb24gYnV0IG1v cmUgcGFydCBvZiB0aGUgd2hvbGUgY2hhbmdlIG1hbmFnZW1lbnQgZnVuY3Rpb24gZHluYW1pYyBy ZWdpc3RyYXRpb24gc3VwcG9ydHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHlvdXIgdXBncmFkZWQgdmVyc2lvbiBvZiB0aGUgY2xpZW50IHN0aWxsIGhhcyBhY2Nlc3Mg dG8gaXRzIG9sZCBjcmVkZW50aWFscywgd2h5IHdvdWxkbid0IGl0IGp1c3QgdXNlIHRob3NlPyBJ IGRvbid0IHNlZSBhIHJlYXNvbiBmb3IgZm9yY2luZyBhIHJlLXJlZ2lzdHJhdGlvbi4gTm9yIGRv IEkgc2VlIGFueSB3YXkgdGhhdCBhbiBBUyB3b3VsZCBldmVuIGJlIGFibGUgdG8gdGVsbCB0aGF0 IGEgY2xpZW50DQogaGFkIGJlZW4gdXBncmFkZWQuIEFuIHVwZ3JhZGVkIGNsaWVudCBhbHdheXMg aGFzIHRoZSAqb3B0aW9uKiBvZiByZS1yZWdpc3RlcmluZyBpdHNlbGYgYW5kIGdldHRpbmcgYSBu ZXcgY2xpZW50X2lkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBjb25jZXJuIGhlcmUgaXMgdGhhdCByb3RhdGlvbiBv ZiBjbGllbnQgY3JlZGVudGlhbCBpcyBub3Qgc29tZXRoaW5nIGRpc2N1c3NlZCBiZWZvcmUuIEJl Zm9yZSB3ZSBwdXQgaXQgaW4gdGhlIHNwZWMgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSByZWFzb25z IGZvciBkb2luZyBpdCBhbmQgd2hhdCBwcm9ibGVtcyBpdCBzb2x2ZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB0aGlzIG1heSBiZSBqdXN0IGEgY2FzZSBvZiBsZXR0aW5nIHBlb3BsZSBl eGNoYW5nZSBjcmVkZW50aWFscyBmb3Igd2hhdGV2ZXIgcmVhc29uIHRoZXkgZmVlbCBpcyBhcHBy b3ByaWF0ZS4gJm5ic3A7VGhlIHZlcnNpb24gdXBncmFkZSB0aGluZyBzdWdnZXN0cyB0aGF0IHdo ZW4gYSBjbGllbnQgaXMgdXBncmFkZWQgaXQgc2hvdWxkIGdvIHRvIHRoZSByZWdpc3RyYXRpb24g c2VydmVyIHRvICZxdW90O3JlLXJlZ2lzdGVyJnF1b3Q7Lg0KICZuYnNwO0RlcGVuZGluZyBvbiB0 aGUgcG9saWN5IG9mIHRoZSBzZXJ2ZXIsIGl0IG1heSAob3IgbWF5IG5vdCkgcmVjZWl2ZSBhIG5l dyBjbGllbnRfaWQgYW5kL29yIG5ldyBjcmVkZW50aWFsLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbmUgb2YgdGhlIGJlc3QgYmVuZWZpdHMgSSBjYW4gdGhpbmsgb2YgaXMgaWYgeW91IGRp c2NvdmVyIGEgdmVyc2lvbiBvZiBhIGNsaWVudCBoYXMgYSBwcm9ibGVtLCBiZWluZyBhYmxlIHRv IHNlbGVjdCBhIGdyb3VwIG9mIGNsaWVudHMgYnkgc29mdHdhcmUgYW5kIHZlcnNpb24gaXMgaW1w b3J0YW50LiBUaHVzIGlmIGNsaWVudF9pZCBkb2Vzbid0IHRyYWNlIHRvIGEgcGFydGljdWxhciBz b2Z0d2FyZSBhbmQgdmVyc2lvbiwNCiB0aGF0IG1ha2VzIGl0IGhhcmQgdG8gZG8uICZuYnNwO0kg Jm5ic3A7dGhpbmsgeW91IHRhbGtlZCBhYm91dCB0aGlzIGFzIGFuIGlzc3VlIGZvciBCbHVlIEJ1 dHRvbiYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkFnYWluLCBSRkMgNjc0 OSBkZWZpbmVzIG5vIGNsaWVudCBpbnN0YW5jZXMgb3IgZ3JvdXBzIG9mIGNsaWVudHMsIHRoZXJl Zm9yZSBJIGJlbGlldmUgdGhhdCBpdOKAmXMgaW5hcHByb3ByaWF0ZSB0byBkbyBzbyBoZXJlLiZu YnNwOyBXZSBkb27igJl0IG5lZWQgdG8gYm9pbCB0aGUgb2NlYW4uJm5ic3A7DQogSWYgYSBuZXcg Y2hhcnRlciBpdGVtIGlzIGFwcHJvdmVkIHRvIGRvIHdvcmsgb24gY2xpZW50IGluc3RhbmNlcyBh bmQgcHJvdG9jb2wgZWxlbWVudHMgdG8gdXNlIGFuZCBleHByZXNzIHRoZW0sIHRoYXTigJlzIHRo ZSB0aW1lIGZvciB0aGUgd29ya2luZyBncm91cCB0byBjb25zaWRlciB0aGF0IHBvc3NpYmlsaXR5 IOKAkyBub3QgYXMgcGFydCBvZiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuICZu YnNwO1doYXQgaXMgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4/IFdoeSBpcyBpcyB1c2Vk PyBXaGF0IGlzIGl0cyBsaWZlLWN5Y2xlPyAmbmJzcDtXaGVuIGlzIGl0IGlzc3VlZCwgd2hlbiBp cyBpdCBjaGFuZ2VkPyBXaGVuIGlzIGl0IGRlbGV0ZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZWUgdGhlIHJlc3BvbnNlIGFib3ZlIGFib3ZlIGFuZCB0aGUgZGVmaW5pdGlvbiBpbiDC pzEuMjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2lzdHJhdGlvbiBB Y2Nlc3MgVG9rZW46IEFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gaXNzdWVkIGJ5IHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50 IHdoaWNoIGlzIHVzZWQgYnkgdGhlIENsaWVudCB0byBhdXRoZW50aWNhdGUgaXRzZWxmIGR1cmlu ZyByZWFkLCB1cGRhdGUsIGFuZCBkZWxldGUgb3BlcmF0aW9ucy4gVGhpcyB0b2tlbiBpcw0KIGFz c29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgQ2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoaXMgY2FuIGJl IGNsYXJpZmllZCwgSSB3ZWxjb21lIHRleHQgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGF0dGVyIHBhcnQgb2YgMS4y IGRpZG4ndCBzZWVtIGxpa2UgdGVybWlub2xvZ3kgYnV0IHJhdGhlciBhcmNoaXRlY3R1cmUgb3Ig cGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRoYXQgZGVzY3JpYmVzIHdoYXQgdGhlIHNwZWMgZG9l cy4gVGhlIHRoaXJkIHBvaW50IGRvZXNuJ3Qgc2VlbSB0byBmaXQgd2l0aCB0aGUgb3RoZXIgdHdv IGV4Y2VwdCB0byBzYXkgdGhhdCB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24NCiBlbmRwb2ludHMg dXNlIHRoZWlyIG93biBhY2Nlc3MgdG9rZW5zIGNhbGxlZCByZWdpc3RyYXRpb24gYWNjZXNzIHRv a2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7b3JwaGFuczogMjt0ZXh0LWFsaWduOi13ZWJraXQt YXV0bzt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Q2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludDogVGhlIE9BdXRoIDIuMCBF bmRwb2ludCB0aHJvdWdoIHdoaWNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIENsaWVu dCBjYW4gcmVxdWVzdCBuZXcgcmVnaXN0cmF0aW9uLiZuYnNwOyBUaGUgbWVhbnMgb2YgdGhlIENs aWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2J0YWluaW5nIHRoZSBVUkwgZm9yIHRo aXMgZW5kcG9pbnQgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IENsaWVudCBDb25m aWd1cmF0aW9uIEVuZHBvaW50OiBUaGUgT0F1dGggMi4wIEVuZHBvaW50IHRocm91Z2g8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGEgc3BlY2lmaWMgQ2xpZW50IGNhbiBtYW5hZ2Ug aXRzIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHByb3ZpZGVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0byB0aGUgQ2xpZW50LiZuYnNw OyBUaGlzIFVSTCBmb3I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgZW5kcG9pbnQg aXMgY29tbXVuaWNhdGVkIHRvIHRoZSBjbGllbnQgYnkgdGhlIEF1dGhvcml6YXRpb248L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZlciBpbiB0aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJl c3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjog QW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBpc3N1ZWQgYnkgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBdXRob3JpemF0aW9uIFNlcnZlciB0aHJvdWdoIHRoZSBDbGllbnQgUmVnaXN0 cmF0aW9uIEVuZHBvaW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGljaCBpcyB1c2Vk IGJ5IHRoZSBDbGllbnQgdG8gYXV0aGVudGljYXRlIGl0c2VsZiBkdXJpbmcgcmVhZCw8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVwZGF0ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiZuYnNw OyBUaGlzIHRva2VuIGlzIGFzc29jaWF0ZWQgd2l0aCBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBwYXJ0aWN1bGFyIENsaWVudC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgc2VjdGlvbiBpcyBtZWFudCB0byBqdXN0IGludHJvZHVjZSB0aGUgbmV3IHRlcm1z IHRoYXQgYXJlIHRoZW4gZXhwbGFpbmVkIGluIGdyZWF0ZXIgZGV0YWlsIHRocm91Z2hvdXQgdGhl IHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBZZXMsIGl0J3MgYSBiaXQgYXJjaGl0ZWN0dXJlLCBidXQg b25seSBpbiB0aGUgc2Vuc2UgdGhhdCB5b3UgbmVlZCB0byBkZWZpbmUgdGhlIHRlcm1zIHRoYXQg bWFrZSB1cCB5b3VyDQogYXJjaGl0ZWN0dXJlLiBIb3cgd291bGQgeW91IHN1Z2dlc3QgdGhhdCBp dCBjaGFuZ2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJvYmFibHkgdGhpcyBpcyBt b3JlIGEgbWF0dGVyIG9mIHN0eWxlLiAmbmJzcDtCdXQsIHdoYXQgaGFwcGVuZWQgZm9yIG1lIGlz IEkgbmF0dXJhbGx5IHNraXBwZWQgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24sIGFzIEkgd2Fzbid0 IGV4cGVjdGluZyBwcm90b2NvbCBjb21wb25lbnRzIHRvIGJlIHRoZXJlLiAmbmJzcDsmcXVvdDt0 ZXJtaW5vbG9neSZxdW90OyBpcyBzb21ldGhpbmcgSSB0aGluayBwZW9wbGUgdGVuZCB0byB1c2Ug YXMgYSBkaWN0aW9uYXJ5DQogcmF0aGVyIHRoYW4gYXMgcHJvdG9jb2wgY29tcG9uZW50IGRlc2Ny aXB0aW9uLiAmbmJzcDtNYXliZSB0aGUgY2hhaXJzIGNhbiBhZHZpc2U/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgZGlzdGluZ3Vpc2ggYmV0d2VlbiBmaXJz dCB0aW1lIHJlZ2lzdHJhdGlvbiBvZiBhIHBhcnRpY3VsYXIgY2xpZW50IHNvZnR3YXJlIHBhY2th Z2UsIGl0IGlzIHBvc3NpYmxlIHRoYXQgc29tZXRoaW5ncyBsaWtlIGF1dGhlbnRpY2F0aW9uIG1l dGhvZCBjYW4gYmUgbmVnb3RpYXRlIGluIG9yIG91dC1vZi1iYW5kIGF0IHRoYXQgdGltZS4gU3Vi c2VxdWVudCByZWdpc3RyYXRpb25zIHNob3VsZCBvbmx5IGhhdmUNCiBwYXJhbWV0ZXJzIGZvciBp dGVtcyB0aGF0IGNvdWxkIGNoYW5nZSBwZXIgZGVwbG95bWVudCAobGlrZSB0b3NfdXJpKS4gJm5i c3A7SSB0aGluayB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCBpcyBvbmUgdGhpbmcgdGhhdCBz aG91bGQgbm90IGJlIG5lZ290aWF0ZWQgcGVyIGluc3RhbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gc3Vic2VxdWVudCBpbnN0YW5jZXMgcmVnaXN0 ZXIsIEkgaGF2ZSB0byBhc2sgdGhlIHF1ZXN0aW9uLCBmb3IgZXhhbXBsZSB3aGVuIHdvdWxkIHRo aW5ncyBsaWtlICZxdW90O3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kJnF1b3Q7IGJlIG5lZ290 aWF0ZWQgb3IgYmUgZGlmZmVyZW50IGZvciB0aGUgc2FtZSBjbGllbnQgc29mdHdhcmU/IFNob3Vs ZCBub3QgYWxsIGluc3RhbmNlcyB1c2UgdGhlIHNhbWUgYXV0aGVudGljYXRpb24NCiBtZXRob2Qu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkknbSBjb25mdXNlZCBieSB0aGlzIC0tIGFzIGZhciBhcyB0aGUgZHluYW1pYyBy ZWdpc3RyYXRpb24gc3BlYyBpcyBjb25jZXJuZWQsIGFsbCBpbnN0YW5jZXMgYXJlIHNlcGFyYXRl IGZyb20gZWFjaCBvdGhlci4gQWxsIHBhcmFtZXRlcnMgY2hhbmdlIHBlciBpbnN0YW5jZS4gQW5k IGluc3RhbmNlLCB5b3Ugc2hvdWxkIGtlZXAgaW4gbWluZCwgaXMgZGVmaW5lZCBhcyBhbnkgb25l IGNvcHkgb2YgdGhlIGNsaWVudA0KIGNvZGUgY29ubmVjdGluZyB0byBhbnkgbmV3IGF1dGhvcml6 YXRpb24gc2VydmVyLiBUaGF0IHBhaXJpbmcgY3JlYXRlcyB0aGUgY2xpZW50X2lkLCBhbmQgdGhl cmVmb3JlIHRoZSBpbnN0YW5jZSwgYW5kIHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiwgYW5kIHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGl0c2VsZiBhdCBhIGNvbmNl cHR1YWwgbGV2ZWwuIFNvIHRoZXJlIGlzIG5vIHdheSBvdGhlciB0aGFuIHBlci1pbnN0YW5jZQ0K IGZvciBhIGNsaWVudCB0byBhc2sgZm9yIGEgcGFydGljdWxhciB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZC4gV2hlcmUgZWxzZSB3b3VsZCB0aGUgQVMgZmluZCBvdXQgYWJvdXQgaXQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBzdGlsbCBkaXNhZ3JlZSBv biB0aGlzLiBJdCBpcyBteSBhc3NlcnRpb24gdGhhdCBjbGllbnRzIHNob3VsZCBORVZFUiBhc2sg Zm9yIGEgcGFydGljdWxhciB0b2tlbiBhdXRoIG1ldGhvZC4gU2luY2UgaXQgaXMgdGhlIEFTIHRo YXQgaXMgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCwgdGhlbiBpdCBpcyB0aGUgQVMncyByaWdo dCB0byBzZXQgdGhlIGF1dGhlbnRpY2F0aW9uIHBvbGljeS4gJm5ic3A7VGhlIHJvbGUNCiBvZiBk eW5hbWljIHJlZyBlbmRwb2ludCBpcyB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0IG11c3Qg ZG8uICZuYnNwO015IGFzc3VtcHRpb24gaXMgdGhhdCBkdXJpbmcgdGhlIGZpcnN0IHRpbWUgYSBw aWVjZSBvZiBzb2Z0d2FyZSBpcyByZWdpc3RlcmVkICh0aGUgZmlyc3QgaW5zdGFuY2UpLCB0aGVy ZSBjb3VsZCBiZSBzb21lIE9PQiBkaXNjdXNzaW9uIGJ5IGFuIGFkbWluaXN0cmF0b3IgdG8gYXBw cm92ZSB0aGUgcGFydGljdWxhciBhdXRoZW50aWNhdGlvbg0KIHR5cGUgZm9yIHRoZSBBUyBpbiBx dWVzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmVuJ3QgaGVhcmQgYSByZWFzb24ganVz dGlmeWluZyB0aGlzIHBhcmFtZXRlciBvdGhlciB0aGVuICZxdW90O2l0IGlzIG5lZWRlZCZxdW90 Oy4gJm5ic3A7V2h5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSByb2xlIG9mIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBwcm90b2NvbCBpcyB0d29mb2xk OiBoYWxmIG9mIHRoYXQgaXMgdGhlIHNlcnZlciBpbmZvcm1pbmcgdGhlIGNsaWVudCB3aGF0IGl0 IG11c3QgZG8uIEJ1dCB0aGUgb3RoZXIgaGFsZiBpcyB0aGUgY2xpZW50IGluZm9ybWluZyB0aGUg c2VydmVyIHdoYXQgaXQgKmNhbiogZG8sIG9yIHdoYXQgaXQgKndhbnRzKiB0byBkby4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgYWdhaW4sIHRoZXJlJ3Mgbm8gd2F5IHRvIGRpc3Rpbmd1 aXNoIGEgZmlyc3QgaW5zdGFuY2UgZnJvbSBhIHN1YnNlcXVlbnQgaW5zdGFuY2UgdW5sZXNzIHlv dSdyZSBkb2luZyBzb21ldGhpbmcgaW4gYWRkaXRpb24uIE5vdGhpbmcgaXMgc3RvcHBpbmcgdGhl IHNhbWUgYXBwbGljYXRpb24gZnJvbSByZWdpc3RlcmluZyBhIG5ldyBpbnN0YW5jZSBvZiBpdHNl bGYgZm9yIGV2ZXJ5IHNpbmdsZSB1c2VyIG9yDQogZXZlcnkgc2luZ2xlIHRva2VuIHRoYXQgaXQg d2FudHMgdG8gZ2V0IGFjY2VzcyBmb3IuIFRoYXQncyBjb21wbGljYXRlZCBhbmQgd2FzdGVmdWwg YW5kIG5vdCBhIGdyZWF0IGlkZWEsIHN1cmUsIGJ1dCAmbmJzcDt0aGVyZSdzIG5vIHVzZWZ1bCB3 YXkgdG8gcHJldmVudCB0aGF0IGtpbmQgb2YgYmVoYXZpb3IgaWYgeW91IGFsc28gd2FudCBvcGVu IHJlZ2lzdHJhdGlvbiBvZiBjbGllbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgd2UndmUgZGlzY3Vzc2VkIGhvdyByZWNvZ25pemluZyBzdWJzZXF1ZW50IGlu c3RhbmNlcyBpcyBlYXNpbHkgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIG1lbnRpb25l ZCBpbiB0aGUgb3RoZXIgdGhyZWFkLCBpZiBhIGRldmVsb3BlciBjaG9vc2VzIHRvIGxpbWl0IHRo ZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGNsaWVudCBpdCBtdXN0IGRvIHNvIGJ5IGxvb2tpbmcgdG8g dGhlIGRldmVsb3BlciBvciBzdGFuZGFyZCBiZWhpbmQgdGhlIEFQSS4gJm5ic3A7T3RoZXJ3aXNl IHRoZXkgYXJlIHRha2luZyB0aGUgY2hhbmNlLiAmbmJzcDtUaGVyZSdzIG5vIHdheSBhIGRldmVs b3Blcg0KIGNhbiBxdWVyeSBhbGwgdGhlIHBvdGVudGlhbCBkZXBsb3llcnMgdG8gYXNrIHdoYXQg YXV0aG4gdHlwZXMgd2lsbCB5b3UgdXNlLiBBcyBJIHNhaWQsIHRoZSBuZXQgZWZmZWN0IGluIHRo ZSBhYnNlbmNlIG9mIGFuIEFQSSBzdGFuZGFyZCBkaWN0YXRpbmcgd2hhdCBzaG91bGQgYmUgc3Vw cG9ydGVkLCB0aGUgZGV2ZWxvcGVyIHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgYWxsIG1ldGhvZHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcG9pbnQgaGVyZSBpcyB0aGF0IG5vbmUgb2YgdGhpcyBp cyBoZWxwZWQgYnkgdGhlIGNsaWVudCBhcHAgc2F5aW5nIHdoYXQgaXQgc3VwcG9ydHMuIEEgZGV2 ZWxvcGVyIHdobyB0YWtlcyB0aGUgcm91dGUgb2YgbGltaXRpbmcgaW1wbGVtZW50YXRpb24gdGFr ZXMgdGhlIGNoYW5jZSB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCBub3QgYWNjZXB0LiAmbmJzcDtTbyB3 aHkgbmVnb3RpYXRlIHdpdGhpbiByZWdpc3RyYXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgdGhlcmUncyBubyB3YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9y IHRoZSBzZXJ2ZXIgdG8gdGVsbCB0aGUgY2xpZW50IHdoaWNoIHRva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kIHRvIHVzZS4gQWxsIGluc3RhbmNlcyB3aWxsIHByb2JhYmx5IGFzayBmb3IgdGhlIHNh bWUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgZnJvbSBhbGwgYXV0aCBzZXJ2ZXJzIHRoZXkg dGFsayB0bywgcmlnaHQ/IEFuZA0KIGVhY2ggQVMgd2lsbCB0ZWxsIGVhY2ggaW5zdGFuY2UgdGhh dCByZWdpc3RlcnMgd2l0aCBpdCB0byB1c2UgYSBwYXJ0aWN1bGFyIGF1dGggbWV0aG9kLiBUaGVy ZSBpcyBubyB3YXkgdG8gdGllIHRvZ2V0aGVyIGRpZmZlcmVudCBpbnN0YW5jZXMgYWNyb3NzIChv ciB3aXRoaW4pIGF1dGggc2VydmVycyB3aXRob3V0IHNwZWNpZnlpbmcgYSBzaWduaWZpY2FudCBh bW91bnQgb2Ygb3RoZXIgbWFjaGluZXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpXaGljaCBpcyBub3Qg dG8gc2F5IHRoYXQgaXQncyBub3QgdXNlZnVsIGluIHNvbWUgY2lyY3Vtc3RhbmNlcyB0byB0aWUg dG9nZXRoZXIgZGlmZmVyZW50IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBjb2RlIGFjcm9zcyAob3Ig d2l0aGluKSBhdXRoIHNlcnZlcnMuIFRoaXMgaXMgd2h5LCB3aXRoIEJsdWUgQnV0dG9uJiM0Mzss IHdlIHNwZWNpZmllZCBhIHNwZWNpZmljIHRva2VuIGZvcm1hdCBmb3IgdGhlIGluaXRpYWwgYWNj ZXNzIHRva2VuIHRoYXQgdGhlIGNsaWVudHMNCiB1c2UgdG8gY2FsbCB0aGUgcmVnaXN0cmF0aW9u IGVuZHBvaW50IHRoZSBmaXJzdCB0aW1lLCAmbmJzcDthcyB3ZWxsIGFzIGEgZGlzY292ZXJ5IHBy b3RvY29sIGFnYWluc3QgYSBjZW50cmFsaXplZCBzZXJ2ZXIgdGhhdCBoYW5kbGVzIHByZS1yZWdp c3RyYXRpb24uIEFsbCBvZiB0aGlzIG1hY2hpbmVyeSBpcywgaW4gbXkgb3BpbmlvbiwgYSBzdHVw ZW5kb3VzIG92ZXJraWxsIGZvciB0aGUgZ2VuZXJhbCBjYXNlLCB0aG91Z2ggaWYgc29tZSBmb2xr cyBmaW5kDQogdXNlIGZvciBpdCBvdXRzaWRlIG9mIEJCJiM0MzsgdGhlbiBpdCdkIGJlIGEgZ29v ZCB0aGluZyB0byBhYnN0cmFjdCBvdXQgYW5kIG1ha2UgaXRzIG93biBzcGVjIHRoYXQgZXh0ZW5k cyB0aGUgRHluIFJlZyBzcGVjIGluIGEgZnVsbHkgY29tcGF0aWJsZSB3YXkuIEZ1cnRoZXJtb3Jl LCBldmVuIGluIEJsdWUgQnV0dG9uJiM0Mzsgd2Ugc3BlY2lmeSB0aGF0IGFsbCBhdXRoIHNlcnZl cnMgTVVTVCBhbHNvIGFjY2VwdCBvcGVuIHJlZ2lzdHJhdGlvbiwgd2l0aG91dA0KIGFuIGluaXRp YWwgYWNjZXNzIHRva2VuLCB3aGVyZSB0aGUgY2xpZW50IHNpbXBseSBzaG93cyB1cCBhbmQgc2F5 cyAmcXVvdDtoZXksIGhlcmUgYXJlIG15IHBhcmFtZXRlcnMuJnF1b3Q7IFRoZSBhdXRoIHNlcnZl ciBoYXMgbm8gd2F5IHRvIGtub3cgaW4gdGhpcyBjYXNlIGFueSBraW5kIG9mIG91dC1vZi1iYW5k IG5lZ290aWF0aW9uIGZvciBkaWZmZXJlbnQgdGhpbmdzLiBJbiBCQiYjNDM7IHdlIGFyZSB3cml0 aW5nIHZlcnkgc3BlY2lmaWMgcG9saWN5IGd1aWRlbGluZXMNCiBhYm91dCBob3cgdG8gcHJlc2Vu dCB0aGUgVVggYW5kIHRoaW5ncyB0byB0aGUgZW5kIHVzZXIgZm9yIGFsbCBvZiB0aGVzZSBkaWZm ZXJlbnQgY2FzZXMuIEJ1dCBhZ2FpbiwgYWxsIG9mIHRoaXMgaXMgc3BlY2lmaWMgdG8gdGhlIEJC JiM0MzsgdXNlIGNhc2UsIGFuZCBJIGRvbid0IHNlZSB2YWx1ZSBpbiBkcmFnZ2luZyBpdCBpbiB0 byB0aGUgcmVnaXN0cmF0aW9uIHNwZWMgb24gaXRzIG93bi4gSSBiZWxpZXZlIGl0IHdvdWxkIGJl IGZhciB0b28gbGltaXRpbmcuPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMEIwNTAiPlNlZSBteSBwcmV2aW91cyBjb21tZW50cyBvbiBkaWZmZXJlbnRpYXRpbmcg Y2xpZW50IGluc3RhbmNlcyBiZWluZyBvdXQgb2Ygc2NvcGUgd2l0aG91dCByZWNoYXJ0ZXJpbmcg dG8gZG8gdGhpcyBuZXcgd29yayBhbmQgb24gd2hhdCB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190 b2tlbg0KIGlzLiZuYnNwOyBJbiBzaG9ydCwgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4g aXMgYW4gUkZDIDY3NTAgYmVhcmVyIHRva2VuIGlzc3VlZCB0byB0aGUgcGFydHkgcmVnaXN0ZXJp bmcgdGhlIGNsaWVudCwgZW5hYmxpbmcgaXQgdG8gc3Vic2VxdWVudGx5IHJldHJpZXZlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCB0byBwb3RlbnRpYWxseSB1 cGRhdGUgdGhlIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhhdA0KIHJlZ2lzdGVyZWQg Y2xpZW50LiZuYnNwOyBBZ2FpbiwgSeKAmWxsIHdvcmsgd2l0aCBKdXN0aW4gdG8gbWFrZSBzdXJl IHRoYXQgdGhpcyBpcyBhcyBjbGVhciBhcyBwb3NzaWJsZSBpbiB0aGUgc3BlY2lmaWNhdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZpbmFsbHksIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGluY29uc2lz dGVudCBzdHlsZSBhcHByb2FjaCB3aXRoJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWhhcmRqb25vLW9hdXRoLXJlc291cmNlLXJlZy0wMC50eHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiM0NDAwODg7YmFja2dyb3VuZDp3aGl0ZSI+ZHJh ZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnPC9zcGFuPjwvYT4mbmJzcDt3aGljaA0KIHVz ZXMgRVRhZ3MuIFNob3VsZCB0aGlzIGRyYWZ0IGRvIHNvIGFzIHdlbGw/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGF0J3MgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uLCBub3QgYSB3b3Jr aW5nIGdyb3VwIGRyYWZ0LiBOb2JvZHkgaGFzLCB1bnRpbCBub3csIGV2ZW4gbWVudGlvbmVkIHRo ZSB1c2Ugb2YgRVRhZ3MgaGVyZS4gVU1BICh3aGVyZSB0aGUgcmVzb3VyY2UgcmVnaXN0cmF0aW9u IGRyYWZ0IGNvbWVzIGZyb20pIHVzZXMgRVRhZ3MsIGhlbmNlIHRoZWlyIGluY2x1c2lvbiB0aGVy ZS4gSSBwZXJzb25hbGx5IGRvbid0DQogc2VlIHRoZWlyIHV0aWxpdHkgaGVyZSwgdGhvdWdoLCBh bmQgSSB3b3VsZG4ndCB3YW50IHRvIGluY2x1ZGUgYSB3aG9sbHkgbmV3IG1lY2hhbmlzbSB0aGlz IGxhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gVGhvbWFzJyBk cmFmdCBpcyBub3QgYSBXRyBkb2N1bWVudC4gQnV0IHRoYXQgZG9lc24ndCBtZWFuIGhlIGRvZXNu J3QgaGF2ZSBhIHBvaW50LiBJdCdzIHdvcnRoIGRpc2N1c3NpbmcuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T25lIGNvdWxkIGFyZ3VlIHRoYXQgdGhlIHBvaW50IG9mIGFuIEVUYWcgaXMgdGhh dCBpdCBpcyB1c2VmdWwgZm9yIGNoYW5nZSBkZXRlY3Rpb24gd2hlbiB0aGVyZSBhcmUgbXVsdGlw bGUgd3JpdGVycyB0byBhIHBhcnRpY3VsYXIgcmVzb3VyY2UuICZuYnNwO0luIHRoZSBkZXNpZ24g b2YgZHluYW1pYyByZWdpc3RyYXRpb24gZW5kcG9pbnQsIHRoZXJlIHNob3VsZCBvbmx5IGJlIG9u ZSB3cml0ZXIgLS0gdGhlIGNsaWVudC4NCiBUaGlzIGlzIGFuIGltcG9ydGFudCBvYnNlcnZhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG90aGVyIG1l Y2hhbmlzbXMgdGhhdCBoYW5kbGUgdGhpcyAtLSBuYW1lbHksIHRoZSByZWdpc3RyYXRpb24gYWNj ZXNzIHRva2VuIGFuZCB0aGUgY2xpZW50X2lkLiBNYW55IGluc3RhbmNlcyBpbmNsdWRlIHRoZSBj bGllbnRfaWQgaW4gc29tZSBmb3JtIGluIHRoZSBjbGllbnQgY29uZmlndXJhdGlvbiBlbmRwb2lu dCdzIFVSTCBmb3Igc2FuaXR5IGNoZWNraW5nLCBhcyBkZXNjcmliZWQgaW4gwqc0LjEuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgZXZlcnlvbmUgYWdyZWVzLCBJJ20gaW4g YWdyZWVtZW50LiBCdXQgaXQgd2lsbCBsaWtlbHkgbWVhbiBjaGFuZ2VzIGZvciB0aGUgcmVzb3Vy Y2UgcmVnIGRyYWZ0IGlmIGFkb3B0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAi PkVUYWdzIHNlZW0gbGlrZSBhbiB1bm5lY2Vzc2FyeSBhZGRpdGlvbiAoYW5kIHBvdGVudGlhbCBj b21wbGljYXRpb24pIHRvIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSB3 b3JraW5nIGZpbmUgYXMtaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+U3BlY2lmaWMg aXRlbXM6PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0t LS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4mcXVv dDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCZxdW90OzwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVyZSBpcyBzb21lIGNvbmZ1c2lvbiBhcyB0byB3aGV0aGVyIHRoaXMgYXBwbGllcyB0byBz ZXJ2ZXIgb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAmbmJzcDtTdWdnZXN0IHJlbmFtaW5nIHBh cmFtZXRlciB0byAmcXVvdDt0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QmcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIGZpcnN0IEkndmUgaGVhcmQg b2YgdGhpcyBwYXJ0aWN1bGFyIGNvbmZ1c2lvbi4gSSdtIGZpbmUgd2l0aCBlaXRoZXIgbmFtZSBi dXQgYXQgdGhpcyBzdGFnZSBJIGRvbid0IHdhbnQgdG8gbWFrZSBzeW50YXggY2hhbmdlcyB3aXRo b3V0IHZlcnksIHZlcnkgY29tcGVsbGluZyByZWFzb25zIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHF1ZXN0aW9uIHdhcyByYWlzZWQgdG8g bWUgYnkgc29tZSBuZXcgZGV2ZWxvcGVycy4gSXQgc2VlbXMgb2J2aW91cyB0byB1cyBhcyBleHBl cmllbmNlZCBPQXV0aCBwZXJzb25zLCBidXQgdG8gbmV3IGRldmVsb3BlcnMgaXQgc2VlbXMgdW5j bGVhci4gJm5ic3A7QWxzbywgbm93IHRoYXQgeW91IGFyZSBpbnRyb2R1Y2luZyByZWdpc3RyYXRp b24gYXV0aGVudGljYXRpb24sIHRoZSB3aG9sZSB0aGluZyBnZXRzIHZlcnkNCiBjb25mdXNpbmcu IFNvIGl0IGlzIHVzZWZ1bCBkaXNhbWJpZ3VhdGUgYWxsIHRoZSBwYXJhbWV0ZXJzIHdoZXJlIHBv c3NpYmxlLiAmbmJzcDtUaGF0IHNhaWQsIEkgd291bGRuJ3QgbWluZCBzaG9ydGVyIG5hbWVzICht YXliZSBub3QgcXVpdGUgYXMgc2hvcnQgYXMgdGhlIEpPU0Ugc3R1ZmYgOy0pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFpciBlbm91Z2gsIGJ1dCBhZ2Fpbiwg SSBvbmx5IHdhbnQgdG8gZG8gc3ludGF4IGNoYW5nZXMgaWYgdGhlIHJlc3Qgb2YgdGhlIFdHICpy ZWFsbHkqIHdhbnRzIHRvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5JIGFncmVl IHdpdGggSnVzdGluIGhlcmUuJm5ic3A7IEnigJltIGZpbmUgY2xhcmlmeWluZyB0aGUgZGVzY3Jp cHRpb24gb2YgdGhpcyBwYXJhbWV0ZXIgdG8gcmVzb2x2ZSB0aGUgcG90ZW50aWFsIGFtYmlndWl0 aWVzIHRoYXQgeW91IGNpdGUsIFBoaWwuJm5ic3A7IEnigJltIG5vdCBPSyByZXZpc2luZw0KIHRo ZSBzeW50YXggd2l0aG91dCBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHNvLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiogQ3VycmVudGx5LCB0aGUgQVBJIG9ubHkgc3VwcG9ydHMgYSBzaW5nbGUgdmFsdWUg aW5zdGVhZCBvZiBhbiBhcnJheS4gJm5ic3A7SWYgdGhlIHB1cnBvc2UgaXMgdG8gYWxsb3cgdGhl IGNsaWVudCB0byBrbm93IHdoYXQgYXV0aCBtZXRob2RzIGl0IHN1cHBvcnRzLCB0aGlzIHNob3Vs ZCBiZSBhbiBhcnJheSBpbmRpY2F0ZWQgd2hhdCBtZXRob2RzIHRoZSBjbGllbnQgc3VwcG9ydHMg LSBvciBpdCBzaG91bGQgbm90IGJlDQogdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgd291bGQgcmF0aGVyIGxpa2UgdGhpcyB0byBiZSBhbiBhcnJheSwgcGVyc29uYWxseSwgYW5k IGJyb3VnaHQgaXQgdXAgd2l0aCB0aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBhYm91 dCBzaXggbW9udGhzIGFnby4gQnV0IHRoZXJlIGl0IHdhcyBkZWNpZGVkIHRoYXQgYSBzaW5nbGUg dmFsdWUgd2FzIHNpbXBsZXIgYW5kIHN1ZmZpY2llbnQgZm9yIHRoZSBwdXJwb3NlLiBUaGUgSUVU RiBkcmFmdCBoYXMNCiBpbmhlcml0ZWQgdGhpcyBkZWNpc2lvbi4gSSAqYmVsaWV2ZSogKHRob3Vn aCBhbSBub3QgMTAwJSBwb3NpdGl2ZSkgdGhhdCBJIGJyb3VnaHQgdXAgdGhpcyB2ZXJ5IGlzc3Vl IGluIHRoZSBXRyBoZXJlIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhbnkgdHJhY3Rpb24gb24gaXQsIHNv IHNpbmdsZSBpdCByZW1haW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGNhbiBnZXQgYmVoaW5kIG11bHRpcGxlIHZhbHVlcy4gSW4gdGhpcyBjYXNlLCBpdCBjaGFuZ2Vz IHRoZSBtZWFuaW5nIG9mIHRoZSBwYXJhbWV0ZXIuIEluc3RlYWQgb2YgdGhlIGNsaWVudCBmb3Jj aW5nIHRoZSBzZXJ2ZXIgdG8gdXNlIGEgcGFydGljdWxhciBtZXRob2QsIHRoZSBjbGllbnQgaXMg aW5mb3JtaW5nIHRoZSBzZXJ2ZXIgYWJvdXQgd2hhdCBtZXRob2RzIGl0IGNhbiBwZXJmb3JtLiBU aGlzIGFsbG93cw0KIHRoZSBzZXJ2ZXIgdG8gYXNzaWduIHRoZSBhcHByb3ByaWF0ZSBtZXRob2Qg YmFzZWQgb24gaXRzIG93biBwb2xpY3kuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIG5vdGUgdGhhdCB0aGlzIGZpZWxkLCBsaWtlIGFsbCBv dGhlcnMgaW4gwqcyLCByZXByZXNlbnRzIHR3byB0aGluZ3M6IHRoZSBjbGllbnQgdGVsbGluZyB0 aGUgc2VydmVyICZxdW90O0kgd2FudCB0byB1c2UgdGhpcyB2YWx1ZSBmb3IgdGhpcyBmaWVsZCZx dW90OywgYW5kIHRoZSBzZXJ2ZXIgdGVsbGluZyB0aGUgY2xpZW50ICZxdW90O3RoaXMgaXMgdGhl IHZhbHVlIHlvdSBoYXZlIGZvciB0aGlzIGZpZWxkJnF1b3Q7LiBJdCdzIG5vdCBleGFjdGx5DQog YSBuZWdvdGlhdGlvbiwgbW9yZSBsaWtlIG1ha2luZyBhIHBvbGl0ZSByZXF1ZXN0IHRvIGFuIGFi c29sdXRlIGRpY3RhdG9yIHdobyBoYXMgdGhlIGxhc3Qgd29yZCBhbnl3YXkuIEJ1dCBhdCBsZWFz dCB0aGlzIGRpY3RhdG9yIGlzIG5pY2UgZW5vdWdoIHRvIHRlbGwgeW91IHdoYXQgdGhlaXIgZGVj aXNpb24gd2FzIGluc3RlYWQgb2YganVzdCBkZWNhcGl0YXRpbmcgeW91LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGlzIHRoZSBoZWFydCBvZiBteSBvYmplY3Rpb24uIFRoaXMgZnV6emluZXNz IGlzIGlzIGdvaW5nIHRvIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIGZ1enppbmVzcyB0aGF0IEkgY2FuIHNlZSBo ZXJlLiBJdCdzIHBhcmFsbGVsaXNtIGJldHdlZW4gd2hhdCBnb2VzIGluIHRvIHRoZSBlbmRwb2lu dCBhbmQgd2hhdCBjb21lcyBvdXQgb2YgaXQuIFRoZSBzZW1hbnRpY3MgZm9yIHRoZSByZXF1ZXN0 IGFuZCB0aGUgcmVzcG9uc2UgYXJlIGRpZmZlcmVudCwgYW5kIGRpZmZlcmVudGlhYmxlIGJ5IHRo ZSBmYWN0IHRoYXQgb25lIGlzIGEgcmVxdWVzdA0KIGFuZCB0aGUgb3RoZXIgaXMgYSByZXNwb25z ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZXItb3AgaXNzdWUg SSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZSBzcGVjIGRvZXMgbm90IGN1cnJl bnRseSBzcGVjaWZ5IGlmIHBhcnRpY3VsYXIgaW5wdXQgdmFsdWVzIGFyZSBzaW5ndWxhciBvciBt dWx0aXBsZS4gJm5ic3A7SWYgYW4gaW1wbGVtZW50ZXIgYXNzdW1lcyBzaW5ndWxhciBhbmQgY2xp ZW50cyBhc3N1bWUgbXVsdGlwbGUsIHdlIGhhdmUgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDBCMDUwIj5UaGUgbXVsdGlwbGUvc2luZ2xlIGRpc2N1c3Npb24gYWJvdmUgZ2V0cyB0 byB0aGUgaGVhcnQgb2Ygd2hhdCBJICo8Yj5kbzwvYj4qIGJlbGlldmUgaXMgYSBkZWZpY2llbmN5 IGluIHRoZSBzcGVjaWZpY2F0aW9uLCBhcyBpdOKAmXMgY3VycmVudGx5IHdyaXR0ZW4uJm5ic3A7 IFRoZSBhdXRob3JzLA0KIG15c2VsZiBpbmNsdWRlZCwgaGF2ZSBmYWlsZWQgdG8gbWFrZSBpdCAx MDAlIGNsZWFyIHRoYXQgZGlzY292ZXJ5IG9mIEF1dGhvcml6YXRpb24gU2VydmVyIGZ1bmN0aW9u YWxpdHkgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHNwZWNpZmljYXRpb24uJm5ic3A7IEkgc3Ry b25nbHkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgdG8gYWRkIGEgY2xlYXIgc3RhdGVtZW50IHRvIHRo aXMgZWZmZWN0IGluIHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIHNwZWNpZmljYXRpb24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5UaGUgcHVycG9zZSBvZiB0aGUgRHlu YW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gaXMgZm9yIHRoZSBjbGllbnQg dG8gcmVnaXN0ZXIgd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRvIGluZm9ybSBp dCBvZiBwcm9wZXJ0aWVzIG9mIHRoZQ0KIGNsaWVudCB0aGF0IHRoZSBBUyBtYXkgd2FudC9uZWVk IHRvIGJlIGF3YXJlIG9mLiZuYnNwOyBJdCAqPGI+aXMgbm90PC9iPiogdGhlIHB1cnBvc2Ugb2Yg dGhpcyBzcGVjaWZpY2F0aW9uIGZvciBpdCB0byBiZSB1c2VkIGJ5IGNsaWVudHMgaW4gYW55IG1h bm5lciB0byBkaXNjb3ZlciBmZWF0dXJlcyBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuJm5i c3A7IFRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Q3VycmVudGx5LCBjbGllbnRzIGFyZSBpbnN0cnVj dGVkIGJ5IFJGQyA2NzQ5IHRvIGRpc2NvdmVyIGluZm9ybWF0aW9uIGFib3V0IEF1dGhvcml6YXRp b24gU2VydmVycyB0aGV5IGludGVyYWN0IHdpdGggYnkgY29uc3VsdGluZyB0aGUg4oCcPC9zcGFu PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZXJ2aWNlDQogZG9jdW1lbnRhdGlv bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+4oCdIChS RkMgNjc0OSwgU2VjdGlvbnMgMy4xIGFuZCAzLjIpLiZuYnNwOyBUaGV5IGNhbiBhbHNvIGxlYXJu IGluZm9ybWF0aW9uIGFib3V0IEF1dGhvcml6YXRpb24gU2VydmVycyBpbiBzcGVjaWZpYyBjb250 ZXh0cyB0aHJvdWdoIGRpc2NvdmVyeSBwcm90b2NvbHMgc3VjaCBhcyBPcGVuSUQNCiBDb25uZWN0 IERpc2NvdmVyeSAoPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5l Y3QtZGlzY292ZXJ5LTFfMC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+aHR0cDov L29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sPC9zcGFu PjwvYT4pIGFuZCBVTUEgRGlzY292ZXJ5IChUQkQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwQjA1MCI+SSBzdXNwZWN0IHRoYXQgYXQgc29tZSBwb2ludCwgc29tZW9uZSBpbiB0 aGUgT0F1dGggd29ya2luZyBncm91cCB3aWxsIHByb3Bvc2UgZGV2ZWxvcGluZyBhIGdlbmVyaWMg T0F1dGggZGlzY292ZXJ5IG1lY2hhbmlzbSwgd2hpY2ggd2lsbCBsZWFkIHRvIGEgcmVjaGFydGVy aW5nDQogdG8gaW5jbHVkZSB0aGlzIHdvcmsgaW4gdGhlIHdvcmtpbmcgZ3JvdXDigJlzIHNldCBv ZiBkZWxpdmVyYWJsZXMuJm5ic3A7IEkgd291bGQgc3VwcG9ydCBkb2luZyB0aGlzIHdvcmsgYW5k IHRoZSBuZWNlc3NhcnkgcmVjaGFydGVyaW5nIHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwQjA1MCI+VGhhdCBiZWluZyBzYWlkLCBJIHN0cm9uZ2x5IG9wcG9zZSB0 cnlpbmcgdG8gc2hvZWhvcm4gcGllY2VtZWFsIGFzcGVjdHMgb2YgZGlzY292ZXJ5IGludG8gdGhl IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJdCBpcyBk aXN0aW5jdCBmdW5jdGlvbmFsaXR5DQogYW5kIGRlc2VydmVzIGZpcnN0LWNsYXNzIGFuZCBzZXBh cmFibGUgdHJlYXRtZW50IGJ5IHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBEaXNjb3ZlcnkgaXMg Zm9yIHBvdGVudGlhbCBjbGllbnRzIHRvIGxlYXJuIHByb3BlcnRpZXMgb2YgdGhlIEFTIGJlZm9y ZSByZWdpc3RyYXRpb24uJm5ic3A7IFJlZ2lzdHJhdGlvbiBpcyBmb3IgcG90ZW50aWFsIGNsaWVu dHMgdG8gaW5mb3JtIHRoZSBBUyBvZiBpdHMgcHJvcGVydGllcywgY3JlYXRpbmcgYSByZWdpc3Rl cmVkIGNsaWVudC4mbmJzcDsNCiBEaXNjb3Zlcnkgc2VuZHMgaW5mb3JtYXRpb24gYWJvdXQgdGhl IEFTIHRvIHRoZSBDbGllbnQuJm5ic3A7IFJlZ2lzdHJhdGlvbiBzZW5kcyBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgQ2xpZW50IHRvIHRoZSBBUy4mbmJzcDsgVGhhdOKAmXMgYSBjbGVhbiBzZXBhcmF0 aW9uLiZuYnNwOyBXZSBzaG91bGQgc3Ryb25nbHkgcmVzaXN0IG11ZGR5aW5nIHRoZSB0d28gZnVu Y3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+T0F1dGggMi4w IGlzIGEgc3VjY2VzcyBiZWNhdXNlIGl0IGRpZG7igJl0IHRyeSB0byBib2lsIHRoZSBvY2Vhbi4m bmJzcDsgSXQgc3BlY2lmaWVkIGhvdyB0byBkbyBvbmUgdGhpbmcgd2VsbCBpbiBhIHNpbXBsZSwg d2ViLWZyaWVuZGx5IG1hbm5lci4mbmJzcDsgV2Ugc2hvdWxkIGRvIHRoZSBzYW1lDQog4oCTIGZv Y3VzaW5nIG9uIHNwZWNpZnlpbmcgaW50ZXJvcGVyYWJsZSBkeW5hbWljIGNsaWVudCByZWdpc3Ry YXRpb24sIHdoaWxlIG1ha2luZyBpdCBjbGVhciB0aGF0IHRoaXMgaXMgZGlzdGluY3QgZnJvbSBk aXNjb3ZlcnkgYWJvdXQgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcHJvcGVydGllcywgYW5kIG1ha2lu ZyBpdCBjbGVhciB0aGF0IGRpc2NvdmVyeSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29yay48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgYXBvbG9naXplIGF0IHRo aXMgcG9pbnQgb24gYmVoYWxmIG9mIG15c2VsZiBhbmQgdGhlIG90aGVyIHNwZWMgZWRpdG9ycyBm b3Igbm90IGJlaW5nIDEwMCUgY2xlYXIgdGhhdCBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSBpcyBl eHBsaWNpdGx5IG91dCBvZiBzY29wZSBmb3INCiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24u Jm5ic3A7IElmIHdlIGhhZCBkb25lIHNvLCBJ4oCZbSBzdXJlIHRoYXQgbWFueSBvZiB0aGUgY3Vy cmVudCBxdWVzdGlvbnMgYW5kIGNvbmZ1c2lvbnMgd291bGQgbm90IGhhdmUgYXJpc2VuLiZuYnNw OyBJIHRoaW5rIHdl4oCZZCBhc3N1bWVkIHRoYXQgdGhpcyB3YXMgb2J2aW91cywgYnV0IGZyb20g dGhlIGN1cnJlbnQgZGlzY3Vzc2lvbnMsIGl04oCZcyBhcHBhcmVudCB0aGF0IGl04oCZcyBub3Qg b2J2aW91cy4mbmJzcDsgSSB3aWxsIHBlcnNvbmFsbHkNCiBjb21taXQgdG8gY2xhcmlmeWluZyB0 aGUgc3BlY2lmaWNhdGlvbiBhdCB0aGlzIHBvaW50IHRvIGVsaW1pbmF0ZSB0aGlzIHBvdGVudGlh bCBwb2ludCBvZiBjb25mdXNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBC MDUwIj5HZXR0aW5nIGJhY2sgdG8gdGhlIHNwZWNpZmljcywgdGhlIG9ubHkgdXNlZnVsIHB1cnBv c2Ugb2YgYSBtdWx0aS12YWx1ZWQg4oCcPC9zcGFuPnRva2VuX2VuZHBvaW50X2NsaWVudF9hdXRo X21ldGhvZDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj7igJ0NCiBt ZW1iZXIgd291bGQgYmUgdG8gZW5hYmxlIHRoZSBjbGllbnQgdG8gZGlzY292ZXIgaW5mb3JtYXRp b24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRoZSBBUyBh ZnRlciB0aGUgcmVnaXN0cmF0aW9uIGhhZCBiZWVuIHBlcmZvcm1lZC4mbmJzcDsgQnV0IHRoYXQg aXMgYSBkaXNjb3ZlcnkgZnVuY3Rpb24sIGFuZCBzbyBzaG91bGQgYmUgcGFydCBvZiB0aGUgZGlz Y292ZXJ5IHdvcmsg4oCTIG5vdCB0aGlzIHNwZWNpZmljYXRpb24uJm5ic3A7DQogV2Ugc2hvdWxk IHJlc2lzdCBzaG9laG9ybmluZyBpbiBiaXRzIG9mIGRpc2NvdmVyeSBpbnRvIHRoaXMgc3BlY2lm aWNhdGlvbi4mbmJzcDsgSXQgKjxiPmlzPC9iPiogYSB3b3J0aHdoaWxlIHRvcGljLCBidXQgZGVz ZXJ2ZXMgZnVsbCBjb25zaWRlcmF0aW9uIGJ5IHRoZSB3b3JraW5nIGdyb3VwIGluIGl0cyBvd24g cmlnaHQuJm5ic3A7IFRoZXJlZm9yZSwgdGhpcyBtZW1iZXIgbXVzdCByZW1haW4gc2luZ2xlLXZh bHVlZCwgYW5kIGJlIGNsZWFybHkgc3BlY2lmaWVkDQogYXMgdGhlIG1ldGhvZCBieSB3aGljaCBh IGNsaWVudCBpbmZvcm1zIHRoZSBBUyB3aGljaCB0b2tlbiBlbmRwb2ludCBhdXRoZW50aWNhdGlv biBtZXRob2QgaXQgd2lsbCB1c2UuJm5ic3A7IEFueXRoaW5nIGVsc2Ugd291bGQgYmUgc2NvcGUg Y3JlZXAsIGFuZCByZXN1bHQgaW4gYW4gdW5uZWNlc3NhcmlseSBjb21wbGljYXRlZCBzcGVjaWZp Y2F0aW9uIGFuZCB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIGNsaWVudHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBUaGVyZSBpcyBubyBhdXRobiBtZXRob2QgZm9yICZxdW90O2NsaWVudF9z ZWNyZXRfc2FtbCZxdW90OyBvciAmcXVvdDtwcml2YXRlX2tleV9zYW1sJnF1b3Q7LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm9ib2R5IGhhcyByZWFsbHkgYXNrZWQgdGhhdCB0aGVzZSB0 d28gYmUgaW5jbHVkZWQgb3Igc3BlY2lmaWVkLiBUaGUgZXh0ZW5zaW9uIG1lY2hhbmlzbSAodXNp bmcgYW4gYWJzb2x1dGUgVVJJKSB3b3VsZCBhbGxvdyBzb21lb25lIGVsc2UgdG8gZGVmaW5lIHRo ZXNlLiBJcyB0aGUgZGVmaW5pdGlvbiBpbiB0aGUgU0FNTCBBc3NlcnRpb24gZHJhZnQgc3VmZmlj aWVudCBmb3IgdGhlaXIgdXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHRoaXMgaXMgY29taW5nIGZyb20gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIEpXVCBi ZWFyZXIgZHJhZnQgYW5kIGEgU0FNTCBiZWFyZXIgZHJhZnQuICZuYnNwO1RoZSB0cnV0aCBpcyB5 b3UgYXJlIGRlZmluaW5nIGFuIGF1dGhlbnRpY2F0aW9uIHRoYXQgaXNuJ3QgZXZlbiBkZWZpbmVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPlRoZXJlIGFyZSBubyBw cm9maWxlcyByZWZlcmVuY2VkIG9yIGRlZmluZWQgZm9yICZxdW90O2NsaWVudF9zZWNyZXRfand0 JnF1b3Q7IG9yICZxdW90O3ByaXZhdGVfa2V5X2p3dCZxdW90Oy4gTmVpdGhlciBvZiB0aGUgSldU IG9yIFNBTUwgQmVhcmVyIGRyYWZ0cyByZWZlcmVuY2VkIGNvdmVyIHRoZXNlIHR5cGVzIG9mIGZs b3dzLiBUaGV5IG9ubHkgY292ZXIgYmVhcmVyIGZsb3dzLiAmbmJzcDsmcXVvdDtjbGllbnRfc2Vj cmV0X2p3dCZxdW90OyBhbmQgJnF1b3Q7cHJpdmF0ZV9rZXlfand0JnF1b3Q7DQogc2VlbSB0byBo YXZlIHNvbWUgbWVhbmluZyB3aXRoaW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJIG5vdGUgdGhhdCBP SURDIGRvZXMgbm90IGZ1bGx5IGRlZmluZSB0aGVzZSBlaXRoZXIuPC9pPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIEpXVCBhc3NlcnRpb24gZHJhZnQgZG9lcyBzYXkgaG93IHRvIHVz ZSBhIEpXVCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCBhbmQgdGhlIER5blJlZyB0ZXh0IGRp ZmZlcmVudGlhdGVzIGJldHdlZW4gYSBjbGllbnQgc2lnbmluZyBzYWlkIEpXVCB3aXRoIGl0cyBv d24gc2VjcmV0IHN5bW1ldHJpY2FsbHkgdnMuIGEgY2xpZW50IHVzaW5nIGl0cyBvd24gcHJpdmF0 ZSBrZXksIGFzeW1tZXRyaWNhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWN0dWFsbHkgbXkgaW50ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1 bWVzIHRoZSBKV1QgQmVhcmVyIGlzIGEgYmVhcmVyIHRva2VuLiAmbmJzcDtUaGUgYXNzdW1wdGlv biBpcyB0aGF0IGlmIGEgY2xpZW50IGhhcyB0aGUgYXNzZXJ0aW9uIGl0IGhhcyB0aGUgcmlnaHQg dG8gcHJlc2VudCBpdC4gJm5ic3A7SU9XLiBUaGUgSldUIEJlYXJlciBEcmFmdCBpcyBtb3N0IGRl ZmluaXRpdmVseSBub3QgYSBKV1QgSG9LIERyYWZ0Lg0KICZuYnNwOzotKTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZGxlc3MsIHlvdSBhcmUgaW50cm9kdWNpbmcgYSBuZXcgcHJvZmlsZSB3aGlj aCBpcyB1bmRlZmluZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBJIHNlZSB0aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFr aW5nIG5vdywgbGV0IG1lIHRyeSB0byByZS1zdGF0ZSBpdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGlsZSB0aGUgYmFzaWNzIG9mICZxdW90O2hvdyB0byBwcmVzZW50IGEgSldUIGFzIGEgY2xpZW50 IGNyZWRlbnRpYWwmcXVvdDsgaXMgZGVmaW5lZCBoZXJlOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUuaHRtbCNyZmMu c2VjdGlvbi4yLjIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWp3 dC1iZWFyZXItMDUuaHRtbCNyZmMuc2VjdGlvbi4yLjI8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiwNCiBpdCdzIG5vdCBjb21wbGV0ZWx5IHNwZWNp ZmllZCBpbiB0aGF0IGl0IGRvZXNuJ3QgZnVsbHkgcmVzdHJpY3QgdGhlIHNpZ25hdHVyZSBzZWNy ZXQgc291cmNlLCB0aGUgYXVkaWVuY2UgY2xhaW0sIGFuZCBvdGhlciB0aGluZ3MgdGhhdCB0aGUg QVMgd291bGQgbmVlZCB0byBjaGVjayBhbmQgdmFsaWRhdGUuIFJpZ2h0PyBUaGUgZHluYW1pYyBy ZWdpc3RyYXRpb24gZHJhZnQgY2FuIGRlZmluZSB0aG9zZSBjYXNlcyBpbiBncmVhdGVyIGRldGFp bCBpZg0KIG5lZWRlZCAodGhvdWdoIEkgdGhpbmsgaXQgZG9lcyBzbyBzdWZmaWNpZW50bHkgYXMt aXMsIEkgd2VsY29tZSBtb3JlIGNsYXJpdHkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBP SyB3aXRoIGFkZGluZyB0aGUgU0FNTCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwgb24g dGhlIEpXVCBiaXRzLCBvciBkcm9wcGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50cyB0 byBkbyBhbnkgb2YgdGhvc2UgYWN0aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpXVCBz dHVmZiBpcyBhbHJlYWR5IGluIHVzZSBhbmQgZnVuY3Rpb25pbmcgYW5kIGl0J2QgYmUgYSBzaGFt ZQ0KIHRvIGxlYXZlIGl0IG91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNz IHRoZW4gdGhlIG1pc3Rha2UgdGhlIEpXVCBCZWFyZXIgYW5kIFNBTUwgQmVhcmVyIGRyYWZ0cyBh dXRob3JzIG1hZGUgaXMgdGhleSBhc3N1bWVkIGV2ZXJ5b25lIGhhZCB0aGUgc2FtZSBkZWZpbml0 aW9uIG9mIGJlYXJlciB0b2tlbi4gJm5ic3A7VG8gbWUgYSBiZWFyZXIgdG9rZW4gb3BhcXVlIHRv IHRoZSBjbGllbnQuIEl0IHRoZXJlZm9yZSBjYW5ub3QgZG8gYW55IHNpZ25hdHVyZSB3b3JrIHdp dGggcmVnYXJkcw0KIHRvIHRoZSB0b2tlbiBpdHNlbGYuICZuYnNwO05vdywgdGhhdCdzIG5vdCB0 byBzYXkgYSBwcm9vZiBkaWRuJ3Qgb2NjdXIgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgdG9r ZW4gaXNzdWVyLCBidXQgd2hlbiB0aGUgY2xpZW50IHdpZWxkcyB0aGUgdG9rZW4sIGl0IGlzIGhh bmRsaW5nIGFuIG9wYXF1ZSBzdHJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbmNlcHQg b2YgY2xpZW50X3NlY3JldF9qd3Qgc3VnZ2VzdHMgYW4gSG9LIHByb2ZpbGUuICZuYnNwO1RoZXJl Zm9yZSBvZiBjb3Vyc2UgdGhlIGJlYXJlciBkcmFmdHMgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lm aWVkIHdoZW4gaXQgY29tZXMgdG8gSG9LIHByb2ZpbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNv IGZvciBleGFtcGxlLCB5b3UgbmVlZCBhIGRyYWZ0IGxpa2UgdGhlIE1BQyBkcmFmdCBmb3IgdGhp cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaGF2aW5nIHRyb3VibGUgb3ZlcmFsbCBo ZXJlLiBJdCBzZWVtcyB0aGUgYXV0aG4gdHlwZXMgc3VnZ2VzdCBPTkxZIHN0cm9uZyBhdXRoZW50 aWNhdGlvbiBmb3IgY2xpZW50cywgeWV0IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mg dGhlIGN1cnJlbnQgZHJhZnQgaXNuJ3QgYWJsZSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIHNvZnR3YXJlIChldmVuIGluIGEgc2VsZi1hc3NlcnRlZA0KIHdheSku ICZuYnNwO0lmIHlvdSBoYXZlbid0IGF1dGhlbnRpY2F0ZWQgdGhlIHNvZnR3YXJlIGF0IGFsbCwg d2h5IGhhdmUgc3Ryb25nIGNsaWVudCBhdXRoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBubyBhdXRoZW50aWNhdGlvbiBtZXRob2QgZGVmaW5l ZCBmb3IgJnF1b3Q7Y2xpZW50X2JlYXJlcl9zYW1sJnF1b3Q7IG9yICZxdW90O2NsaWVudF9iZWFy ZXJfand0JnF1b3Q7IG9yICZxdW90O2NsaWVudF9iZWFyZXJfcmVmJnF1b3Q7LiAmbmJzcDtTaW5j ZSB0aGUgYmVhcmVyIHNwZWNzIHNheSB0aGlzIGlzIGFjY2VwdGFibGUsICZuYnNwO3RoZSBkeW5h bWljIHJlZ2lzdHJhdGlvbiBzcGVjIHNob3VsZCBhY2NlcHQgdGhlc2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBiaXQgLS0gd2hlcmUgYXJlIHRo ZXNlIGRlZmluZWQgaW4gUkZDNjc1MD8gSSBkb24ndCBldmVuIGtub3cgd2hhdCBjbGllbnRfYmVh cmVyX3JlZiB3b3VsZCByZWZlciB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Njc1MCBzYXlzIHlvdSBjYW4gdXNlIGEgYmVhcmVyIGFzc2VydGlvbiAoZS5nLiBvYnRhaW5l ZCBmcm9tIGFuIElEUCkgYW5kIHdpZWxkIGl0IGFzIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlv bi4gJm5ic3A7VGhlIGNsaWVudCBpcyBOT1QgY3JlYXRpbmcgb3IgbW9kaWZ5aW5nIHRoZSBhc3Nl cnRpb24uIFRoZSBjbGllbnQgaXMgc2ltcGx5IHBhc3Npbmcgb25lIGl0IHByZXZpb3VzbHkgb2J0 YWluZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgbm90 IGJlYXJlci4gSXQgaXMgaG9sZGVyIG9mIGtleS4gVmVyeSB2ZXJ5IGRpZmZlcmVudC4mbmJzcDs8 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BIHBvc3NpYmxlIHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlIGNsaWVudF9zZWNyZXRfand0IGFu ZCBwcml2YXRlX2tleV9qd3QgYW5kIGRlZmluZSB0aG9zZSBhcyByZWdpc3RlciBleHRlbnNpb25z IHNpbmNlIHRoZXNlIHByb2ZpbGVzIGFyZSBub3QgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYXQncyBwb3NzaWJsZSwgYnV0IHRoZXkgYXJlIGluIGFjdGl2ZSB1c2UgYWxy ZWFkeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBtYXkgYmUgdHJ1ZS4gQnV0IHRo ZW4geW91IG5lZWQgdG8gd3JpdGUgYW5vdGhlciBkcmFmdCBzbyB0aGUgcmVzdCBvZiB1cyBjYW4g aW1wbGVtZW50IGl0IGluIGFuIGludGVyb3BlcmFibGUgd2F5LiAmbmJzcDtNZSBJIHByZWZlciBu b3QgdG8gZ3Vlc3Mgd2hhdCB5b3UgYXJlIGRvaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG11Y2ggSSBhZ3JlZSB3aXRoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5KdXN0aW4sIEpvaG4sIGFuZCBJIGRpc2N1c3NlZCB0 aGlzIGlzc3VlIGFuZCBhZ3JlZSB3aXRoIHlvdXIgc3VnZ2VzdGlvbiwgUGhpbC4mbmJzcDsgU2lu Y2UgdGhleSBhcmUgbm90IGNvbXBsZXRlbHkgc3BlY2lmaWVkLCB3ZSB3aWxsIHJlbW92ZSB0aGUg Y2xpZW50X3NlY3JldF9qd3QNCiBhbmQgcHJpdmF0ZV9rZXlfand0IG1ldGhvZHMgZnJvbSB0aGUg c3BlY2lmaWNhdGlvbiBhbmQgYWRkIGEgcmVnaXN0cnksIGVuYWJsaW5nIHNwZWNpZmljYXRpb24g dGhhdCBkbyBmdWxseSBzcGVjaWZ5IHRoZXNlIGFuZCBvdGhlciB0b2tlbiBlbmRwb2ludCBhdXRo ZW50aWNhdGlvbiBtZXRob2RzLCBpbmNsdWRpbmcgcG90ZW50aWFsIG1ldGhvZHMgdXNpbmcgU0FN TCBhc3NlcnRpb25zLCB0byByZWdpc3RlciB0aGVtIGluIHRoZSByZWdpc3RyeSwNCiByYXRoZXIg dGhhbiB0cnlpbmcgdG8gYmFrZSB0aGVtIGludG8gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJh dGlvbiBzcGVjaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkFib3V0ICZxdW90O3Rvc191 cmkmcXVvdDsgYW5kICZxdW90O3BvbGljeV91cmkmcXVvdDs8L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdG9zX3VyaSBhbmQgcG9saWN5X3VyaSBpcyB1bmNs ZWFyLiAmbmJzcDtDYW4gd2UgY2xhcmlmeSBvciBjb21iaW5lIHRoZW0/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UZXJtcyBvZiBzZXJ2aWNlIGFuZCBwb2xpY3kgYXJlIHR3byBkaWZmZXJl bnQgZG9jdW1lbnRzLiBPbmUgaXMgc29tZXRoaW5nIHRoYXQgYSB1c2VyIGFjY2VwdHMgKGdlbmVy YWxseSBkZXNjcmliaW5nIHdoYXQgdGhlIHVzZXIgd2lsbCBkbyksIG9uZSBpcyBhIHN0YXRlbWVu dCBvZiB3aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChpbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQp IHdpbGwgZG8uIE1vcmUgaW1wb3J0YW50bHksDQogd2UgdXNlZCB0byBoYXZlIG9ubHkgb25lLCBh bmQgc2V2ZXJhbCBwZW9wbGUgYXNrZWQgZm9yIHRoZW0gdG8gYmUgc3BsaXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNldmVyYWwgZGV2ZWxvcGVycyB3ZXJlIGNvbmZ1c2Vk IGJ5IHRoaXMuIEluIHBhcnRpY3VsYXIgdGhleSBjb3VsZG4ndCBmaWd1cmUgb3V0IHdoaWNoIHdh cyB1c2VkIGZvciB3aGF0LiAmbmJzcDtKdXN0IHBhc3NpbmcgYWxvbmcgdGhlIGZlZWRiYWNrLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgdGhlIGRpc3RpbmN0aW9uIHRo YXQgSSBzZWUgaXMgdGhhdCB0aGUgVE9TIGlzIGNvbnRyYWN0dWFsLCB0aGUgUG9saWN5IGlzIGEg c3RhdGVtZW50LiBSZS1yZWFkaW5nIHRoZSBkZWZpbml0aW9ucyBpbiB0aGVyZSByaWdodCBub3cs IHRoYXQgY2FuIGJlIG1hZGUgbXVjaCBjbGVhcmVyLiAoSXQgZXZlbiBsb29rcyBsaWtlIHNvbWUg T0lEQyB0ZXh0IGxlYWtlZCBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIHBvbGljeV91cmkNCiBhbmQg dGhhdCBoYWRuJ3QgYmVlbiBjYXVnaHQgeWV0Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+SSBzdXBwb3J0IGNsYXJpZnlpbmcgdGhlIGxhbmd1YWdlIG9uIHRoZXNlIGRl ZmluaXRpb25zLCBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIHRvIGRvIHNvLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIGFyZW4ndCB0aGVzZSByZWFsbHkgVVJJcyBv ciBhcmUgdGhleSBtZWFudCB0byBiZSBVUkxzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlcmUgd2FzIGFscmVhZHkgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRoZSBsaXN0OiBUaGUg SUVURiBpcyBhcHBhcmVudGx5IHRyeWluZyB0byBkZXByZWNhdGUgVVJMIGluIGZhdm9yIG9mIFVS SSBpbiBuZXcgc3BlY3MuIFNvIGluIHByYWN0aWNlIHRoZXknbGwgbmVhcmx5IGFsd2F5cyBiZSBV UkxzLCBidXQgc2luY2UgYWxsIFVSTHMgYXJlIFVSSXMgd2UncmUgbm90IHRlY2huaWNhbGx5IGlu Y29ycmVjdA0KIGluIGZvbGxvd2luZyB0aGUgbmV3IHBvbGljeS4gQW5kIGl0IG1ha2VzIHRoZSBJ RVNHIGxlc3MgbWFkIGF0IHVzLCB3aGljaCBpcyBhIHBsdXMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFyZy4gTmljZS4gJm5ic3A7VGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5 IHRoZSB2YWx1ZSBwYXNzZWQgbXVzdCByZXNvbHZlIHRvIGEgdmFsaWQgd2ViIHBhZ2UsIGRvY3Vt ZW50LCB3aGF0ZXZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdz IGZhaXIsIGFuZCBpdCdzIHNvbWV0aGluZyB0aGF0IHRoZSBBUyBjYW4gZXZlbiBjaGVjayBpZiBp dCB3YW50cyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+QWdyZWVk IG9uIHRoaXMgY2xhcmlmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5BYm91dCAmcXVvdDtqd2tzX3VyaSZxdW90OzwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B IG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNw YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wOSI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wOTwvYT4mbmJzcDtp cw0KIG5lZWRlZC4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzLCB5b3UncmUgY29ycmVjdCwgSSdsbCBhZGQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgYmUgVVJMIGluc3RlYWQgb2YgVVJJ PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIGFib3ZlLiA6KTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5BZ3JlZWQgb24gYWRkaW5nIHRo aXMgcmVmZXJlbmNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TZWN0 aW9uIDIuMTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgdGFibGUmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOmdy YW50LXR5cGU6and0LWJlYXJlcjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMg bWlzc2luZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3MgdGhlcmUgaW4gdGhlIGNv cHkgb2YgLTEwIEknbSByZWFkaW5nIG9mZiBvZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vaWV0Zi5vcmcvIj5pZXRmLm9yZzwv YT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cmlnaHQg bm93IOKApiA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPic8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBJIG1lYW50OiZu YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij51cm46aWV0ZjpwYXJh bXM6b2F1dGg6Z3JhbnQtdHlwZTpzYW1sLWJlYXJlcjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFoLCB0aGF0IG1ha2VzIG1vcmUgc2Vuc2UuIElmIHRo ZSBXRyB3YW50cyB0byBhZGQgaW4gU0FNTCBzdXBwb3J0IHRvIHBhcmFsbGVsIHRoZSBKV1Qgc3Vw cG9ydCwgSSdkIGJlIE9LIHdpdGggdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxBcyBzdWNoLCBhIHNlcnZlciBzdXBwb3J0aW5nIHRo ZXNlIGZpZWxkcyBTSE9VTEQgdGFrZSBzdGVwcyZuYnNwO3RvIGVuc3VyZSB0aGF0IGEgY2xpZW50 IGNhbm5vdCByZWdpc3RlciBpdHNlbGYgaW50byBhbiBpbmNvbnNpc3RlbnQgc3RhdGUu4oCdPGJy Pg0KPGJyPg0KV2UgbWF5IHdhbnQgdG8gZGVmaW5lIG1vcmUgZGV0YWlsZWQgSFRUUCBlcnJvciBy ZXNwb25zZS4mbmJzcDtFLmcuIDQwMCBzdGF0dXMgY29kZSAmIzQzOyBkZWZpbmVkIGVycm9yIGNv ZGUgKOKAnGludmFsaWRfY2xpZW50X21ldGFkYXRh4oCdKT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkknZCBiZSBmaW5lIHdpdGggZGVmaW5pbmcgYSBtb3JlIGV4cGxpY2l0IGVycm9yIHN0 YXRlIGluIHRoaXMgY2FzZS4gSSB0aGluayBpdCB3b3VsZCBoZWxwIGludGVyb3AgZm9yIHRoZSBz ZXJ2ZXJzIHRoYXQgd2FudCB0byBlbmZvcmNlIGdyYW50LXR5cGUgYW5kIHJlc3BvbnNlLXR5cGUg cmVzdHJpY3Rpb25zLCBidXQgc2VydmVycyB0aGF0IGNhbid0IG9yIGRvbid0IGNhcmUgYWJvdXQg cmVzdHJpY3RpbmcgZ3JhbnRzDQogdHlwZXMgYW5kIHdoYXRub3QgZG9uJ3QgaGF2ZSB0byBkbyBh bnl0aGluZyBzcGVjaWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDBCMDUwIj5JICo8Yj50aGluazwvYj4qIHRoYXQgdGhpcyBnb2VzIGF3YXkgd2l0aCB0aGUg ZGVsZXRpb24gb2YgY2xpZW50X3NlY3JldF9qd3QgYW5kIHByaXZhdGVfa2V5X2p3dCBpbiBmYXZv ciBvZiB0aGUgcmVnaXN0cnnigKYmbmJzcDsgSeKAmWxsIGRvIGEgY29uc2lzdGVuY3kgY2hlY2sg YW5kIHZlcmlmeQ0KIHRoYXQgd2hlbiB0aGUgc3BlYyBpcyB1cGRhdGVkIGFjY29yZGluZ2x5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5TZWN0 aW9uIDIuMjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPk1heSB3YW50 IHRvIGFkZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoZW4mbmJzcDvigJwj4oCdIGxhbmd1YWdlIHRhZyBpcyBtaXNzaW5n LCAoZS5nLiDigJwjZW7igJ0gaXMgbWlzc2luZyBpbiDigJxjbGllbnRfbmFtZeKAnSwgaW5zdGVh ZCZuYnNwO29mIOKAnGNsaWVudF9uYW1lI2Vu4oCdKSB0aGUgT0F1dGggc2VydmVyIG1heSB1c2Ug aW50ZXJwcmV0IHRoZSZuYnNwO2xhbmd1YWdlIHVzZWQgYmFzZWQmbmJzcDtvbiBzZXJ2ZXIgY29u ZmlndXJhdGlvbiBvciBoZXVyaXN0aWNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzZWVtcyBp bmNvbnNpc3RlbnQgd2l0aCB3aGF0IHdlIGFscmVhZHkgaGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklmIGFueSBodW1hbi1yZWFkYWJsZSBmaWVsZCBpcyBzZW50IHdpdGhvdXQg YSBsYW5ndWFnZSB0YWcsIHBhcnRpZXMgdXNpbmcgaXQgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1w dGlvbnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFyYWN0ZXIgc2V0LCBvciBzY3JpcHQgb2YgdGhl IHN0cmluZyB2YWx1ZSwgYW5kIHRoZSBzdHJpbmcgdmFsdWUgTVVTVCBiZSB1c2VkIGFzLWlzIHdo ZXJldmVyIGl0IGlzIHByZXNlbnRlZA0KIGluIGEgdXNlciBpbnRlcmZhY2UuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hp Y2ggaXMgdG8gc2F5LCB0cmVhdCBpdCBhcyBhIHJhdyBieXRlLXZhbHVlLXN0cmluZyBhbmQgZG9u J3QgdHJ5IHRvIGdldCBmYW5jeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBkaXNjdXNzIHdpdGggb3VyIGRldmVsb3BlcnMuIEknbSBu b3Qgc3VyZSB0aGUgYXMtaXMgd29ya3MuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0 IHRoZSBpbnRlbnQgdGhhdCB3aGVuIHRoZSBjbGllbnQgaGFzIGxvY2FsaXplZCAmcXVvdDtjbGll bnRfbmFtZSZxdW90OyBmb3IgZXhhbXBsZSwgaXQgc2hvdWxkIHBhc3MgYWxsIGxhbmd1YWdlIHZh cmlhdGlvbnMgaW4gYSBKU09OIGFycmF5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yLCBzaG91bGQg cGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIGJlIHRvIGluZGljYXRlIHdoaWNoIGludGVyZmFjZSBs YW5ndWFnZSB0aGUgY2xpZW50IHdpc2hlcyB0byB1c2U/ICZuYnNwO1RoZW4gaXQgb25seSBwYXNz ZXMgYSBzaW5nbGUgdmFsdWUgZm9yIHRoYXQgcmVnaXN0cmF0aW9uPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ObywgdGhlIGNsaWVudCBzaG91bGQgcGFzcyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNl cGFyYXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhpcyBpbiBpdHMgZXhhbXBsZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 ICZxdW90O2NsaWVudF9uYW1lJnF1b3Q7OiAmcXVvdDtNeSBFeGFtcGxlJnF1b3Q7LDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgJnF1 b3Q7Y2xpZW50X25hbWUjamEtSnBhbi1KUCZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Ozxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOCr+ODqeOCpOOC ouODs+ODiOWQjTwvc3Bhbj4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCB3ZSBh ZGQgdGhhdCB0byBhdCBsZWFzdCBvbmUgb2YgdGhlIGV4YW1wbGVzIGluIER5blJlZz8gKFRoZSBs YW5ndWFnZSB0YWdzIGFyZSBhIGxhdGUgYWRkaXRpb24sIHNvIHRoZSBleGFtcGxlcyBkb24ndCBy ZWZsZWN0IGl0Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBleGFtcGxlIHdvdWxkIGRlZmluaXRlbHkgaGVscC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBjbGllbnQgcGFzc2VzIG9ubHkgYSBzaW5nbGUg dW5hZG9ybmVkIGZpZWxkLCB0aGUgQVMgY2FuJ3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB3 aGF0IGxhbmd1YWdlIGl0IGlzLiBUaGluayBvZiB0aGlzIGFzIHRoZSBpbnRlcm5hdGlvbmFsaXpl ZCB2YWx1ZSBvZiB0aGUgZmllbGQgd2hpbGUgdGhlIGxhbmd1YWdlIHRhZ3MgYXJlIHRoZSBsb2Nh bGl6ZWQgdmVyc2lvbnMgb2YgdGhlIGZpZWxkLiBUaGlzDQogaXMgd2h5IHdlIHJlY29tbWVuZCB0 aGF0IHRoZSBiYXJlLXZhbHVlIGFsd2F5cyBiZSBzZW50IGJ5IHRoZSBjbGllbnQsIHNvIHRoYXQg aW4gdGhlIGxhY2sgb2YgYW55dGhpbmcgbW9yZSBzcGVjaWZpYywgdGhlIEFTIGNhbiBhdCBsZWFz dCBkbyAqc29tZXRoaW5nKiB3aXRoIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc3NpbmcgaW4g YSAmcXVvdDtkZWZhdWx0JnF1b3Q7IGxhbmd1YWdlIGZpZWxkIChsaWtlIGRlZmF1bHRfbG9jYWxl IG9yIHRoZSBsaWtlKSBpcyBvbmx5IGdvaW5nIHRvIGxlYWQgdG8gcGFpbiBmb3IgaW1wbGVtZW50 b3JzIG9mIGJvdGggY2xpZW50cyBhbmQgc2VydmVycywgYW5kIGl0J3MgZ29pbmcgdG8gaHVydCB0 aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgaHVtYW4tcmVhZGFibGUgZmllbGRzLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgd2hhdCBJIG1lYW50IGlzIHNpbmNlIHlvdSBhcmUgYWxsb3dpbmcgZWFjaCBjbGll bnQgdG8gcmVnaXN0ZXIgZGlmZmVyZW50IHRoaW5ncywgQU5EIHRoZSBjbGllbnQgbGlrZWx5IGFs cmVhZHkga25vd3MgdGhlIHVzZXIncyBwcmVmZXJyZWQgbGFuZ3VhZ2UsIHdoeSB3b3VsZG4ndCB0 aGUgY2xpZW50IGp1c3QgcGFzcyB0ZXh0IHZhbHVlcyBpbiBvbmUgbGFuZ3VhZ2UgYW5kIGFub3Ro ZXIgcGFyYW1ldGVyDQogaW5kaWNhdGluZyBwcmVmZXJyZWQgbGFuZ3VhZ2UgaW4gdGhlIGNhc2Ug b2YgYW55IHNlcnZpY2UgZ2VuZXJhdGVkIHRleHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhl IHJlYXNvbiB5b3UgYXJlIHBhc3NpbmcgbXVsdGlwbGUgbG9jYWxpemF0aW9ucyBpcyBzbyB0aGF0 IHlvdSBjYW4gdXNlIHRoZSBwcmVmZXJyZWQgbGFuZ3VhZ2Ugb2YgdGhlIHJlc291cmNlIG93bmVy IHJhdGhlciB0aGVuIHRoZSBjbGllbnQgdXNlcj8gSSB3b25kZXIgaWYgdGhhdCBpcyBjb3JyZWN0 LiAmbmJzcDtJZiB0aGUgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgYXJlIGluIGZhY3QgZGlmZmVyZW50 LCB3aGF0DQogd291bGQgdGhlIHVzZXIgb2YgdGhlIGNsaWVudCBhcHAgZXhwZWN0PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tLS0mZ3Q7IGFueSBtdWx0aS1saW5ndWFsIHBlb3BsZSBoYXZlIGFueSBv cGluaW9ucyBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+V2l0aG91dCBzcGVjaWZpYyBwcm9wb3NlZCB0ZXh0IGNoYW5nZXMgdG8gcmV2 aWV3LCBpdOKAmXMgaGFyZCB0byBrbm93IHdoYXQgdG8gdGhpbmsgYWJvdXQgdGhpcyBjb21tZW50 LiZuYnNwOyBVbmxlc3MgYSBzcGVjaWZpYyBwcm9wb3NlZCB0ZXh0IGNoYW5nZSBpcyBzZW50IHRv IHRoZQ0KIGxpc3Qgd2l0aCBjbGVhciByYXRpb25hbGUgZm9yIHdoeSBpdOKAmXMgYmV0dGVyIHRo YW4gd2hhdOKAmXMgdGhlcmUgbm93IGFuZCByZXZpZXdlZCBieSB0aGUgd29ya2luZyBncm91cCwg SSBkb27igJl0IGJlbGlldmUgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgc3BlY2lmaWNhdGlvbiBpbiBy ZXNwb25zZSB0byB0aGlzIGNvbW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+U2VjdGlvbiAz PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4aXN0aW5nIHRleHQ6PGJyPg0KPGJyPg0K4oCcSW4g b3JkZXIgdG8gc3VwcG9ydCBvcGVuIHJlZ2lzdHJhdGlvbiBhbmQgZmFjaWxpdGF0ZSB3aWRlciZu YnNwO2ludGVyb3BlcmFiaWxpdHksIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50Jm5i c3A7U0hPVUxEJm5ic3A7YWxsb3cgaW5pdGlhbCByZWdpc3RyYXRpb24mbmJzcDtyZXF1ZXN0cyB3 aXRoIG5vJm5ic3A7YXV0aGVudGljYXRpb24uJm5ic3A7Jm5ic3A7VGhlc2UgcmVxdWVzdHMgTUFZ IGJlJm5ic3A7cmF0ZS1saW1pdGVkIG9yIG90aGVyd2lzZSBsaW1pdGVkIHRvIHByZXZlbnQgYSBk ZW5pYWwtb2Ytc2VydmljZQ0KIGF0dGFjayBvbiB0aGUmbmJzcDtDbGllbnQmbmJzcDtSZWdpc3Ry YXRpb24gRW5kcG9pbnQu4oCdPGJyPg0KPGJyPg0KSSB3b3VsZCBzdWdnZXN0IHRvIGNoYW5nZSB0 aGUgZmlyc3Qg4oCcU0hPVUxE4oCdIHRvIOKAnE1BWeKAnS4mbmJzcDsgJm5ic3A7SW4gbW9zdCBj bG91ZCBzZXJ2aWNlcywgdGhlIGZpcnN0IGNsaWVudCBpcyZuYnNwO3JlZ2lzdGVyZWQgYnkgYSBo dW1hbiB1c2VyLiBUaGVuLCBvdGhlciZuYnNwO2NsaWVudHMgY2FuIGJlIGZ1cnRoZXIgdXNlZCB0 byBhdXRvbWF0ZSZuYnNwO290aGVyIGNsaWVudCByZWdpc3RyYXRpb24uJm5ic3A7Jm5ic3A7U28s IHRoZSBmaXJzdCZuYnNwO3JlcXVlc3Qgd291bGQgdHlwaWNhbGx5IGNvbWUgd2l0aA0KIGFuIGF1 dGhlbnRpY2F0ZWQgdXNlciBpZGVudGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgdGhlIHdlaWdodCBvZiAmcXVvdDtTSE9VTEQmcXVvdDsgaXMgYXBwcm9wcmlhdGUgaGVyZSwg YmVjYXVzZSBJIGJlbGlldmUgdGhhdCB0dXJuaW5nIG9mZiBvcGVuIHJlZ2lzdHJhdGlvbiBhdCB0 aGUgQVMgKHdoaWNoIGlzIHdoYXQgdGhpcyBpcyB0YWxraW5nIGFib3V0KSByZWFsbHkgb3VnaHQg dG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRoZXIgdGhhbiB0aGUgcnVsZS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3UgYXJlIHJlYWRpbmcgaXQgd3Jv bmcgLS0gYSBkb3VibGUtbmVnYXRpdmUgaXNzdWUuIFRoZSBlbmQgb2YgdGhlIHNlbnRlbmNlIGlz ICZxdW90O25vIGF1dGhlbnRpY2F0aW9uJnF1b3Q7LiAmbmJzcDtZb3UgYXJlIGltcGx5aW5nIHRo YXQgTk8gQXV0aGVudGljYXRpb24gdXMgd2hhdCBzaG91bGQgbm9ybWFsbHkgYmUgZG9uZS4gSSB0 aGluayB5b3UgaW50ZW5kIGFub255bW91cyBhdXRoZW50aWNhdGlvbiB0byBiZSB0aGUNCiBleGNl cHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUgZG9uJ3QgeW91PzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ObywgSSB0aGluayB0aGF0IGFub255bW91cyBhdXRoZW50aWNhdGlv biBzaG91bGQgYmUgdGhlIHJ1bGUuIE9wZW4gcmVnaXN0cmF0aW9uIHNob3VsZCBiZSBkZWZhdWx0 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBkaXNhZ3JlZS4gJm5ic3A7QWdhaW4sICZuYnNwO3RoZSBzcGVjIHNlZW1zIGNv bnRyYWRpY3RvcnkuIEl0IHN1Z2dlc3RzIHN0cm9uZyBjbGllbnQgYXV0aCBtZXRob2RzIGFuZCBh dCB0aGUgc2FtZSB0aW1lIGFub255bW91cyByZWdpc3RyYXRpb24uICZuYnNwO1llcyB5b3UgZ2Fp biB1bmlxdWVuZXNzLCBidXQgdGhhdCdzIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIHRoZSBmbGlwIHNpZGUsIHRoZSBl YXJsaWVyIHBhcmFncmFwaDo8YnI+DQo8YnI+DQrigJxUaGUgQ2xpZW50IFJlZ2lzdHJhdGlvbiBF bmRwb2ludCZuYnNwO01BWSZuYnNwO2FjY2VwdCBhbiBpbml0aWFsIGF1dGhvcml6YXRpb24gY3Jl ZGVudGlhbCBpbiB0aGUgZm9ybSBvZiBhbiBPQXV0aCAyLjAmbmJzcDtbUkZDNjc0OV0gYWNjZXNz IHRva2VuIGluIG9yZGVyIHRvJm5ic3A7bGltaXQgcmVnaXN0cmF0aW9uIHRvIG9ubHkgcHJldmlv dXNseSZuYnNwO2F1dGhvcml6ZWQgcGFydGllcy4gVGhlIG1ldGhvZCBieSB3aGljaCB0aGlzIGFj Y2VzcyB0b2tlbiBpcyBvYnRhaW5lZCBieSB0aGUmbmJzcDtyZWdpc3RyYW50DQogaXMgZ2VuZXJh bGx5IG91dC1vZi1iYW5kIGFuZCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9u LuKAnTxicj4NCjxicj4NCkkgdGVuZCB0byB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hh bmdlIHRoaXMg4oCcTUFZ4oCdIHRvIOKAnFNIT1VMROKAnS48YnI+DQo8YnI+DQpUaGF0IGFjY2Vz cyB0b2tlbiB3b3VsZCBjYXJyeSBhIGh1bWFuIHVzZXIgYXV0aGVudGljYXRlZCZuYnNwO2lkZW50 aXR5IHNvbWVob3cuIEluIHNvbWUgY2FzZXMsIGl0IGNhbiBiZSBhIHB1cmUgYXV0aGVudGljYXRl ZCB1c2VyIGFzc2VydGlvbiZuYnNwO3Rva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiwgZGlzYWdyZWUs IGZvciB0aGUgc2FtZSByZWFzb25pbmcgYXMgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNhbWUgcmVhc29uaW5nLiZuYnNwOzxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgYWdyZWUgd2l0aCBKdXN0aW4gaGVy ZS4mbmJzcDsgVGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgb3BlbiByZWdpc3RyYXRpb25zIGFy ZSBlbmFibGVkLiZuYnNwOyBUaGUgZXhjZXB0aW9uIGNhc2UgaXMgdGhhdCBzcGVjaWZpYyBwZXJt aXNzaW9ucyBhcmUgcmVxdWlyZWQgdG8gcGVyZm9ybQ0KIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJh dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+QWJvdXQgc2VjdGlvbiA0 LjM6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklmIHRoZSBjbGllbnQgZG9lcyBu b3QgZXhpc3Qgb24gdGhpcyBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgTVVTVCByZXNwb25kPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNw OyB3aXRoIEhUVFAgNDAxIFVuYXV0aG9yaXplZCwgYW5kIHRoZSBSZWdpc3RyYXRpb24gQWNjZXNz IFRva2VuIHVzZWQgdG88L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG1ha2UgdGhpcyByZXF1ZXN0IFNIT1VMRCBiZSBpbW1l ZGlhdGVseSByZXZva2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgQ2xpZW50IGRvZXMg bm90IGV4aXN0IG9uJm5ic3A7dGhpcyBzZXJ2ZXIsIHNob3VsZG4ndCBpdCByZXR1cm4gYSAmcXVv dDs0MDQgTm90IEZvdW5kJnF1b3Q7Pzxicj4NCjxicj4NCklmIHJldm9raW5nIHRoZSByZWdpc3Ry YXRpb24gYWNjZXNzIHRva2VuLCBpcyBpdCBib3VuZCB0byBhIHNpbmdsZSBjbGllbnQgcmVnaXN0 cmF0aW9uPyAmbmJzcDtUaGlzIGlzIG5vdCBjbGVhci4gJm5ic3A7V2hhdCBpcyB0aGUgbGlmZWN5 Y2xlIGFyb3VuZCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuPyBPbmx5IGhpbnQgaXMgaW4gdGhl IENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25zZSBpbiBzZWN0aW9uIDUuMS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBsYW5ndWFnZSBhYm91dCB0aGUgNDAxIGhlcmUgKGFuZCBpbiBvdGhlciBuZWFy Ynkgc2VjdGlvbnMpIGlzIHNwZWNpZmljYWxseSBzbyB0aGF0IHlvdSB0cmVhdCBhIG1pc3Npbmcg Y2xpZW50IGFuZCBhIGJhZCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIHRoZSBzYW1lIHdheS4g WW91IHNlZSwmbmJzcDtyZXR1cm5pbmcgYSA0MDQgaGVyZSBhY3R1YWxseSBpbmRpY2F0ZXMgdGhp bmdzIHdlcmUgaW4gYW4gaW5jb25zaXN0ZW50DQogc3RhdGUuIE5hbWVseSwgdGhhdCB0aGUgcmVn aXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgc3RpbGwgdmFsaWQgYnV0IHRoZSBjbGllbnQgdGhh dCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgYXR0YWNoZWQgdG8gZG9lc24ndCBl eGlzdCBhbnltb3JlLiBUaGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBpbiBtZWFudCB0byBi ZSB0aWVkIHRvIGEgY2xpZW50J3MgaW5zdGFuY2UgKG9yIHJlZ2lzdHJhdGlvbiksIHNvIGl0J3Mg YWN0dWFsbHkNCiBtb3JlIHNlbnNpYmxlIHRvIGFjdCBhcyB0aG91Z2ggdGhlIHJlZ2lzdHJhdGlv biBhY2Nlc3MgdG9rZW4gaXNuJ3QgdmFsaWQgYW55bW9yZS4gSW4gYXQgbGVhc3Qgc29tZSBpbXBs ZW1lbnRhdGlvbnMgKHNwZWNpZmljYWxseSBvdXJzIGF0IE1JVFJFIHRoYXQncyBidWlsdCBvbiBT RUNPQVVUSCBpbiBKYXZhKSwgeW91J2QgbmV2ZXIgYmUgYWJsZSB0byByZWFjaCB0aGUgNDA0IHN0 YXRlIGR1ZSB0byBjb25zaXN0ZW5jeSBjaGVja2luZyB3aXRoIHRoZQ0KIGluYm91bmQgdG9rZW4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhlIGludGVudCBvZiB0aGUgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbiBpcyB0aGF0IGl0J3MgYm91bmQgdG8gYSBzaW5nbGUgaW5zdGFuY2UsIGl0 cyBsaWZlY3ljbGUgaXMgZ2VuZXJhbGx5IHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBiZWdpbnMgYXQg dGhlIGlzc3VhbmNlIG9mIGEgbmV3IGNsaWVudF9pZCB3aXRoIHRoYXQgaW5zdGFuY2UuIFRoYXQg dG9rZW4gbWlnaHQgYmUgcmV2b2tlZCBhbmQgYQ0KIG5ldyBvbmUgaXNzdWVkIG9uIFJlYWQgYW5k IFVwZGF0ZSByZXF1ZXN0cyB0byB0aGUgQ2xpZW50IENvbmZpZ3VyYXRpb24gRW5kcG9pbnQgKGFu ZCB0aGUgY2xpZW50IG5lZWRzIHRvIGJlIHByZXBhcmVkIGZvciB0aGF0IC0tIHNhbWUgYXMgdGhl IGNsaWVudF9zZWNyZXQpLCBhbmQgaXQgd2lsbCBiZSByZXZva2VkIHdoZW4gdGhlIGNsaWVudCBp cyBkZWxldGVkIGVpdGhlciB3aXRoIGEgRGVsZXRlIGNhbGwgdG8gdGhlIENsaWVudCBDb25maWd1 cmF0aW9uDQogRW5kcG9pbnQgb3Igc29tZXRoaW5nIGhhcHBlbmluZyBvdXQtb2YtYmFuZCB0byBr aWxsIHRoZSBjbGllbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvdWxkIHdlIGFkZCBt b3JlIGV4cGxhbmF0b3J5IHRleHQgdG8gdGhlIGRlZmluaXRpb24gaW4gdGhlIHRlcm1pbm9sb2d5 IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdtIHZlcnkgb3BlbiB0byBjb25jcmV0ZSBzdWdnZXN0aW9u cyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9uJ3QgdGhpbmsgaXQncyBhcyBjbGVhciBhcyB3ZSdkIGxp a2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2Ugc2hvdWxkIGxvb2sgYXQgaXQuPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Rm9y IHNlY3VyaXR5IHJlYXNvbnMsIGl04oCZcyBnZW5lcmFsbHkgbm90IGdvb2QgdG8gZGlzdGluZ3Vp c2ggYmV0d2VlbiDigJxub3QgZm91bmTigJ0gYW5kIOKAnHVuYXV0aG9yaXplZOKAnSBlcnJvcnMg aW4gcmVzcG9uc2VzLCBhcyB0aGF0IGNhbiBwcm92aWRlIHRoZSBhdHRhY2tlciBhbg0KIG9yYWNs ZSB0byBwcm9iZSB3aGV0aGVyIGEgcGFydGljdWxhciBlbnRpdHkgZXhpc3RzJm5ic3A7IEkgZG9u 4oCZdCB0aGluayBhIGNoYW5nZSBpcyBjYWxsZWQgZm9yIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxiPkFib3V0IHNlY3Rpb24gNS4xOjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIHVuaXF1ZT8gJm5ic3A7T3Ig aXMgaXQgc2hhcmVkIGJ5IG11bHRpcGxlIGluc3RhbmNlcz8gJm5ic3A7IElmIHNoYXJlZCwgdGhl biByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGNhbid0IGJlIHJldm9rZWQgb24gZGVsZXRlIG9m IGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPlRoZSByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGlzIHVuaXF1ZSB0byBhIHJl Z2lzdGVyZWQgY2xpZW50LCBpbiB0aGUgUkZDIDY3NDkgc2Vuc2Ugb2Yg4oCcY2xpZW504oCdLiZu YnNwOyBBZ2FpbiwgaWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIOKAnGNsaWVudCBpbnN0YW5jZXPi gJ0sIHdlIG5lZWQNCiB0byByZWNoYXJ0ZXIgYW5kIHRha2UgdGhpcyBkaXN0aW5jdCB3b3JrIGl0 ZW0gdXAgZXhwbGljaXRseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU3VnZ2Vz dCByZW5hbWUg4oCcZXhwaXJlc19hdOKAnSB0byDigJxjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXTi gJ0sJm5ic3A7PGJyPg0KPGJyPg0KU3VnZ2VzdCB0byByZW5hbWUg4oCcaXNzdWVkX2F04oCdIHRv IOKAnGlkX2lzc3VlZF9hdOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSBkbyBsaWtlIHRo ZSBzdWdnZXN0aW9uIG9mIGNoYW5naW5nIHRoZXNlIHRvIGNsaWVudF9zZWNyZXRfZXhwaXJlc19h dCBhbmQgY2xpZW50X2lkX2lzc3VlZF9hdCwgYW5kIEkgdGhpbmsgdGhlc2UgYXJlIG1vcmUgY2xl YXIgYW5kIHJlYWRhYmxlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB3YW50IHRv IGNoYW5nZSB0aGUgc3ludGF4IGR1cmluZyBsYXN0IGNhbGwgdW5sZXNzIHRoZXJlIGlzIGEgY2xl YXIgbmVlZCBhbmQgYSBjbGVhciBjb25zZW5zdXMgZm9yIGRvaW5nIHNvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhdCdzIHdoeSB3ZSBhcmUgaGF2aW5nIGxhc3QgY2FsbC4gVG8gY29uZmlybSBjb25zZW5zdXMg b24gdGhlIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhbWUgcmVhc29uaW5nIGFz IGVhcmxpZXIuIFlvdSBub3cgaGF2ZSBtdWx0aXBsZSB0b2tlbnMgKHJlZ2lzdHJhdGlvbiBhY2Nl c3MgYW5kIGNsaWVudCkgaW4gcGxheS4gVGhlIHNwZWMgbmVlZHMgdG8gYmUgY2xlYXIgd2hpY2gg b25lIGl0IGlzIHRhbGtpbmcgYWJvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkknbSBmaW5lIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgYnV0IEkgd291bGQgbGlrZSBt b3JlIGZlZWRiYWNrIGZyb20gb3RoZXIgcGVvcGxlIGJlZm9yZSBtb3ZpbmcgZm9yd2FyZCB3aXRo IGl0LiBUaGVyZSdzIGEgbG90IG9mIHZhbHVlIGluICZxdW90O2p1c3QgcGljayBhIG5hbWUgYW5k IHNoaXAgaXQmcXVvdDsgYXMgd2VsbCB0aG91Z2gsIGFuZCBJIGRvbid0IHdhbnQgdG8gZGV2b2x2 ZSBpbnRvIGJpa2Ugc2hlZGRpbmcuDQogKEknbSBub3QgYWNjdXNpbmcgeW91IG9mIGJpa2Ugc2hl ZGRpbmcgcXVpdGUgeWV0LCBidHcsIGp1c3QgYWZyYWlkIG9mIGdldHRpbmcgaW50byBhIGxvbmcg ZGViYXRlIG9uIG5hbWVzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiwgdGhp cyB3YXMgYSBwcm9ibGVtIHJhaXNlZCBieSBwZW9wbGUgbmV3IHRvIHRoZSBzcGVjaWZpY2F0aW9u LiBUaGV5IGZvdW5kIGl0IGNvbmZ1c2luZy4gSSB0ZW5kIHRvIGFncmVlLiBXZSdyZSBub3QgdGFs a2luZyBhYm91dCB3aGF0IGNvbG91ciB0byBwYWludCB0aGUgc2hlZC4gV2UncmUgdGFsa2luZyBh Ym91dCB3aGV0aGVyIHRoZSBiaWtlIHNoZWQgaXMgYSBob3VzZS4mbmJzcDsmbmJzcDs6LSkmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHRvbyBmdXNzZWQgYWJvdXQgd2hldGhlciB5 b3UgY2FsbCBpdCAmcXVvdDtjbF9zZWNfZXhwaXJ5JnF1b3Q7IG9yICZxdW90O2NsaWVudF9zZWNy ZXRfZXhwaXJlc19hdCZxdW90Oy4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5JZiB0aGUgZGVmaW5pdGlvbnMgb2Yg4oCcZXhwaXJl c19hdOKAnSBvciDigJxpc3N1ZWRfYXTigJ0gYXJlIHVuY2xlYXIsIHdlIHNob3VsZCBjbGFyaWZ5 IHRoZW0uJm5ic3A7IElmIHlvdSBiZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBQaGlsLCBj YW4geW91IHN1cHBseSBwcm9wb3NlZCBhbHRlcm5hdGl2ZQ0KIGRlZmluaXRpb24gdGV4dCB0aGF0 IGlzIGNsZWFyZXI/Jm5ic3A7IFRoYXQgYmVpbmcgc2FpZCwgSSBiZWxpZXZlIHRoYXQgYXQgdGhp cyBwb2ludCB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUgZXhpc3RpbmcgcHJvdG9jb2wgZWxlbWVu dCBuYW1lcyB1bmxlc3Mgb3ZlcndoZWxtaW5nIHdvcmtpbmcgZ3JvdXAgc2VudGltZW50IGVtZXJn ZXMgdG8gY2hhbmdlIHRoZW0uJm5ic3A7IFRoZXkgYXJlIGFscmVhZHkgd29ya2luZyBmaW5lIGFz LWlzIGluIHByb2R1Y3Rpb24NCiBkZXBsb3ltZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5TZWN0aW9uIDc8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBhIGNsaWVudF9z ZWNyZXQgZXhwaXJlcyBpcyBpdCB0aGUgaW50ZW50IHRoYXQgY2xpZW50cyBkbyBhbiB1cGRhdGUg b3IgcmVmcmVzaCB0byBnZXQgYSBuZXcgY2xpZW50IHNlY3JldD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlllcywgdGhlIGNsaWVudCBpcyBzdXBwb3NlZCB0byBlaXRoZXIgY2FsbCB0aGUgcmVhZCBvciB1 cGRhdGUgbWV0aG9kcyBvbiB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24gZW5kcG9pbnQgdG8gZ2V0 IGl0cyBuZXcgc2VjcmV0LiBBcyBkaXNjdXNzZWQgYWJvdmUsIEknbSBub3Qgc3VyZSB0aGF0J3Mg YXMgY2xlYXIgYXMgaXQgbmVlZHMgdG8gYmUsIGFuZCBJIHdlbGNvbWUgc3VnZ2VzdGlvbnMgb24g aG93IHRvIGNsYXJpZnkNCiB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5F aXRoZXIgaXMgYSByZWFzb25hYmxlIGJlaGF2aW9yIG9uIHRoZSBiZWhhbGYgb2YgY2xpZW50cywg ZGVwZW5kaW5nIHVwb24gY29udGV4dC4mbmJzcDsgSSBzdXBwb3J0IGFkZGluZyB0ZXh0IHRvIGNs YXJpZnkgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFnYWluLCB0aGFua3MgZm9yIHRoZSB2ZXJ5IHRob3JvdWdoIHJlYWQg dGhyb3VnaC4gSGF2ZSB5b3UgaW1wbGVtZW50ZWQgYW55IG9mIHRoZSBzcGVjIHlldCwgZWl0aGVy IGFzLWlzIG9yIHdpdGggYW55IG9mIHlvdXIgc3VnZ2VzdGVkIGNoYW5nZXM/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gTXVjaCBvZiB0aGUgZmVlZGJhY2sgaXMgY29t aW5nIGZyb20gb3VyIGRldmVsb3BtZW50IGNvbW11bml0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWgsIHZlcnkgY29vbC4gRGV2ZWxvcGVyIGV4cGVyaWVuY2Ug aXMgdGhlIG1vc3QgdmFsdWFibGUgZmVlZGJhY2ssIGluIG15IG9waW5pb24uIElmIHlvdSBjYW4n dCBhY3R1YWxseSBidWlsZCB0aGUgYmxhc3RlZCB0aGluZywgd2hhdCBnb29kIGlzIGl0PyA6KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+ R2xhZCB0byBoZWFyIHRoYXQgeW914oCZcmUgd29ya2luZyB3aXRoIGRldmVsb3BlcnMgYnVpbGRp bmcgdGhlIHNwZWMuJm5ic3A7IFBsZWFzZSB0aGFuayB0aGVtIGZvciB0aGUgZmVlZGJhY2suPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstLSBKdXN0aW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B168042967394367734CE0TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri May 17 17:01:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AE021F9687 for ; Fri, 17 May 2013 17:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32sdmOr1QIXt for ; Fri, 17 May 2013 17:01:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id C476021F9674 for ; Fri, 17 May 2013 17:01:51 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.201) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.687.1; Sat, 18 May 2013 00:01:35 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Sat, 18 May 2013 00:01:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Sat, 18 May 2013 00:01:34 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOUas2JA4xslwK7Eu6I2Qndjwd05kG/FsAgAAbFoCAAKOFAIAAf+YAgADupECAALz7gIAAJWHQ Date: Sat, 18 May 2013 00:01:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367734D79@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <80E6C4AC-5402-43E3-A6A2-0A98595F7203@oracle.com> In-Reply-To: <80E6C4AC-5402-43E3-A6A2-0A98595F7203@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367734D79TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52034003)(51914003)(85644002)(377454002)(66654002)(15454003)(377424003)(24454002)(50854003)(51444003)(54094003)(199002)(189002)(59766001)(54356001)(66066001)(16601075002)(50986001)(47976001)(79102001)(69226001)(33656001)(77982001)(54316002)(71186001)(81342001)(55846006)(74366001)(512874002)(80022001)(56816002)(56776001)(44976003)(16406001)(53806001)(46102001)(76482001)(15395725003)(31966008)(74502001)(47446002)(16236675002)(15974865001)(74876001)(74706001)(20776003)(81542001)(51856001)(74662001)(63696002)(6806003)(15202345002)(47736001)(65816001)(49866001)(4396001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0850800A29 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2013 00:01:59 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367734D79TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgcmVwbGllcyBhcmUgaW4gZ3JlZW4gYW5kIG1hcmtlZCBbbWJqXS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IEZy aWRheSwgTWF5IDE3LCAyMDEzIDI6MjQgUE0NClRvOiBNaWtlIEpvbmVzDQpDYzogUmljaGVyLCBK dXN0aW4gUC47IG9hdXRoQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBMYXN0 IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMA0KDQpJIGhhdmUgc3Rh cnRlZCBhIHNlcGFyYXRlIHRocmVhZCBvbiBoYXZpbmcgZHluIHJlZyBjb3JyZWxhdGUgY2xpZW50 IHNvZnR3YXJlLg0KDQpNeSBvdGhlciBjb21tZW50cyBhcmUgZW1iZWRkZWQgbWFya2VkIHdpdGgg W1BIXS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIDIwMTMtMDUtMTcsIGF0IDE6MDggUE0s IE1pa2UgSm9uZXMgd3JvdGU6DQoNCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZmVlZGJhY2ss IFBoaWwuICBTb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2Ug4oCTIEkgd2FzIHByZXR0eSBm dWxseSBlbmdhZ2VkIGF0IHRoZSBFdXJvcGVhbiBJZGVudGl0eSBDb25mZXJlbmNlICh3aGVyZSBP QXV0aCAyLjAgd29uIHRoZSBhd2FyZCBmb3IgYmVzdCBuZXcgc3RhbmRhcmQ8aHR0cDovL3NlbGYt aXNzdWVkLmluZm8vP3A9MTAyNj4g4pi6KS4gIE15IGZlZWRiYWNrIG9uIHRoZSBwb2ludHMgcmFp c2VkIGlzIGlubGluZSBpbiBncmVlbuKApg0KDQooUGVyaGFwcyBpZiBhbnkgb2YgeW91IHJlcGx5 IHRvIHRoaXMgdGhyZWFkLCB5b3UgY291bGQgYWxzbyBjaG9vc2UgYSBkaXN0aW5jdCBjb2xvciBm b3IgeW91ciBpbmxpbmUgcmVwbGllcywgc28gdGhhdCBpdCB3aWxsIGJlIGVhc2lseSBldmlkZW50 IHdobyBzYWlkIHdoYXQuICBBcyBpdCBpcywganVzdCB0aGUgYmFjay1hbmQtZm9ydGggYmV0d2Vl biBQaGlsIGFuZCBKdXN0aW4gaXMgYWxyZWFkeSB2ZXJ5IGRpZmZpY3VsdCB0byBmb2xsb3cuICBU aGFua3MuKQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBQaGlsIEh1bnQNClNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMTI6NTQgUE0NClRvOiBS aWNoZXIsIEp1c3RpbiBQLg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4gV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIExhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1vYXV0aC1keW4tcmVnLTEwDQoNCkp1c3RpbiwNCg0KVGhhbmtzIGZvciB0aGUgZGlzY3Vz c2lvbi4gTW9yZSBjb21tZW50cyBiZWxvdy4uLg0KDQpCVFcuIEknbSBoYXBweSB0byBjb250cmli dXRlIHRleHQuIEp1c3Qgd2FudCB0byBnZXQgdG8gc29tZSByb3VnaCBhZ3JlZW1lbnQgZmlyc3Qu ICBGb3IgZXhhbXBsZSwgSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgYSBhd2F5IHRvIHJlY29nbml6 ZSB0d28gcGllY2VzIG9mIHNvZnR3YXJlIGFzIGJlaW5nIHRoZSBzYW1lIChldmVuIGlmIHNlbGYt YXNzZXJ0ZWQpLiAgT25jZSBkZWZpbmVkLCBJIGNhbiBwdXQgdG9nZXRoZXIgc29tZSBpbnRybyB0 ZXh0LCBldGMuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNv bTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gMjAxMy0wNS0xNiwgYXQgNToxNiBBTSwg UmljaGVyLCBKdXN0aW4gUC4gd3JvdGU6DQoNCk9uIE1heSAxNSwgMjAxMywgYXQgMTA6MzAgUE0s IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj4NCiB3cm90ZToNCg0KT24gMjAxMy0wNS0xNSwgYXQgNTo1MyBQTSwgUmljaGVyLCBKdXN0 aW4gUC4gd3JvdGU6DQoNClBoaWwsIG1hbnkgdGhhbmtzIGZvciB0aGUgZXh0cmVtZWx5IHRob3Jv dWdoIHJldmlldyEgSXQgaXMgdmVyeSB1c2VmdWwgaW5kZWVkLg0KDQpNeSBjb21tZW50cyBhbmQg cmVzcG9uc2VzIHRvIGVhY2ggcG9pbnQgYXJlIGlubGluZS4NCg0KT24gTWF5IDE1LCAyMDEzLCBh dCA0OjMwIFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpJdCBzZWVtcyB1bmZvcnR1bmF0ZSB0aGF0IEkgaGF2 ZSBub3QgZ290dGVuIGEgY2hhbmNlIHRvIGdldCBpbnRvIHRoaXMgbGV2ZWwgb2YgZGV0YWlsIG11 Y2ggZWFybGllci4gQnV0IHRoZW4sIEkgZ3Vlc3MgdGhhdCdzIHdoYXQgTEMgcmV2aWV3IGlzIGZv ciEgTXkgYXBvbG9naWVzIGZvciBub3QgZ2V0dGluZyBtYW55IG9mIHRoZXNlIGNvbmNlcm5zIHRv IHRoZSBXRyBtdWNoIGVhcmxpZXIuDQoNCk92ZXJhbGwNCi0tLS0tLS0tLS0tDQpJIHRoaW5rIGR5 bmFtaWMgcmVnaXN0cmF0aW9uIGlzIGEgY3JpdGljYWwgcGFydCBvZiB0aGUgT0F1dGggZnJhbWV3 b3JrIG5vdyB0aGF0IHdlIGFyZSBzdGFydGluZyB0byBjb25zaWRlciBob3cgaW5kaXZpZHVhbCBj bGllbnQgYXBwbGljYXRpb25zIHNob3VsZCBvcGVyYXRlIHdoZW4gdGhlcmUgaXMgb25lIG9yIG1v cmUgZGVwbG95bWVudHMgb2YgYSBwYXJ0aWN1bGFyIHJlc291cmNlIEFQSS4gV2UndmUgbW92ZWQg ZnJvbSB0aGUgc2ltcGxlIHVzZSBjYXNlIG9mIGEgc2luZ2xlIEFQSSBwcm92aWRlciBsaWtlIEZh Y2Vib29rIG9yIEZsaWNrciBhbmQgbW92ZWQgb24gdG8gc3RhbmRhcmRzIGJhc2VkLCBvcGVuIHNv dXJjZSBiYXNlZCwgYW5kIGNvbW1lcmNpYWwgYmFzZWQgZGVwbG95bWVudHMgd2hlcmUgdGhlcmUg YXJlIG11bHRpcGxlIHNlcnZpY2UgZW5kcG9pbnRzIGFuZCBtYW55IGNsaWVudHMgdG8gbWFuYWdl Lg0KDQpUaGUgZHluYW1pYyByZWdpc3RyYXRpb24gc3BlYyBpcyBhY3R1YWxseSBkZWFsaW5nIHdp dGggYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBtYWRlIG1vcmUg Y2xlYXIgaW4gZWFybHkgcGFydCBvZiB0aGUgc3BlYzoNCg0KMS4gIEhvdyBpcyBhIG5ldyBjbGll bnQgYXBwbGljYXRpb24gcmVjb2duaXplZCBmb3IgdGhlIGZpcnN0IHRpbWUgd2hlbiBkZXBsb3ll ZCBhZ2FpbnN0IGEgcGFydGljdWxhciBTUCBlbmRwb2ludD8gIFNob3VsZCBjbGllbnRzIGFjdHVh bGx5IGFzc2VydCBhbiBhcHBsaWNhdGlvbl9pZCBVVUlEIHRoYXQgbmV2ZXIgY2hhbmdlcyBhbmQg cG9zc2libHkgYSB2ZXJzaW9uIGlkIHRoYXQgZG9lcyBjaGFuZ2Ugd2l0aCB2ZXJzaW9ucz8NCg0K SW4gdGhlIGdlbmVyYWwgY2FzZSwgd2h5IGlzIGFueSByZWNvZ25pdGlvbiByZXF1aXJlZD8gSWYg eW91J3JlIGRvaW5nIHRoaW5ncyBhcyBwYXJ0IG9mIGEgbGFyZ2VyIHByb3RvY29sIGVjb3N5c3Rl bSwgbGlrZSBCbHVlIEJ1dHRvbisgb3IgYSBwYXJ0aWN1bGFyIE9wZW5JRCBDb25uZWN0IHByb3Zp ZGVyLCB0aGVuIHlvdSBjYW4gZGVmaW5lIHNlbWFudGljcyBmb3IgdHlpbmcgdG9nZXRoZXIgY2xh c3NlcyBvZiBjbGllbnRzIChzZWUgYmVsb3cgZm9yIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlzIHZl cnkgcG9pbnQpLiBCdXQgaW4gZ2VuZXJhbCwgYSBjbGllbnQgaXMganVzdCBnb2luZyB0byBzaG93 IHVwIGFzIGEgbmV3IGluc3RhbmNlIHRvIHRoZSBBUyBhbmQgZ2V0IGlzc3VlZCBhIG5ldywgdW5p cXVlIGNsaWVudF9pZCwgYW5kIHRoYXQncyB0aGF0Lg0KDQpJIHRoaW5rIHdlIGhhdmUgdG8gZGVm aW5lIG1vcmUgY2xlYXJseSB3aGF0IGFuICJpbnN0YW5jZSIgaXMuIEZvciBtZSwgdGhlcmUgYXJl IGFwcGxpY2F0aW9ucyBhbmQgdGhlcmUgYXJlIGluc3RhbmNlcyBvZiB0aGF0IGFwcGxpY2F0aW9u LiAgSXQgaXMgdXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhhdCBhIGNsaWVudCBhcHBsaWNhdGlvbiBy ZXByZXNlbnRzIGEgc2V0IG9mIGNvZGUgdGhhdCBzaG91bGQgYmVoYXZlIGluIGEgY29uc2lzdGVu dCB3YXkuICBJdCBzZWVtcyB0byBtZSB0aGUgZmlyc3QgdGltZSBhIG5ldyBhcHBsaWNhdGlvbiBz aG93cyB1cCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHRoZSBzdWJzZXF1ZW50IGluc3RhbmNlcyB0 aGF0IHJlZ2lzdGVyLiBGb3IgZXhhbXBsZSwgYWZ0ZXIgdGhlIGZpcnN0IHJlZ2lzdHJhdGlvbiwg c3Vic2VxdWVudCBpbnN0YW5jZXMgZG9uJ3QgbmVlZCBzcGVjaWFsIHJldmlldyBvciBhcHByb3Zh bCB0byB0aGUgc2FtZSBkZWdyZWUuDQoNCkJ1dCB3aXRob3V0IG90aGVyIG1lY2hhbmlzbXMgdG8g dGllIHRoaW5ncyB0b2dldGhlciwgdGhlcmUncyBubyB3YXkgZm9yIGFuIGF1dGhvcml6YXRpb24g c2VydmVyIHRvIGtub3cgaWYgYW55IGNsaWVudCBpbnN0YW5jZSBpcyB0aWVkIHRvIGFueSBvdGhl ciBjbGllbnQgaW5zdGFuY2UuIFRoZXJlZm9yZSwgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYW4g QVMsIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiBhbiBhcHBsaWNhdGlvbiAoaS5lLiwgcGFydGljdWxh ciBjb25maWd1cmF0aW9uIG9mIGEgc2V0IG9mIGNvZGUpIHRvIHJlZ2lzdGVyIGlzIG5vIGRpZmZl cmVudCB0byBzdWJzZXF1ZW50IGluc3RhbmNlcyBvZiB0aGF0IHNhbWUgYXBwbGljYXRpb24uIEhv dyB3ZXJlIHlvdSBlbnZpc2lvbmluZyBhbiBBUyBrbm93aW5nIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhlIGZpcnN0IGFuZCBzdWJzZXF1ZW50IGluc3RhbmNlcyBvZiBhbiBhcHBsaWNhdGlvbiwg c3BlY2lmaWNhbGx5PyBJZiB0aGVyZSdzIGFuICJhcHBsaWNhdGlvbl9pZCIgbGlrZSB5b3UgbWVu dGlvbiBhYm92ZSwgSSB0aGluayBpdCByYWlzZXMgbW9yZSBxdWVzdGlvbnMgdGhhbiBpdCByZXNv bHZlczogV2hvIGlzc3VlcyB0aGUgYXBwbGljYXRpb25faWQsIHNvbWUgc2VydmVyIG9yIHRoZSBh cHBsaWNhdGlvbiBpdHNlbGY/IElzIGl0IHZhbGlkYXRlZCBhdCBhbGw/IFNob3VsZCBpdCBiZSBj b25zaWRlcmVkIHNlY3JldD8gV2hhdCBoYXBwZW5zIHdoZW4gc29tZW9uZSBzaW1wbHkgc3RlYWxz IGFuIGFwcGxpY2F0aW9uX2lkPyBEb2VzIGFuIEFTIGhhdmUgdG8gZG8gYW55dGhpbmcgdG8gY2hl Y2sgd2l0aCBhbnkgb3RoZXIgQVMgdG8gc2VlIGlmIHRoZSBhcHBsaWNhdGlvbl9pZCBoYXMgYWxy ZWFkeSBiZWVuIHVzZWQgZWxzZXdoZXJlPw0KDQpJIGRvIGFncmVlIHRoYXQgYSBkaXNjdXNzaW9u IG9mICJpbnN0YW5jZSB2cy4gYXBwbGljYXRpb24iIHdvdWxkIGJlIGhlbHBmdWwgaW4gY2xlYXJp bmcgdGhpcyB1cCwgSSdsbCBtYWtlIGEgbm90ZSB0byBhZGQgdGV4dCB0byB0aGF0IGVmZmVjdC4g KFdlIGhhZCB0byBkbyBzb21ldGhpbmcgc2ltaWxhciBmb3IgQkIrKQ0KDQpJIHRoaW5rIGl0IGlz IHNpbXBsZSBlbm91Z2ggdG8gYXQgbGVhc3QgYWRkIGEgc2VsZiBnZW5lcmF0ZWQgVVVJRCBmb3Ig dGhlIGFwcGxpY2F0aW9uIElELiAgVGhvdWdoIEkgd291bGQgYWxsb3cgZm9yIGNhc2VzIHdoZXJl IHRoZSBhcHBsaWNhdGlvbiBJRCBpcyBhc3NpZ25lZCB3aGVuIHRoZSBjbGllbnQgZGV2ZWxvcGVy IGFuZCB0aGUgQVBJcyBvd25lciBkbyBhIGZvcm1hbCBhc3NpZ25tZW50IG9mIGFwcGxpY2F0aW9u IElEcy4NCg0KSW4gYSBzZW5zZSB0aGlzIGlzIGp1c3QgYSBsb3dlciB0ZWNoIHdheSBvZiBkb2lu ZyBpdCB0aGFuIHdoYXQgeW91IGRlc2NyaWJlZCBhcyB0aGUgaW5pdGlhbCBjbGllbnQgY3JlZGVu dGlhbCBpbiBCbHVlIEJ1dHRvbisgd2hlcmUgeW91IGVuY29kZWQgZXh0cmEgY2xhaW1zIGludG8g dGhlIGluaXRpYWwgYXBwIGNyZWRlbnRpYWwuDQoNCldoYXQgdGhlIFVVSUQgZG9lcyBpcyBsaW5r IG11bHRpcGxlIGluc3RhbmNlcyBvZiBhIGNsaWVudCBhcHAgdG9nZXRoZXIgYXMgdGhlIHNhbWUg InRoaW5nIiB0aGF0IHNob3VsZCBoYXZlIHNpbWlsYXIgaGV1cmlzdGljcy9iZWhhdmlvdXJzLiAg VGhpcyBpcyB2ZXJ5IHVzZWZ1bCBpZiB5b3Ugd2FudCB0byBiZSBhYmxlIHRvIHJldm9rZSBhY2Nl c3MgdG8gYSBzZXQgb2YgY2xpZW50cyBpZGVudGlmaWVkIGJ5IGFwcGxpY2F0aW9uIGlkIChvciBh IHZlcnNpb24gb2YgdGhhdCBhcHApLg0KDQpXaGlsZSBJ4oCZbSBzeW1wYXRoZXRpYyB0byB0aGUg T0F1dGggd29ya2luZyBncm91cCBldmVudHVhbGx5IGRvaW5nIHdvcmsgb24gZGlmZmVyZW50aWF0 aW5nIGJldHdlZW4gaW5zdGFuY2VzIG9mIGFuIE9BdXRoIGNsaWVudCwgSeKAmWxsIG5vdGUgdGhh dCBpbiBSRkMgNjc0OSBvciBSRkMgNjc1MCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGEgY2xp ZW50IGluc3RhbmNlLiAgVGhlcmUgYXJlIG9ubHkgY2xpZW50cywgd2hpY2ggYXJlIGlkZW50aWZp ZWQgYnkgY2xpZW50X2lkIHZhbHVlcy4gIElmIHdlIHdhbnQgdG8gZG8gd29yayBvbiBjbGllbnQg aW5zdGFuY2VzLCB3ZSBzaG91bGQgcmVjaGFydGVyIHRvIGFkZCB0aGlzIG5ldyB3b3JrIGFzIGEg d29ya2luZyBncm91cCBkZWxpdmVyYWJsZS4gIFdlIHNob3VsZCBub3QgdHJ5IHRvIHNob2Vob3Ju IGJpdHMgYW5kIHBpZWNlcyBvZiBpdCBpbnRvIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVj LCBhbnkgbW9yZSB0aGFuIHdlIHNob3VsZCBoYXZlIHRyaWVkIHRvIHNob2Vob3JuIGl0IGludG8g UkZDIDY3NDkgb3IgUkZDIDY3NTAuICBPYXV0aC1keW4tcmVnIGlzIHRoZXJlIHRvIHJlZ2lzdGVy IGNsaWVudHMgYXMgZGVmaW5lZCBpbiBSRkMgNjc0OS4gIEl04oCZcyBub3QgdGhlIHJpZ2h0IHBs YWNlIHRvIGV4dGVuZCB3aGF0IGFuIE9BdXRoIGNsaWVudCBpcyBpbiBuZXcgd2F5cy4NCg0KW1BI XSBTZWUgbmV3IHRocmVhZCBJIGhhdmUgYmVndW4uDQoNCg0KMi4gIEhvdyBhcmUgY2xpZW50IGNy ZWRlbnRpYWxzIG1hbmFnZWQuIEFyZSB3ZSBhc3N1bWluZyBjbGllbnQgY3JlZGVudGlhbHMgaGF2 ZSBhIGxpbWl0ZWQgbGlmZXRpbWUgb3Igcm90YXRpb24gcG9saWN5Pw0KDQpUaGUgaW50ZW50IHdh cyB0aGF0IGNsaWVudF9zZWNyZXQgY291bGQgYmUgcm90YXRlZCwgYXMgaW5kaWNhdGVkIGJ5IHRo ZSBleHBpcmVzX2F0IG1lbWJlciBvZiB0aGUgcmVzcG9uc2UuIElmIGEgY2xpZW50J3Mgc2VjcmV0 IGV4cGlyZXMsIGl0IGNhbGxzIHRoZSByZWFkIG9wZXJhdGlvbiBvbiB0aGUgQ2xpZW50IENvbmZp Z3VyYXRpb24gRW5kcG9pbnQgKMKnNC4yKSB0byBnZXQgaXRzIG5ldyBjbGllbnRfc2VjcmV0LiBJ ZiB0aGlzIGlzIHVuY2xlYXIgaW4gdGhlIGN1cnJlbnQgdGV4dCAod2hpY2ggSSBzdXNwZWN0IGl0 IG1heSBiZSBhZnRlciBtdWx0aXBsZSByZWZhY3RvcmluZ3MpLCB0aGVuIEkgd2VsY29tZSBzdWdn ZXN0aW9ucyBhbmQgc3BlY2lmaWMgdGV4dCBhcyB0byBob3cgdG8gbWFrZSB0aGF0IGNsZWFyLg0K U29tZXRoaW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgaW4gdGhlIGRyYWZ0Lg0KDQpTaG91bGQgdGhp cyBiZSB1cCBpbiB0aGUgaW50cm9kdWN0b3J5IHRleHQsIHNvbWV3aGVyZSBlbHNlLCBvciBoYXZl IGl0cyBvd24gc2VjdGlvbj8NCg0KSSdtIHN0YXJ0aW5nIHRvIHRoaW5rIGNyZWRlbnRpYWwgbWFu YWdlbWVudCBpcyBhIGtleSBwYXJ0IG9mIHRoZSBkcmFmdC4gSXQgbWF5IGJlIHdvcnRoIGludHJv ZHVjaW5nIGEgc3BlY2lmaWMgc2VjdGlvbiBvdXRsaW5nIHRoZSByZWdpc3RyYXRpb24gbGlmZS1j eWNsZSwgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB1c2FnZSwgYW5kIGNsaWVudCB0b2tlbiB1 c2FnZSBhbmQgYm9vdHN0cmFwcGluZy4NCg0KSSB0aGluayB0aGF0IGFkZGluZyBhIGRpc2N1c3Np b24gb24gdGhpcyB3b3VsZCBiZSBmaW5lLCBhcyBpdCBjb3VsZCBoZWxwIGRldmVsb3BlcnMgdW5k ZXJzdGFuZCB0aGUgd29ya2Zsb3cgb2YgcmVnaXN0ZXJpbmcsIHVzaW5nLCBhbmQgdXBkYXRpbmcg cmVnaXN0ZXJlZCBjbGllbnRzLg0KDQpIb3cgZG9lcyBhIGNsaWVudCBhdXRoZW50aWNhdGUgdGhl IGZpcnN0IHRpbWUgYW5kIHN1YnNlcXVlbnQgdGltZXMgdG8gdGhlIHJlZ2lzdHJhdGlvbiBzZXJ2 aWNlPw0KDQpUaGlzIGlzIGEgc2VwYXJhdGUgcXVlc3Rpb24gYWxsIHRvZ2V0aGVyLCBhcyBpdCBk b2VzIG5vdCBpbnZvbHZlIHRoZSBjbGllbnRfc2VjcmV0IG9yIGNsaWVudF9pZCBhdCBhbGwuIFJh dGhlciwgdGhlIGZpcnN0IHRpbWUgdGhlIGNsaWVudCBzaG93cyB1cCB0byB0aGUgcmVnaXN0cmF0 aW9uIHNlcnZpY2UsIGl0IG1heSBlaXRoZXI6DQogIC0gTm90IGF1dGhlbnRpY2F0ZSBhdCBhbGwg KHRoaXMgaXMgdGhlIHRydWUgcHVibGljLCBvcGVuIHJlZ2lzdHJhdGlvbiwgYW5kIGl0IGlzIHJl Y29tbWVuZGVkIHRoYXQgc2VydmVycyBkbyB0aGlzKQ0KIC0gQXV0aGVudGljYXRlIHVzaW5nIGFu IE9BdXRoIDIuMCB0b2tlbiAod2hpY2ggQVRNIG1lYW5zIGEgYmVhcmVyIHRva2VuKS4gSG93IHRo ZSBjbGllbnQgZ2V0cyB0aGF0IGJlYXJlciB0b2tlbiBhbmQgd2hhdCB0aGUgYmVhcmVyIHRva2Vu IG1lYW5zIHRvIHRoZSBBUyBiZXlvbmQgInRoaXMgY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gcmVn aXN0ZXIiIGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIHNwZWMsIGJ5IGRlc2lnbi4NCg0KU3Vic2Vx dWVudCB0aW1lcyB0aGF0IHRoZSBzYW1lIHJlZ2lzdGVyZWQgY2xpZW50IChieSB3aGljaCB3ZSBt ZWFuIHRoZSBzYW1lIGluc3RhbmNlIG9mIGEgY2xpZW50IHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVu dF9pZCkgc2hvd3MgdXAgYXQgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCAoYWN0dWFsbHksIHRo ZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludCksIGl0IHVzZXMgaXRzIFJlZ2lzdHJhdGlv biBBY2Nlc3MgVG9rZW4gdGhhdCBpdCB3YXMgaXNzdWVkIG9uIGluaXRpYWwgcmVnaXN0cmF0aW9u LiBUaGlzIGlzIGFuIE9BdXRoIDIuMCBCZWFyZXIgdG9rZW4gdGhhdCBpcyB1bmlxdWUgdG8gdGhl IGNsaWVudCBpbnN0YW5jZS4NCg0KU29tZXRoaW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgaW4gdGhl IGRyYWZ0Lg0KDQpPSywgdGhlIGRlZmluaXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3Mg dG9rZW4gY2FuIGJlIGV4cGFuZGVkLCBidXQgSSB0aGluayB0aGF0IHRoZSByZXN0IG9mIGl0IGlz IGFscmVhZHkgaW4gdGhlcmUgaW4gwqczLiBJJ2Qgd2VsY29tZSBzdWdnZXN0aW9ucyBvbiB3aGlj aCBiaXRzIG9mIHRoaXMgY291bGQgYmUgbWFkZSBjbGVhcmVyLg0KDQpTZWUgdGhlIGRpc2N1c3Np b24gb24gd2hhdCB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBpcyBpbiB0aGUgdGhyZWFk IOKAnENsaWVudCBDcmVkZW50aWFsIEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3Mg VG9rZW4gLSBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMTDigJ0uICBJIHdpbGwgd29yayB3aXRo IEp1c3RpbiB0byBhcHBseSB0aGVzZSBjbGFyaWZpY2F0aW9ucyB0byB0aGUgc3BlY2lmaWNhdGlv bi4gIFRoaXMgbWF5IGdvIGludG8gdGhlIHByb3Bvc2VkIGNyZWRlbnRpYWwgbWFuYWdlbWVudCBv dmVydmlldyBzZWN0aW9uIGRpc2N1c3NlZCBhYm92ZS4NCg0KMy4gIEhvdyBpcyB2ZXJzaW9uaW5n IG9mIGNsaWVudHMgbWFuYWdlZD8gU2hvdWxkIGVhY2ggbmV3IHZlcnNpb24gb2YgYSBjbGllbnQg cmVxdWlyZSBhIGNoYW5nZSBpbiBjbGllbnQgcmVnaXN0cmF0aW9uIGluY2x1ZGluZyBwb3NzaWJs eSBjaGFuZ2luZyBjbGllbnRfaWQgYW5kIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWw/IEkgZG9u J3QgaGF2ZSBhIHN0cm9uZyBmZWVsaW5nLCBidXQgaXQgaXMgc29tZXRoaW5nIHRoYXQgaW1wbGVt ZW50b3JzIHNob3VsZCBjb25zaWRlci4NCg0KVGhpcyBpcyB1cCB0byB0aGUgQVMsIHJlYWxseSwg YW5kIEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnkgZ2xvYmFsIHBvbGljeSB3b3VsZCBldmVyIGZseSBo ZXJlLiBFc3BlY2lhbGx5IGlmIHlvdSBjb25zaWRlciB0aGF0IHRoZSBlbnRpcmUgbm90aW9uIG9m ICJ2ZXJzaW9uIiBpcyBtb3JlIGZsdWlkIHRoZXNlIGRheXMgdGhhbiBpdCBldmVyIGhhcyBiZWVu LiBJIHdvdWxkbid0IG1pbmQgYWRkaW5nIGEgZGlzY3Vzc2lvbiBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgaWYgaXQgbWVyaXRzIG1lbnRpb25pbmcgdGhvdWdoLCBzbyB0aGF0IHdlIGNh biBoZWxwIGJvdGggY2xpZW50IGRldmVsb3BlcnMgYW5kIHNlcnZlciBkZXZlbG9wZXJzIGluc3Rp dHV0ZSByZWFzb25hYmx5IGdvb2QgcG9saWN5Lg0KDQpJIGd1ZXNzIHRoZSBpc3N1ZSBpcyB0aGF0 IHdoZW4gYSBjbGllbnQgdXBncmFkZXMgaXQgbWF5IGhhdmUgYWNjZXNzIHRvIHRoZSBvbGQgY3Jl ZGVudGlhbHMuIFdoYXQgaXMgdGhlIGludGVudCB0aGVuIG9mIHJlZ2lzdHJhdGlvbi4gIFNpbmNl IHlvdSBoYXZlIGFuIHVwZGF0ZSBhcmUgY2xpZW50cyBleHBlY3RlZCB0byB1cGRhdGUgL3JlLXJl Z2lzdGVyIG9yIG5vdD8gIEknbSBub3Qgc3VyZSB0aGlzIGlzIGEgc2VjdXJpdHkgY29uc2lkZXJh dGlvbiBidXQgbW9yZSBwYXJ0IG9mIHRoZSB3aG9sZSBjaGFuZ2UgbWFuYWdlbWVudCBmdW5jdGlv biBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzdXBwb3J0cy4NCg0KSWYgeW91ciB1cGdyYWRlZCB2ZXJz aW9uIG9mIHRoZSBjbGllbnQgc3RpbGwgaGFzIGFjY2VzcyB0byBpdHMgb2xkIGNyZWRlbnRpYWxz LCB3aHkgd291bGRuJ3QgaXQganVzdCB1c2UgdGhvc2U/IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIGZv ciBmb3JjaW5nIGEgcmUtcmVnaXN0cmF0aW9uLiBOb3IgZG8gSSBzZWUgYW55IHdheSB0aGF0IGFu IEFTIHdvdWxkIGV2ZW4gYmUgYWJsZSB0byB0ZWxsIHRoYXQgYSBjbGllbnQgaGFkIGJlZW4gdXBn cmFkZWQuIEFuIHVwZ3JhZGVkIGNsaWVudCBhbHdheXMgaGFzIHRoZSAqb3B0aW9uKiBvZiByZS1y ZWdpc3RlcmluZyBpdHNlbGYgYW5kIGdldHRpbmcgYSBuZXcgY2xpZW50X2lkLg0KSSB0aGluayB0 aGUgY29uY2VybiBoZXJlIGlzIHRoYXQgcm90YXRpb24gb2YgY2xpZW50IGNyZWRlbnRpYWwgaXMg bm90IHNvbWV0aGluZyBkaXNjdXNzZWQgYmVmb3JlLiBCZWZvcmUgd2UgcHV0IGl0IGluIHRoZSBz cGVjIHdlIHNob3VsZCBjb25zaWRlciB0aGUgcmVhc29ucyBmb3IgZG9pbmcgaXQgYW5kIHdoYXQg cHJvYmxlbXMgaXQgc29sdmVzLg0KDQpJIHRoaW5rIHRoaXMgbWF5IGJlIGp1c3QgYSBjYXNlIG9m IGxldHRpbmcgcGVvcGxlIGV4Y2hhbmdlIGNyZWRlbnRpYWxzIGZvciB3aGF0ZXZlciByZWFzb24g dGhleSBmZWVsIGlzIGFwcHJvcHJpYXRlLiAgVGhlIHZlcnNpb24gdXBncmFkZSB0aGluZyBzdWdn ZXN0cyB0aGF0IHdoZW4gYSBjbGllbnQgaXMgdXBncmFkZWQgaXQgc2hvdWxkIGdvIHRvIHRoZSBy ZWdpc3RyYXRpb24gc2VydmVyIHRvICJyZS1yZWdpc3RlciIuICBEZXBlbmRpbmcgb24gdGhlIHBv bGljeSBvZiB0aGUgc2VydmVyLCBpdCBtYXkgKG9yIG1heSBub3QpIHJlY2VpdmUgYSBuZXcgY2xp ZW50X2lkIGFuZC9vciBuZXcgY3JlZGVudGlhbC4NCg0KT25lIG9mIHRoZSBiZXN0IGJlbmVmaXRz IEkgY2FuIHRoaW5rIG9mIGlzIGlmIHlvdSBkaXNjb3ZlciBhIHZlcnNpb24gb2YgYSBjbGllbnQg aGFzIGEgcHJvYmxlbSwgYmVpbmcgYWJsZSB0byBzZWxlY3QgYSBncm91cCBvZiBjbGllbnRzIGJ5 IHNvZnR3YXJlIGFuZCB2ZXJzaW9uIGlzIGltcG9ydGFudC4gVGh1cyBpZiBjbGllbnRfaWQgZG9l c24ndCB0cmFjZSB0byBhIHBhcnRpY3VsYXIgc29mdHdhcmUgYW5kIHZlcnNpb24sIHRoYXQgbWFr ZXMgaXQgaGFyZCB0byBkby4gIEkgIHRoaW5rIHlvdSB0YWxrZWQgYWJvdXQgdGhpcyBhcyBhbiBp c3N1ZSBmb3IgQmx1ZSBCdXR0b24rDQoNCkFnYWluLCBSRkMgNjc0OSBkZWZpbmVzIG5vIGNsaWVu dCBpbnN0YW5jZXMgb3IgZ3JvdXBzIG9mIGNsaWVudHMsIHRoZXJlZm9yZSBJIGJlbGlldmUgdGhh dCBpdOKAmXMgaW5hcHByb3ByaWF0ZSB0byBkbyBzbyBoZXJlLiAgV2UgZG9u4oCZdCBuZWVkIHRv IGJvaWwgdGhlIG9jZWFuLiAgSWYgYSBuZXcgY2hhcnRlciBpdGVtIGlzIGFwcHJvdmVkIHRvIGRv IHdvcmsgb24gY2xpZW50IGluc3RhbmNlcyBhbmQgcHJvdG9jb2wgZWxlbWVudHMgdG8gdXNlIGFu ZCBleHByZXNzIHRoZW0sIHRoYXTigJlzIHRoZSB0aW1lIGZvciB0aGUgd29ya2luZyBncm91cCB0 byBjb25zaWRlciB0aGF0IHBvc3NpYmlsaXR5IOKAkyBub3QgYXMgcGFydCBvZiBEeW5hbWljIENs aWVudCBSZWdpc3RyYXRpb24uDQoNCltQSF0gV2UgZGlzYWdyZWUgc3Ryb25nbHkgaGVyZS4gIEkg dGhpbmsgaXQgaXMgd2VsbCB3aXRoaW4gY2hhcnRlciBhbmQgaW4gZmFjdCBpZiBzdWNoIGEgbmV3 IGNoYXJ0ZXIgaXRlbSB3ZXJlIGRldmVsb3BlZCB3ZSB3b3VsZCBiZSBxdWlja2x5IG1vdmluZyB0 byByZXBsYWNlIGR5biByZWcgdmVyc2lvbiAyLg0KDQpbbWJqXSBQZXIgbXkgY29tbWVudHMgb24g dGhlIG5ldyB0aHJlYWQgeW91IHN0YXJ0ZWQsIHdlIHdvdWxkbuKAmXQgYmUgcmVwbGFjaW5nIHRo ZSBleGlzdGluZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVjIOKAkyB3ZeKAmWQgYmUgY3JlYXRp bmcgYSBuZXcgT0F1dGggQ2xpZW50IEluc3RhbmNlIE1hbmFnZW1lbnQgc3BlYywgb25jZSBwaWVj ZSBvZiB3aGljaCB3b3VsZCBiZSBkZWZpbmluZyB0aGUgNSUgZXh0ZW5zaW9ucyBuZWVkZWQgdG8g dXNlIGl0IGZvciB0aGF0IHVzZSBjYXNlLiAgKEFuZCBhbHNvIHBlciBteSBjb21tZW50cyBvbiB0 aGF0IHRocmVhZCwgSeKAmW0gc3VyZSB0aGF0IHRoZSByZWdpc3RyYXRpb24gYml0cyB3b3VsZG7i gJl0IGJlIGFsbCB0aGF0IHdvdWxkIGJlIGluIHRoYXQgc3BlYyDigJMgdGhleeKAmWQgcHJvYmFi bHkgb25seSBiZSBhIHNtYWxsIHBhcnQgb2YgaXQuKQ0KDQo0LiAgV2hhdCBpcyB0aGUgcmVnaXN0 cmF0aW9uIGFjY2VzcyB0b2tlbj8gV2h5IGlzIGlzIHVzZWQ/IFdoYXQgaXMgaXRzIGxpZmUtY3lj bGU/ICBXaGVuIGlzIGl0IGlzc3VlZCwgd2hlbiBpcyBpdCBjaGFuZ2VkPyBXaGVuIGlzIGl0IGRl bGV0ZWQ/DQoNClNlZSB0aGUgcmVzcG9uc2UgYWJvdmUgYWJvdmUgYW5kIHRoZSBkZWZpbml0aW9u IGluIMKnMS4yOg0KDQpSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuOiBBbiBPQXV0aCAyLjAgQmVh cmVyIFRva2VuIGlzc3VlZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhyb3VnaCB0aGUg Q2xpZW50IFJlZ2lzdHJhdGlvbiBFbmRwb2ludCB3aGljaCBpcyB1c2VkIGJ5IHRoZSBDbGllbnQg dG8gYXV0aGVudGljYXRlIGl0c2VsZiBkdXJpbmcgcmVhZCwgdXBkYXRlLCBhbmQgZGVsZXRlIG9w ZXJhdGlvbnMuIFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBDbGll bnQuDQoNCklmIHRoaXMgY2FuIGJlIGNsYXJpZmllZCwgSSB3ZWxjb21lIHRleHQgc3VnZ2VzdGlv bnMuDQoNClRoZSBsYXR0ZXIgcGFydCBvZiAxLjIgZGlkbid0IHNlZW0gbGlrZSB0ZXJtaW5vbG9n eSBidXQgcmF0aGVyIGFyY2hpdGVjdHVyZSBvciBwYXJ0IG9mIHRoZSBpbnRyb2R1Y3Rpb24gdGhh dCBkZXNjcmliZXMgd2hhdCB0aGUgc3BlYyBkb2VzLiBUaGUgdGhpcmQgcG9pbnQgZG9lc24ndCBz ZWVtIHRvIGZpdCB3aXRoIHRoZSBvdGhlciB0d28gZXhjZXB0IHRvIHNheSB0aGF0IHRoZSBkeW5h bWljIHJlZ2lzdHJhdGlvbiBlbmRwb2ludHMgdXNlIHRoZWlyIG93biBhY2Nlc3MgdG9rZW5zIGNh bGxlZCByZWdpc3RyYXRpb24gYWNjZXNzIHRva2Vucy4NCg0KDQpDbGllbnQgUmVnaXN0cmF0aW9u IEVuZHBvaW50OiBUaGUgT0F1dGggMi4wIEVuZHBvaW50IHRocm91Z2ggd2hpY2gNCg0KICAgICAg YSBDbGllbnQgY2FuIHJlcXVlc3QgbmV3IHJlZ2lzdHJhdGlvbi4gIFRoZSBtZWFucyBvZiB0aGUg Q2xpZW50DQoNCiAgICAgIG9idGFpbmluZyB0aGUgVVJMIGZvciB0aGlzIGVuZHBvaW50IGFyZSBv dXQgb2Ygc2NvcGUgZm9yIHRoaXMNCg0KICAgICAgc3BlY2lmaWNhdGlvbi4NCg0KDQoNCiAgIG8g IENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50OiBUaGUgT0F1dGggMi4wIEVuZHBvaW50IHRo cm91Z2gNCg0KICAgICAgd2hpY2ggYSBzcGVjaWZpYyBDbGllbnQgY2FuIG1hbmFnZSBpdHMgcmVn aXN0cmF0aW9uIGluZm9ybWF0aW9uLA0KDQogICAgICBwcm92aWRlZCBieSB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgdG8gdGhlIENsaWVudC4gIFRoaXMgVVJMIGZvcg0KDQogICAgICB0aGlzIGVu ZHBvaW50IGlzIGNvbW11bmljYXRlZCB0byB0aGUgY2xpZW50IGJ5IHRoZSBBdXRob3JpemF0aW9u DQoNCiAgICAgIFNlcnZlciBpbiB0aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJlc3BvbnNlLg0KDQoN Cg0KICAgbyAgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjogQW4gT0F1dGggMi4wIEJlYXJlciBU b2tlbiBpc3N1ZWQgYnkgdGhlDQoNCiAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIHRocm91Z2gg dGhlIENsaWVudCBSZWdpc3RyYXRpb24gRW5kcG9pbnQNCg0KICAgICAgd2hpY2ggaXMgdXNlZCBi eSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgZHVyaW5nIHJlYWQsDQoNCiAgICAg IHVwZGF0ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiAgVGhpcyB0b2tlbiBpcyBhc3NvY2lhdGVk IHdpdGggYQ0KDQogICAgICBwYXJ0aWN1bGFyIENsaWVudC4NCg0KVGhpcyBzZWN0aW9uIGlzIG1l YW50IHRvIGp1c3QgaW50cm9kdWNlIHRoZSBuZXcgdGVybXMgdGhhdCBhcmUgdGhlbiBleHBsYWlu ZWQgaW4gZ3JlYXRlciBkZXRhaWwgdGhyb3VnaG91dCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQu IFllcywgaXQncyBhIGJpdCBhcmNoaXRlY3R1cmUsIGJ1dCBvbmx5IGluIHRoZSBzZW5zZSB0aGF0 IHlvdSBuZWVkIHRvIGRlZmluZSB0aGUgdGVybXMgdGhhdCBtYWtlIHVwIHlvdXIgYXJjaGl0ZWN0 dXJlLiBIb3cgd291bGQgeW91IHN1Z2dlc3QgdGhhdCBpdCBjaGFuZ2U/DQoNClByb2JhYmx5IHRo aXMgaXMgbW9yZSBhIG1hdHRlciBvZiBzdHlsZS4gIEJ1dCwgd2hhdCBoYXBwZW5lZCBmb3IgbWUg aXMgSSBuYXR1cmFsbHkgc2tpcHBlZCB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiwgYXMgSSB3YXNu J3QgZXhwZWN0aW5nIHByb3RvY29sIGNvbXBvbmVudHMgdG8gYmUgdGhlcmUuICAidGVybWlub2xv Z3kiIGlzIHNvbWV0aGluZyBJIHRoaW5rIHBlb3BsZSB0ZW5kIHRvIHVzZSBhcyBhIGRpY3Rpb25h cnkgcmF0aGVyIHRoYW4gYXMgcHJvdG9jb2wgY29tcG9uZW50IGRlc2NyaXB0aW9uLiAgTWF5YmUg dGhlIGNoYWlycyBjYW4gYWR2aXNlPw0KDQpJZiB3ZSBkaXN0aW5ndWlzaCBiZXR3ZWVuIGZpcnN0 IHRpbWUgcmVnaXN0cmF0aW9uIG9mIGEgcGFydGljdWxhciBjbGllbnQgc29mdHdhcmUgcGFja2Fn ZSwgaXQgaXMgcG9zc2libGUgdGhhdCBzb21ldGhpbmdzIGxpa2UgYXV0aGVudGljYXRpb24gbWV0 aG9kIGNhbiBiZSBuZWdvdGlhdGUgaW4gb3Igb3V0LW9mLWJhbmQgYXQgdGhhdCB0aW1lLiBTdWJz ZXF1ZW50IHJlZ2lzdHJhdGlvbnMgc2hvdWxkIG9ubHkgaGF2ZSBwYXJhbWV0ZXJzIGZvciBpdGVt cyB0aGF0IGNvdWxkIGNoYW5nZSBwZXIgZGVwbG95bWVudCAobGlrZSB0b3NfdXJpKS4gIEkgdGhp bmsgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgaXMgb25lIHRoaW5nIHRoYXQgc2hvdWxkIG5v dCBiZSBuZWdvdGlhdGVkIHBlciBpbnN0YW5jZS4NCg0KV2hlbiBzdWJzZXF1ZW50IGluc3RhbmNl cyByZWdpc3RlciwgSSBoYXZlIHRvIGFzayB0aGUgcXVlc3Rpb24sIGZvciBleGFtcGxlIHdoZW4g d291bGQgdGhpbmdzIGxpa2UgInRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIiBiZSBuZWdvdGlh dGVkIG9yIGJlIGRpZmZlcmVudCBmb3IgdGhlIHNhbWUgY2xpZW50IHNvZnR3YXJlPyBTaG91bGQg bm90IGFsbCBpbnN0YW5jZXMgdXNlIHRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4NCg0K SSdtIGNvbmZ1c2VkIGJ5IHRoaXMgLS0gYXMgZmFyIGFzIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlv biBzcGVjIGlzIGNvbmNlcm5lZCwgYWxsIGluc3RhbmNlcyBhcmUgc2VwYXJhdGUgZnJvbSBlYWNo IG90aGVyLiBBbGwgcGFyYW1ldGVycyBjaGFuZ2UgcGVyIGluc3RhbmNlLiBBbmQgaW5zdGFuY2Us IHlvdSBzaG91bGQga2VlcCBpbiBtaW5kLCBpcyBkZWZpbmVkIGFzIGFueSBvbmUgY29weSBvZiB0 aGUgY2xpZW50IGNvZGUgY29ubmVjdGluZyB0byBhbnkgbmV3IGF1dGhvcml6YXRpb24gc2VydmVy LiBUaGF0IHBhaXJpbmcgY3JlYXRlcyB0aGUgY2xpZW50X2lkLCBhbmQgdGhlcmVmb3JlIHRoZSBp bnN0YW5jZSwgYW5kIHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiwgYW5k IHRoZXJlZm9yZSB0aGUgcmVnaXN0cmF0aW9uIGl0c2VsZiBhdCBhIGNvbmNlcHR1YWwgbGV2ZWwu IFNvIHRoZXJlIGlzIG5vIHdheSBvdGhlciB0aGFuIHBlci1pbnN0YW5jZSBmb3IgYSBjbGllbnQg dG8gYXNrIGZvciBhIHBhcnRpY3VsYXIgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QuIFdoZXJl IGVsc2Ugd291bGQgdGhlIEFTIGZpbmQgb3V0IGFib3V0IGl0Pw0KDQpXZSBzdGlsbCBkaXNhZ3Jl ZSBvbiB0aGlzLiBJdCBpcyBteSBhc3NlcnRpb24gdGhhdCBjbGllbnRzIHNob3VsZCBORVZFUiBh c2sgZm9yIGEgcGFydGljdWxhciB0b2tlbiBhdXRoIG1ldGhvZC4gU2luY2UgaXQgaXMgdGhlIEFT IHRoYXQgaXMgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCwgdGhlbiBpdCBpcyB0aGUgQVMncyBy aWdodCB0byBzZXQgdGhlIGF1dGhlbnRpY2F0aW9uIHBvbGljeS4gIFRoZSByb2xlIG9mIGR5bmFt aWMgcmVnIGVuZHBvaW50IGlzIHRvIGluZm9ybSB0aGUgY2xpZW50IHdoYXQgaXQgbXVzdCBkby4g IE15IGFzc3VtcHRpb24gaXMgdGhhdCBkdXJpbmcgdGhlIGZpcnN0IHRpbWUgYSBwaWVjZSBvZiBz b2Z0d2FyZSBpcyByZWdpc3RlcmVkICh0aGUgZmlyc3QgaW5zdGFuY2UpLCB0aGVyZSBjb3VsZCBi ZSBzb21lIE9PQiBkaXNjdXNzaW9uIGJ5IGFuIGFkbWluaXN0cmF0b3IgdG8gYXBwcm92ZSB0aGUg cGFydGljdWxhciBhdXRoZW50aWNhdGlvbiB0eXBlIGZvciB0aGUgQVMgaW4gcXVlc3Rpb24uDQoN CkkgaGF2ZW4ndCBoZWFyZCBhIHJlYXNvbiBqdXN0aWZ5aW5nIHRoaXMgcGFyYW1ldGVyIG90aGVy IHRoZW4gIml0IGlzIG5lZWRlZCIuICBXaHk/DQoNClRoZSByb2xlIG9mIHRoZSBkeW5hbWljIHJl Z2lzdHJhdGlvbiBwcm90b2NvbCBpcyB0d29mb2xkOiBoYWxmIG9mIHRoYXQgaXMgdGhlIHNlcnZl ciBpbmZvcm1pbmcgdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgZG8uIEJ1dCB0aGUgb3RoZXIgaGFs ZiBpcyB0aGUgY2xpZW50IGluZm9ybWluZyB0aGUgc2VydmVyIHdoYXQgaXQgKmNhbiogZG8sIG9y IHdoYXQgaXQgKndhbnRzKiB0byBkby4NCg0KQW5kIGFnYWluLCB0aGVyZSdzIG5vIHdheSB0byBk aXN0aW5ndWlzaCBhIGZpcnN0IGluc3RhbmNlIGZyb20gYSBzdWJzZXF1ZW50IGluc3RhbmNlIHVu bGVzcyB5b3UncmUgZG9pbmcgc29tZXRoaW5nIGluIGFkZGl0aW9uLiBOb3RoaW5nIGlzIHN0b3Bw aW5nIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGZyb20gcmVnaXN0ZXJpbmcgYSBuZXcgaW5zdGFuY2Ug b2YgaXRzZWxmIGZvciBldmVyeSBzaW5nbGUgdXNlciBvciBldmVyeSBzaW5nbGUgdG9rZW4gdGhh dCBpdCB3YW50cyB0byBnZXQgYWNjZXNzIGZvci4gVGhhdCdzIGNvbXBsaWNhdGVkIGFuZCB3YXN0 ZWZ1bCBhbmQgbm90IGEgZ3JlYXQgaWRlYSwgc3VyZSwgYnV0ICB0aGVyZSdzIG5vIHVzZWZ1bCB3 YXkgdG8gcHJldmVudCB0aGF0IGtpbmQgb2YgYmVoYXZpb3IgaWYgeW91IGFsc28gd2FudCBvcGVu IHJlZ2lzdHJhdGlvbiBvZiBjbGllbnRzLg0KDQpJIHRoaW5rIHdlJ3ZlIGRpc2N1c3NlZCBob3cg cmVjb2duaXppbmcgc3Vic2VxdWVudCBpbnN0YW5jZXMgaXMgZWFzaWx5IGRvbmUuDQoNCkFzIEkg bWVudGlvbmVkIGluIHRoZSBvdGhlciB0aHJlYWQsIGlmIGEgZGV2ZWxvcGVyIGNob29zZXMgdG8g bGltaXQgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgY2xpZW50IGl0IG11c3QgZG8gc28gYnkgbG9v a2luZyB0byB0aGUgZGV2ZWxvcGVyIG9yIHN0YW5kYXJkIGJlaGluZCB0aGUgQVBJLiAgT3RoZXJ3 aXNlIHRoZXkgYXJlIHRha2luZyB0aGUgY2hhbmNlLiAgVGhlcmUncyBubyB3YXkgYSBkZXZlbG9w ZXIgY2FuIHF1ZXJ5IGFsbCB0aGUgcG90ZW50aWFsIGRlcGxveWVycyB0byBhc2sgd2hhdCBhdXRo biB0eXBlcyB3aWxsIHlvdSB1c2UuIEFzIEkgc2FpZCwgdGhlIG5ldCBlZmZlY3QgaW4gdGhlIGFi c2VuY2Ugb2YgYW4gQVBJIHN0YW5kYXJkIGRpY3RhdGluZyB3aGF0IHNob3VsZCBiZSBzdXBwb3J0 ZWQsIHRoZSBkZXZlbG9wZXIgd2lsbCBoYXZlIHRvIGltcGxlbWVudCBhbGwgbWV0aG9kcy4NCg0K TXkgcG9pbnQgaGVyZSBpcyB0aGF0IG5vbmUgb2YgdGhpcyBpcyBoZWxwZWQgYnkgdGhlIGNsaWVu dCBhcHAgc2F5aW5nIHdoYXQgaXQgc3VwcG9ydHMuIEEgZGV2ZWxvcGVyIHdobyB0YWtlcyB0aGUg cm91dGUgb2YgbGltaXRpbmcgaW1wbGVtZW50YXRpb24gdGFrZXMgdGhlIGNoYW5jZSB0aGF0IHRo ZSBzZXJ2ZXIgd2lsbCBub3QgYWNjZXB0LiAgU28gd2h5IG5lZ290aWF0ZSB3aXRoaW4gcmVnaXN0 cmF0aW9uPw0KDQpBbmQgdGhlcmUncyBubyB3YXkgb3RoZXIgdGhhbiBwZXItaW5zdGFuY2UgZm9y IHRoZSBzZXJ2ZXIgdG8gdGVsbCB0aGUgY2xpZW50IHdoaWNoIHRva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kIHRvIHVzZS4gQWxsIGluc3RhbmNlcyB3aWxsIHByb2JhYmx5IGFzayBmb3IgdGhlIHNh bWUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgZnJvbSBhbGwgYXV0aCBzZXJ2ZXJzIHRoZXkg dGFsayB0bywgcmlnaHQ/IEFuZCBlYWNoIEFTIHdpbGwgdGVsbCBlYWNoIGluc3RhbmNlIHRoYXQg cmVnaXN0ZXJzIHdpdGggaXQgdG8gdXNlIGEgcGFydGljdWxhciBhdXRoIG1ldGhvZC4gVGhlcmUg aXMgbm8gd2F5IHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIGFjcm9zcyAob3Ig d2l0aGluKSBhdXRoIHNlcnZlcnMgd2l0aG91dCBzcGVjaWZ5aW5nIGEgc2lnbmlmaWNhbnQgYW1v dW50IG9mIG90aGVyIG1hY2hpbmVyeS4NCg0KV2hpY2ggaXMgbm90IHRvIHNheSB0aGF0IGl0J3Mg bm90IHVzZWZ1bCBpbiBzb21lIGNpcmN1bXN0YW5jZXMgdG8gdGllIHRvZ2V0aGVyIGRpZmZlcmVu dCBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgY29kZSBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0aCBzZXJ2 ZXJzLiBUaGlzIGlzIHdoeSwgd2l0aCBCbHVlIEJ1dHRvbissIHdlIHNwZWNpZmllZCBhIHNwZWNp ZmljIHRva2VuIGZvcm1hdCBmb3IgdGhlIGluaXRpYWwgYWNjZXNzIHRva2VuIHRoYXQgdGhlIGNs aWVudHMgdXNlIHRvIGNhbGwgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCB0aGUgZmlyc3QgdGlt ZSwgIGFzIHdlbGwgYXMgYSBkaXNjb3ZlcnkgcHJvdG9jb2wgYWdhaW5zdCBhIGNlbnRyYWxpemVk IHNlcnZlciB0aGF0IGhhbmRsZXMgcHJlLXJlZ2lzdHJhdGlvbi4gQWxsIG9mIHRoaXMgbWFjaGlu ZXJ5IGlzLCBpbiBteSBvcGluaW9uLCBhIHN0dXBlbmRvdXMgb3ZlcmtpbGwgZm9yIHRoZSBnZW5l cmFsIGNhc2UsIHRob3VnaCBpZiBzb21lIGZvbGtzIGZpbmQgdXNlIGZvciBpdCBvdXRzaWRlIG9m IEJCKyB0aGVuIGl0J2QgYmUgYSBnb29kIHRoaW5nIHRvIGFic3RyYWN0IG91dCBhbmQgbWFrZSBp dHMgb3duIHNwZWMgdGhhdCBleHRlbmRzIHRoZSBEeW4gUmVnIHNwZWMgaW4gYSBmdWxseSBjb21w YXRpYmxlIHdheS4gRnVydGhlcm1vcmUsIGV2ZW4gaW4gQmx1ZSBCdXR0b24rIHdlIHNwZWNpZnkg dGhhdCBhbGwgYXV0aCBzZXJ2ZXJzIE1VU1QgYWxzbyBhY2NlcHQgb3BlbiByZWdpc3RyYXRpb24s IHdpdGhvdXQgYW4gaW5pdGlhbCBhY2Nlc3MgdG9rZW4sIHdoZXJlIHRoZSBjbGllbnQgc2ltcGx5 IHNob3dzIHVwIGFuZCBzYXlzICJoZXksIGhlcmUgYXJlIG15IHBhcmFtZXRlcnMuIiBUaGUgYXV0 aCBzZXJ2ZXIgaGFzIG5vIHdheSB0byBrbm93IGluIHRoaXMgY2FzZSBhbnkga2luZCBvZiBvdXQt b2YtYmFuZCBuZWdvdGlhdGlvbiBmb3IgZGlmZmVyZW50IHRoaW5ncy4gSW4gQkIrIHdlIGFyZSB3 cml0aW5nIHZlcnkgc3BlY2lmaWMgcG9saWN5IGd1aWRlbGluZXMgYWJvdXQgaG93IHRvIHByZXNl bnQgdGhlIFVYIGFuZCB0aGluZ3MgdG8gdGhlIGVuZCB1c2VyIGZvciBhbGwgb2YgdGhlc2UgZGlm ZmVyZW50IGNhc2VzLiBCdXQgYWdhaW4sIGFsbCBvZiB0aGlzIGlzIHNwZWNpZmljIHRvIHRoZSBC QisgdXNlIGNhc2UsIGFuZCBJIGRvbid0IHNlZSB2YWx1ZSBpbiBkcmFnZ2luZyBpdCBpbiB0byB0 aGUgcmVnaXN0cmF0aW9uIHNwZWMgb24gaXRzIG93bi4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGZh ciB0b28gbGltaXRpbmcuDQoNClNlZSBteSBwcmV2aW91cyBjb21tZW50cyBvbiBkaWZmZXJlbnRp YXRpbmcgY2xpZW50IGluc3RhbmNlcyBiZWluZyBvdXQgb2Ygc2NvcGUgd2l0aG91dCByZWNoYXJ0 ZXJpbmcgdG8gZG8gdGhpcyBuZXcgd29yayBhbmQgb24gd2hhdCB0aGUgcmVnaXN0cmF0aW9uX2Fj Y2Vzc190b2tlbiBpcy4gIEluIHNob3J0LCB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBp cyBhbiBSRkMgNjc1MCBiZWFyZXIgdG9rZW4gaXNzdWVkIHRvIHRoZSBwYXJ0eSByZWdpc3Rlcmlu ZyB0aGUgY2xpZW50LCBlbmFibGluZyBpdCB0byBzdWJzZXF1ZW50bHkgcmV0cmlldmUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIHRvIHBvdGVudGlhbGx5IHVw ZGF0ZSB0aGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGZvciB0aGF0IHJlZ2lzdGVyZWQgY2xp ZW50LiAgQWdhaW4sIEnigJlsbCB3b3JrIHdpdGggSnVzdGluIHRvIG1ha2Ugc3VyZSB0aGF0IHRo aXMgaXMgYXMgY2xlYXIgYXMgcG9zc2libGUgaW4gdGhlIHNwZWNpZmljYXRpb24uDQoNCkZpbmFs bHksIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGluY29uc2lzdGVudCBzdHlsZSBhcHByb2FjaCB3aXRo IGRyYWZ0LWhhcmRqb25vLW9hdXRoLXJlc291cmNlLXJlZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTAwLnR4dD4gd2hpY2ggdXNlcyBF VGFncy4gU2hvdWxkIHRoaXMgZHJhZnQgZG8gc28gYXMgd2VsbD8NCg0KVGhhdCdzIGFuIGluZGl2 aWR1YWwgc3VibWlzc2lvbiwgbm90IGEgd29ya2luZyBncm91cCBkcmFmdC4gTm9ib2R5IGhhcywg dW50aWwgbm93LCBldmVuIG1lbnRpb25lZCB0aGUgdXNlIG9mIEVUYWdzIGhlcmUuIFVNQSAod2hl cmUgdGhlIHJlc291cmNlIHJlZ2lzdHJhdGlvbiBkcmFmdCBjb21lcyBmcm9tKSB1c2VzIEVUYWdz LCBoZW5jZSB0aGVpciBpbmNsdXNpb24gdGhlcmUuIEkgcGVyc29uYWxseSBkb24ndCBzZWUgdGhl aXIgdXRpbGl0eSBoZXJlLCB0aG91Z2gsIGFuZCBJIHdvdWxkbid0IHdhbnQgdG8gaW5jbHVkZSBh IHdob2xseSBuZXcgbWVjaGFuaXNtIHRoaXMgbGF0ZS4NCg0KWWVzLiBUaG9tYXMnIGRyYWZ0IGlz IG5vdCBhIFdHIGRvY3VtZW50LiBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gaGUgZG9lc24ndCBoYXZl IGEgcG9pbnQuIEl0J3Mgd29ydGggZGlzY3Vzc2luZy4NCg0KT25lIGNvdWxkIGFyZ3VlIHRoYXQg dGhlIHBvaW50IG9mIGFuIEVUYWcgaXMgdGhhdCBpdCBpcyB1c2VmdWwgZm9yIGNoYW5nZSBkZXRl Y3Rpb24gd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgd3JpdGVycyB0byBhIHBhcnRpY3VsYXIgcmVz b3VyY2UuICBJbiB0aGUgZGVzaWduIG9mIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGVuZHBvaW50LCB0 aGVyZSBzaG91bGQgb25seSBiZSBvbmUgd3JpdGVyIC0tIHRoZSBjbGllbnQuIFRoaXMgaXMgYW4g aW1wb3J0YW50IG9ic2VydmF0aW9uLg0KDQpUaGVyZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0aGF0 IGhhbmRsZSB0aGlzIC0tIG5hbWVseSwgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gYW5k IHRoZSBjbGllbnRfaWQuIE1hbnkgaW5zdGFuY2VzIGluY2x1ZGUgdGhlIGNsaWVudF9pZCBpbiBz b21lIGZvcm0gaW4gdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGVuZHBvaW50J3MgVVJMIGZvciBz YW5pdHkgY2hlY2tpbmcsIGFzIGRlc2NyaWJlZCBpbiDCpzQuMS4NCg0KSWYgZXZlcnlvbmUgYWdy ZWVzLCBJJ20gaW4gYWdyZWVtZW50LiBCdXQgaXQgd2lsbCBsaWtlbHkgbWVhbiBjaGFuZ2VzIGZv ciB0aGUgcmVzb3VyY2UgcmVnIGRyYWZ0IGlmIGFkb3B0ZWQuDQoNCkVUYWdzIHNlZW0gbGlrZSBh biB1bm5lY2Vzc2FyeSBhZGRpdGlvbiAoYW5kIHBvdGVudGlhbCBjb21wbGljYXRpb24pIHRvIHRo ZSBzcGVjaWZpY2F0aW9uLiAgSXTigJlzIGFscmVhZHkgd29ya2luZyBmaW5lIGFzLWlzLg0KDQpT cGVjaWZpYyBpdGVtczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KInRva2VuX2VuZHBvaW50X2F1 dGhfbWV0aG9kIg0KDQpUaGVyZSBpcyBzb21lIGNvbmZ1c2lvbiBhcyB0byB3aGV0aGVyIHRoaXMg YXBwbGllcyB0byBzZXJ2ZXIgb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAgU3VnZ2VzdCByZW5h bWluZyBwYXJhbWV0ZXIgdG8gInRva2VuX2VuZHBvaW50X2NsaWVudF9hdXRoX21ldGhvZCINCg0K VGhpcyBpcyB0aGUgZmlyc3QgSSd2ZSBoZWFyZCBvZiB0aGlzIHBhcnRpY3VsYXIgY29uZnVzaW9u LiBJJ20gZmluZSB3aXRoIGVpdGhlciBuYW1lIGJ1dCBhdCB0aGlzIHN0YWdlIEkgZG9uJ3Qgd2Fu dCB0byBtYWtlIHN5bnRheCBjaGFuZ2VzIHdpdGhvdXQgdmVyeSwgdmVyeSBjb21wZWxsaW5nIHJl YXNvbnMgdG8gZG8gc28uDQoNClRoZSBxdWVzdGlvbiB3YXMgcmFpc2VkIHRvIG1lIGJ5IHNvbWUg bmV3IGRldmVsb3BlcnMuIEl0IHNlZW1zIG9idmlvdXMgdG8gdXMgYXMgZXhwZXJpZW5jZWQgT0F1 dGggcGVyc29ucywgYnV0IHRvIG5ldyBkZXZlbG9wZXJzIGl0IHNlZW1zIHVuY2xlYXIuICBBbHNv LCBub3cgdGhhdCB5b3UgYXJlIGludHJvZHVjaW5nIHJlZ2lzdHJhdGlvbiBhdXRoZW50aWNhdGlv biwgdGhlIHdob2xlIHRoaW5nIGdldHMgdmVyeSBjb25mdXNpbmcuIFNvIGl0IGlzIHVzZWZ1bCBk aXNhbWJpZ3VhdGUgYWxsIHRoZSBwYXJhbWV0ZXJzIHdoZXJlIHBvc3NpYmxlLiAgVGhhdCBzYWlk LCBJIHdvdWxkbid0IG1pbmQgc2hvcnRlciBuYW1lcyAobWF5YmUgbm90IHF1aXRlIGFzIHNob3J0 IGFzIHRoZSBKT1NFIHN0dWZmIDstKQ0KDQpGYWlyIGVub3VnaCwgYnV0IGFnYWluLCBJIG9ubHkg d2FudCB0byBkbyBzeW50YXggY2hhbmdlcyBpZiB0aGUgcmVzdCBvZiB0aGUgV0cgKnJlYWxseSog d2FudHMgdG8uDQoNCkkgYWdyZWUgd2l0aCBKdXN0aW4gaGVyZS4gIEnigJltIGZpbmUgY2xhcmlm eWluZyB0aGUgZGVzY3JpcHRpb24gb2YgdGhpcyBwYXJhbWV0ZXIgdG8gcmVzb2x2ZSB0aGUgcG90 ZW50aWFsIGFtYmlndWl0aWVzIHRoYXQgeW91IGNpdGUsIFBoaWwuICBJ4oCZbSBub3QgT0sgcmV2 aXNpbmcgdGhlIHN5bnRheCB3aXRob3V0IGEgY29tcGVsbGluZyByZWFzb24gdG8gZG8gc28uDQoN CltQSF0gSSBkb24ndCB0aGluayB3ZSdyZSBjaGFuZ2luZyBhbnkgc3ludGF4IGhlcmUuIEp1c3Qg Y2xhcmlmeWluZyB0aGUgbmFtZS4gVGhpcyBzZWVtcyBpbXBvcnRhbnQgbm93IHRoYXQgdGhlcmUg YXJlIDMgdHlwZXMgb2YgdG9rZW5zIGJlaW5nIG1hbmFnZWQgKHJlZ2lzdHJhdGlvbiwgY2xpZW50 LCBhY2Nlc3MpLg0KDQpJIHdvdWxkIG11Y2ggcHJlZmVyIGp1c3QgZHVtcGluZyB0aGUgcmVnaXN0 cmF0aW9uIGFjY2VzcyB0b2tlbiByYXRoZXIgdGhlbiByZW5hbWluZyBwYXJhbWV0ZXJzIHRoYXQg d291bGQgb3RoZXJ3aXNlIGJlIHVuY2xlYXIuDQoNClttYmpdIENoYW5naW5nIGEgbmFtZSBpcyBj aGFuZ2luZyB0aGUgc3ludGF4LiAgQXMgZm9yIGR1bXBpbmcgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nl c3MgdG9rZW4sIGdpdmVuIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gaXMgdXNl ZCBieSB0aGUgY29kZSBhdXRob3IgdG8gYWNjZXNzIG9uZSByZXNvdXJjZSBhbmQgdGhlIGNsaWVu dF9pZCBpcyB1c2VkIGJ5IHRoZSBjb2RlIHRvIGFjY2VzcyBhIGRpZmZlcmVudCByZXNvdXJjZSwg YW5kIHRoYXQgdGhlIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgdHdvIGtpbmRzIG9m IGFjY2VzcyBhcmUgdmVyeSBkaWZmZXJlbnQsIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBhIHNlY3Vy aXR5IGFuZCB1c2FiaWxpdHkgZGlzYXN0ZXIgdG8gdHJ5IHRvIGJsZW5kIHRoZW0gdG9nZXRoZXIu DQoNCiogQ3VycmVudGx5LCB0aGUgQVBJIG9ubHkgc3VwcG9ydHMgYSBzaW5nbGUgdmFsdWUgaW5z dGVhZCBvZiBhbiBhcnJheS4gIElmIHRoZSBwdXJwb3NlIGlzIHRvIGFsbG93IHRoZSBjbGllbnQg dG8ga25vdyB3aGF0IGF1dGggbWV0aG9kcyBpdCBzdXBwb3J0cywgdGhpcyBzaG91bGQgYmUgYW4g YXJyYXkgaW5kaWNhdGVkIHdoYXQgbWV0aG9kcyB0aGUgY2xpZW50IHN1cHBvcnRzIC0gb3IgaXQg c2hvdWxkIG5vdCBiZSB1c2VkLg0KDQpJIHdvdWxkIHJhdGhlciBsaWtlIHRoaXMgdG8gYmUgYW4g YXJyYXksIHBlcnNvbmFsbHksIGFuZCBicm91Z2h0IGl0IHVwIHdpdGggdGhlIE9wZW5JRCBDb25u ZWN0IHdvcmtpbmcgZ3JvdXAgYWJvdXQgc2l4IG1vbnRocyBhZ28uIEJ1dCB0aGVyZSBpdCB3YXMg ZGVjaWRlZCB0aGF0IGEgc2luZ2xlIHZhbHVlIHdhcyBzaW1wbGVyIGFuZCBzdWZmaWNpZW50IGZv ciB0aGUgcHVycG9zZS4gVGhlIElFVEYgZHJhZnQgaGFzIGluaGVyaXRlZCB0aGlzIGRlY2lzaW9u LiBJICpiZWxpZXZlKiAodGhvdWdoIGFtIG5vdCAxMDAlIHBvc2l0aXZlKSB0aGF0IEkgYnJvdWdo dCB1cCB0aGlzIHZlcnkgaXNzdWUgaW4gdGhlIFdHIGhlcmUgYnV0IGRpZG4ndCByZWNlaXZlIGFu eSB0cmFjdGlvbiBvbiBpdCwgc28gc2luZ2xlIGl0IHJlbWFpbnMuDQoNCkkgY2FuIGdldCBiZWhp bmQgbXVsdGlwbGUgdmFsdWVzLiBJbiB0aGlzIGNhc2UsIGl0IGNoYW5nZXMgdGhlIG1lYW5pbmcg b2YgdGhlIHBhcmFtZXRlci4gSW5zdGVhZCBvZiB0aGUgY2xpZW50IGZvcmNpbmcgdGhlIHNlcnZl ciB0byB1c2UgYSBwYXJ0aWN1bGFyIG1ldGhvZCwgdGhlIGNsaWVudCBpcyBpbmZvcm1pbmcgdGhl IHNlcnZlciBhYm91dCB3aGF0IG1ldGhvZHMgaXQgY2FuIHBlcmZvcm0uIFRoaXMgYWxsb3dzIHRo ZSBzZXJ2ZXIgdG8gYXNzaWduIHRoZSBhcHByb3ByaWF0ZSBtZXRob2QgYmFzZWQgb24gaXRzIG93 biBwb2xpY3kuDQoNCg0KQWxzbyBub3RlIHRoYXQgdGhpcyBmaWVsZCwgbGlrZSBhbGwgb3RoZXJz IGluIMKnMiwgcmVwcmVzZW50cyB0d28gdGhpbmdzOiB0aGUgY2xpZW50IHRlbGxpbmcgdGhlIHNl cnZlciAiSSB3YW50IHRvIHVzZSB0aGlzIHZhbHVlIGZvciB0aGlzIGZpZWxkIiwgYW5kIHRoZSBz ZXJ2ZXIgdGVsbGluZyB0aGUgY2xpZW50ICJ0aGlzIGlzIHRoZSB2YWx1ZSB5b3UgaGF2ZSBmb3Ig dGhpcyBmaWVsZCIuIEl0J3Mgbm90IGV4YWN0bHkgYSBuZWdvdGlhdGlvbiwgbW9yZSBsaWtlIG1h a2luZyBhIHBvbGl0ZSByZXF1ZXN0IHRvIGFuIGFic29sdXRlIGRpY3RhdG9yIHdobyBoYXMgdGhl IGxhc3Qgd29yZCBhbnl3YXkuIEJ1dCBhdCBsZWFzdCB0aGlzIGRpY3RhdG9yIGlzIG5pY2UgZW5v dWdoIHRvIHRlbGwgeW91IHdoYXQgdGhlaXIgZGVjaXNpb24gd2FzIGluc3RlYWQgb2YganVzdCBk ZWNhcGl0YXRpbmcgeW91Lg0KDQpUaGlzIGlzIHRoZSBoZWFydCBvZiBteSBvYmplY3Rpb24uIFRo aXMgZnV6emluZXNzIGlzIGlzIGdvaW5nIHRvIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMuDQoNClRo ZXJlIGlzIG5vIGZ1enppbmVzcyB0aGF0IEkgY2FuIHNlZSBoZXJlLiBJdCdzIHBhcmFsbGVsaXNt IGJldHdlZW4gd2hhdCBnb2VzIGluIHRvIHRoZSBlbmRwb2ludCBhbmQgd2hhdCBjb21lcyBvdXQg b2YgaXQuIFRoZSBzZW1hbnRpY3MgZm9yIHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UgYXJl IGRpZmZlcmVudCwgYW5kIGRpZmZlcmVudGlhYmxlIGJ5IHRoZSBmYWN0IHRoYXQgb25lIGlzIGEg cmVxdWVzdCBhbmQgdGhlIG90aGVyIGlzIGEgcmVzcG9uc2UuDQoNClRoZSBpbnRlci1vcCBpc3N1 ZSBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0IGlzIHRoYXQgdGhlIHNwZWMgZG9lcyBub3QgY3Vy cmVudGx5IHNwZWNpZnkgaWYgcGFydGljdWxhciBpbnB1dCB2YWx1ZXMgYXJlIHNpbmd1bGFyIG9y IG11bHRpcGxlLiAgSWYgYW4gaW1wbGVtZW50ZXIgYXNzdW1lcyBzaW5ndWxhciBhbmQgY2xpZW50 cyBhc3N1bWUgbXVsdGlwbGUsIHdlIGhhdmUgaXNzdWVzLg0KDQpUaGUgbXVsdGlwbGUvc2luZ2xl IGRpc2N1c3Npb24gYWJvdmUgZ2V0cyB0byB0aGUgaGVhcnQgb2Ygd2hhdCBJICpkbyogYmVsaWV2 ZSBpcyBhIGRlZmljaWVuY3kgaW4gdGhlIHNwZWNpZmljYXRpb24sIGFzIGl04oCZcyBjdXJyZW50 bHkgd3JpdHRlbi4gIFRoZSBhdXRob3JzLCBteXNlbGYgaW5jbHVkZWQsIGhhdmUgZmFpbGVkIHRv IG1ha2UgaXQgMTAwJSBjbGVhciB0aGF0IGRpc2NvdmVyeSBvZiBBdXRob3JpemF0aW9uIFNlcnZl ciBmdW5jdGlvbmFsaXR5IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLiAg SSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgd2UgbmVlZCB0byBhZGQgYSBjbGVhciBzdGF0ZW1lbnQg dG8gdGhpcyBlZmZlY3QgaW4gdGhlIGludHJvZHVjdGlvbiB0byB0aGUgc3BlY2lmaWNhdGlvbi4N Cg0KVGhlIHB1cnBvc2Ugb2YgdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjaWZp Y2F0aW9uIGlzIGZvciB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIHdpdGggdGhlIEF1dGhvcml6YXRp b24gU2VydmVyIGFuZCB0byBpbmZvcm0gaXQgb2YgcHJvcGVydGllcyBvZiB0aGUgY2xpZW50IHRo YXQgdGhlIEFTIG1heSB3YW50L25lZWQgdG8gYmUgYXdhcmUgb2YuICBJdCAqaXMgbm90KiB0aGUg cHVycG9zZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gZm9yIGl0IHRvIGJlIHVzZWQgYnkgY2xpZW50 cyBpbiBhbnkgbWFubmVyIHRvIGRpc2NvdmVyIGZlYXR1cmVzIG9mIHRoZSBBdXRob3JpemF0aW9u IFNlcnZlci4gIFRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlLg0KDQpbUEhd IEFncmVlZC4NCg0KDQpDdXJyZW50bHksIGNsaWVudHMgYXJlIGluc3RydWN0ZWQgYnkgUkZDIDY3 NDkgdG8gZGlzY292ZXIgaW5mb3JtYXRpb24gYWJvdXQgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIHRo ZXkgaW50ZXJhY3Qgd2l0aCBieSBjb25zdWx0aW5nIHRoZSDigJxzZXJ2aWNlIGRvY3VtZW50YXRp b27igJ0gKFJGQyA2NzQ5LCBTZWN0aW9ucyAzLjEgYW5kIDMuMikuICBUaGV5IGNhbiBhbHNvIGxl YXJuIGluZm9ybWF0aW9uIGFib3V0IEF1dGhvcml6YXRpb24gU2VydmVycyBpbiBzcGVjaWZpYyBj b250ZXh0cyB0aHJvdWdoIGRpc2NvdmVyeSBwcm90b2NvbHMgc3VjaCBhcyBPcGVuSUQgQ29ubmVj dCBEaXNjb3ZlcnkgKGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2Nv dmVyeS0xXzAuaHRtbCkgYW5kIFVNQSBEaXNjb3ZlcnkgKFRCRCkuDQoNCkkgc3VzcGVjdCB0aGF0 IGF0IHNvbWUgcG9pbnQsIHNvbWVvbmUgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgd2lsbCBw cm9wb3NlIGRldmVsb3BpbmcgYSBnZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBtZWNoYW5pc20sIHdo aWNoIHdpbGwgbGVhZCB0byBhIHJlY2hhcnRlcmluZyB0byBpbmNsdWRlIHRoaXMgd29yayBpbiB0 aGUgd29ya2luZyBncm91cOKAmXMgc2V0IG9mIGRlbGl2ZXJhYmxlcy4gIEkgd291bGQgc3VwcG9y dCBkb2luZyB0aGlzIHdvcmsgYW5kIHRoZSBuZWNlc3NhcnkgcmVjaGFydGVyaW5nIHRvIGRvIHNv Lg0KW1BIXSBTbywgZ2l2ZW4gdGhlIGFib3ZlLCB0aGUgY2xpZW50IHNob3VsZG4ndCBiZSBkaWN0 YXRpbmcgdG9rZW4gdHlwZS4gVGhlIEFTIHNob3VsZCBzaW1wbHkgYXNzaWduIHRoZSBjcmVkZW50 aWFsIGFuZCBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgdXNlLg0KDQpbbWJqXSBZb3Ug c2VlbSB0byBiZSAoaW50ZW50aW9uYWxseT8pIGlnbm9yaW5nIEpvaG4gQnJhZGxleeKAmXMgcG9p bnQgdGhhdCBpdOKAmXMgdGhlIGNsaWVudCB0aGF0IGtub3dzIHdoaWNoIG9mIHRoZSBzZWN1cml0 eSBwcm9maWxlcyBzdXBwb3J0ZWQgYnkgdGhlIEFTIHRoYXQgaXQgbmVlZHMgdG8gdXNlIOKAkyBu b3QgdGhlIEFTLiAgVGhlcmVmb3JlLCBmb3Igc2VjdXJpdHkgcmVhc29ucywgaXQgbXVzdCBiZSB0 aGUgY2xpZW50IHRoYXQgcGlja3MgdGhlIG1ldGhvZCBmcm9tIGFtb25nIHRob3NlIHN1cHBvcnRl ZCBieSB0aGUgQVMg4oCTIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZC4gIFRoZSBBUyBoYXMgbm8g d2F5IHRvIGtub3cgd2hpY2ggbWV0aG9kcyBhcmUgYXBwcm9wcmlhdGUgZm9yIHdoaWNoIGNsaWVu dHMsIGJ1dCB0aGUgY2xpZW50cyBkby4NCg0KV2UgYWdyZWUsIG5vIGRpc2NvdmVyeS4gIEJ1dCBJ IGFsc28gd2FudCB0byBlbGltaW5hdGUgbmVnb3RpYXRpb24gdGhhdCBkb2Vzbid0IGFjdHVhbGx5 IGhlbHAgYW55dGhpbmcuDQoNClttYmpdIEnigJltIG5vdCBkZXNjcmliaW5nIG5lZ290aWF0aW9u IGFib3ZlLiAgSeKAmW0gZGVzY3JpYmluZyB0aGUgcGFydHkgd2l0aCB0aGUga25vd2xlZGdlIHRv IG1ha2UgdGhlIGFwcHJvcHJpYXRlIGNob2ljZSBiZWluZyBhYmxlIHRvIG1ha2UgdGhhdCBjaG9p Y2UuDQoNClRoYXQgYmVpbmcgc2FpZCwgSSBzdHJvbmdseSBvcHBvc2UgdHJ5aW5nIHRvIHNob2Vo b3JuIHBpZWNlbWVhbCBhc3BlY3RzIG9mIGRpc2NvdmVyeSBpbnRvIHRoZSBEeW5hbWljIENsaWVu dCBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbi4gIEl0IGlzIGRpc3RpbmN0IGZ1bmN0aW9uYWxp dHkgYW5kIGRlc2VydmVzIGZpcnN0LWNsYXNzIGFuZCBzZXBhcmFibGUgdHJlYXRtZW50IGJ5IHRo ZSB3b3JraW5nIGdyb3VwLiAgRGlzY292ZXJ5IGlzIGZvciBwb3RlbnRpYWwgY2xpZW50cyB0byBs ZWFybiBwcm9wZXJ0aWVzIG9mIHRoZSBBUyBiZWZvcmUgcmVnaXN0cmF0aW9uLiAgUmVnaXN0cmF0 aW9uIGlzIGZvciBwb3RlbnRpYWwgY2xpZW50cyB0byBpbmZvcm0gdGhlIEFTIG9mIGl0cyBwcm9w ZXJ0aWVzLCBjcmVhdGluZyBhIHJlZ2lzdGVyZWQgY2xpZW50LiAgRGlzY292ZXJ5IHNlbmRzIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBBUyB0byB0aGUgQ2xpZW50LiAgUmVnaXN0cmF0aW9uIHNlbmRz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBDbGllbnQgdG8gdGhlIEFTLiAgVGhhdOKAmXMgYSBjbGVh biBzZXBhcmF0aW9uLiAgV2Ugc2hvdWxkIHN0cm9uZ2x5IHJlc2lzdCBtdWRkeWluZyB0aGUgdHdv IGZ1bmN0aW9ucy4NCg0KT0F1dGggMi4wIGlzIGEgc3VjY2VzcyBiZWNhdXNlIGl0IGRpZG7igJl0 IHRyeSB0byBib2lsIHRoZSBvY2Vhbi4gIEl0IHNwZWNpZmllZCBob3cgdG8gZG8gb25lIHRoaW5n IHdlbGwgaW4gYSBzaW1wbGUsIHdlYi1mcmllbmRseSBtYW5uZXIuICBXZSBzaG91bGQgZG8gdGhl IHNhbWUg4oCTIGZvY3VzaW5nIG9uIHNwZWNpZnlpbmcgaW50ZXJvcGVyYWJsZSBkeW5hbWljIGNs aWVudCByZWdpc3RyYXRpb24sIHdoaWxlIG1ha2luZyBpdCBjbGVhciB0aGF0IHRoaXMgaXMgZGlz dGluY3QgZnJvbSBkaXNjb3ZlcnkgYWJvdXQgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgcHJvcGVydGll cywgYW5kIG1ha2luZyBpdCBjbGVhciB0aGF0IGRpc2NvdmVyeSBpcyBvdXQgb2Ygc2NvcGUgZm9y IHRoaXMgd29yay4NCg0KSSBhcG9sb2dpemUgYXQgdGhpcyBwb2ludCBvbiBiZWhhbGYgb2YgbXlz ZWxmIGFuZCB0aGUgb3RoZXIgc3BlYyBlZGl0b3JzIGZvciBub3QgYmVpbmcgMTAwJSBjbGVhciB0 aGF0IGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IGlzIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlIGZv ciBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24uICBJZiB3ZSBoYWQgZG9uZSBzbywgSeKAmW0g c3VyZSB0aGF0IG1hbnkgb2YgdGhlIGN1cnJlbnQgcXVlc3Rpb25zIGFuZCBjb25mdXNpb25zIHdv dWxkIG5vdCBoYXZlIGFyaXNlbi4gIEkgdGhpbmsgd2XigJlkIGFzc3VtZWQgdGhhdCB0aGlzIHdh cyBvYnZpb3VzLCBidXQgZnJvbSB0aGUgY3VycmVudCBkaXNjdXNzaW9ucywgaXTigJlzIGFwcGFy ZW50IHRoYXQgaXTigJlzIG5vdCBvYnZpb3VzLiAgSSB3aWxsIHBlcnNvbmFsbHkgY29tbWl0IHRv IGNsYXJpZnlpbmcgdGhlIHNwZWNpZmljYXRpb24gYXQgdGhpcyBwb2ludCB0byBlbGltaW5hdGUg dGhpcyBwb3RlbnRpYWwgcG9pbnQgb2YgY29uZnVzaW9uLg0KDQpHZXR0aW5nIGJhY2sgdG8gdGhl IHNwZWNpZmljcywgdGhlIG9ubHkgdXNlZnVsIHB1cnBvc2Ugb2YgYSBtdWx0aS12YWx1ZWQg4oCc dG9rZW5fZW5kcG9pbnRfY2xpZW50X2F1dGhfbWV0aG9k4oCdIG1lbWJlciB3b3VsZCBiZSB0byBl bmFibGUgdGhlIGNsaWVudCB0byBkaXNjb3ZlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVu dGljYXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhlIEFTIGFmdGVyIHRoZSByZWdpc3RyYXRp b24gaGFkIGJlZW4gcGVyZm9ybWVkLiAgQnV0IHRoYXQgaXMgYSBkaXNjb3ZlcnkgZnVuY3Rpb24s IGFuZCBzbyBzaG91bGQgYmUgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHdvcmsg4oCTIG5vdCB0aGlz IHNwZWNpZmljYXRpb24uICBXZSBzaG91bGQgcmVzaXN0IHNob2Vob3JuaW5nIGluIGJpdHMgb2Yg ZGlzY292ZXJ5IGludG8gdGhpcyBzcGVjaWZpY2F0aW9uLiAgSXQgKmlzKiBhIHdvcnRod2hpbGUg dG9waWMsIGJ1dCBkZXNlcnZlcyBmdWxsIGNvbnNpZGVyYXRpb24gYnkgdGhlIHdvcmtpbmcgZ3Jv dXAgaW4gaXRzIG93biByaWdodC4gIFRoZXJlZm9yZSwgdGhpcyBtZW1iZXIgbXVzdCByZW1haW4g c2luZ2xlLXZhbHVlZCwgYW5kIGJlIGNsZWFybHkgc3BlY2lmaWVkIGFzIHRoZSBtZXRob2QgYnkg d2hpY2ggYSBjbGllbnQgaW5mb3JtcyB0aGUgQVMgd2hpY2ggdG9rZW4gZW5kcG9pbnQgYXV0aGVu dGljYXRpb24gbWV0aG9kIGl0IHdpbGwgdXNlLiAgQW55dGhpbmcgZWxzZSB3b3VsZCBiZSBzY29w ZSBjcmVlcCwgYW5kIHJlc3VsdCBpbiBhbiB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIHNwZWNp ZmljYXRpb24gYW5kIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQgY2xpZW50cy4NCg0KW1BIXSBB Z3JlZWQuIExldCdzIHJlbW92ZSB0aGUgcGFyYW1ldGVyLmluIHRoZSByZXF1ZXN0LiBJdCBzaG91 bGQgb25seSBiZSBpbiB0aGUgcmVzcG9uc2UuDQoNCiBbbWJqXSBSZW1vdmluZyB0aGUgcGFyYW1l dGVyIHdvdWxkIG1ha2UgaXQgaW1wb3NzaWJsZSBmb3IgdGhlIGNsaWVudCwgd2hpY2gga25vd3Mg d2hpY2ggc2VjdXJpdHkgcHJvZmlsZSBpdCBuZWVkcyB0byB1c2UsIHRvIGRlY2xhcmUgdG8gdGhl IEFTIHdoaWNoIG1ldGhvZCwgZnJvbSBhbW9uZyB0aGUgbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhl IEFTLCB0aGF0IGl0IG5lZWRzIHRvIHVzZS4gIFRoZSBjbGllbnQgTVVTVCBiZSB0aGUgb25lIGRv aW5nIHRoZSBjaG9vc2luZy4NCg0KKiBUaGVyZSBpcyBubyBhdXRobiBtZXRob2QgZm9yICJjbGll bnRfc2VjcmV0X3NhbWwiIG9yICJwcml2YXRlX2tleV9zYW1sIi4NCg0KTm9ib2R5IGhhcyByZWFs bHkgYXNrZWQgdGhhdCB0aGVzZSB0d28gYmUgaW5jbHVkZWQgb3Igc3BlY2lmaWVkLiBUaGUgZXh0 ZW5zaW9uIG1lY2hhbmlzbSAodXNpbmcgYW4gYWJzb2x1dGUgVVJJKSB3b3VsZCBhbGxvdyBzb21l b25lIGVsc2UgdG8gZGVmaW5lIHRoZXNlLiBJcyB0aGUgZGVmaW5pdGlvbiBpbiB0aGUgU0FNTCBB c3NlcnRpb24gZHJhZnQgc3VmZmljaWVudCBmb3IgdGhlaXIgdXNlPw0KDQpJIHRoaW5rIHRoaXMg aXMgY29taW5nIGZyb20gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIEpXVCBiZWFyZXIgZHJhZnQg YW5kIGEgU0FNTCBiZWFyZXIgZHJhZnQuICBUaGUgdHJ1dGggaXMgeW91IGFyZSBkZWZpbmluZyBh biBhdXRoZW50aWNhdGlvbiB0aGF0IGlzbid0IGV2ZW4gZGVmaW5lZC4NCg0KVGhlcmUgYXJlIG5v IHByb2ZpbGVzIHJlZmVyZW5jZWQgb3IgZGVmaW5lZCBmb3IgImNsaWVudF9zZWNyZXRfand0IiBv ciAicHJpdmF0ZV9rZXlfand0Ii4gTmVpdGhlciBvZiB0aGUgSldUIG9yIFNBTUwgQmVhcmVyIGRy YWZ0cyByZWZlcmVuY2VkIGNvdmVyIHRoZXNlIHR5cGVzIG9mIGZsb3dzLiBUaGV5IG9ubHkgY292 ZXIgYmVhcmVyIGZsb3dzLiAgImNsaWVudF9zZWNyZXRfand0IiBhbmQgInByaXZhdGVfa2V5X2p3 dCIgc2VlbSB0byBoYXZlIHNvbWUgbWVhbmluZyB3aXRoaW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJ IG5vdGUgdGhhdCBPSURDIGRvZXMgbm90IGZ1bGx5IGRlZmluZSB0aGVzZSBlaXRoZXIuDQoNClRo ZSBKV1QgYXNzZXJ0aW9uIGRyYWZ0IGRvZXMgc2F5IGhvdyB0byB1c2UgYSBKV1QgZm9yIGNsaWVu dCBhdXRoZW50aWNhdGlvbiwgYW5kIHRoZSBEeW5SZWcgdGV4dCBkaWZmZXJlbnRpYXRlcyBiZXR3 ZWVuIGEgY2xpZW50IHNpZ25pbmcgc2FpZCBKV1Qgd2l0aCBpdHMgb3duIHNlY3JldCBzeW1tZXRy aWNhbGx5IHZzLiBhIGNsaWVudCB1c2luZyBpdHMgb3duIHByaXZhdGUga2V5LCBhc3ltbWV0cmlj YWxseS4NCg0KQWN0dWFsbHkgbXkgaW50ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1 bWVzIHRoZSBKV1QgQmVhcmVyIGlzIGEgYmVhcmVyIHRva2VuLiAgVGhlIGFzc3VtcHRpb24gaXMg dGhhdCBpZiBhIGNsaWVudCBoYXMgdGhlIGFzc2VydGlvbiBpdCBoYXMgdGhlIHJpZ2h0IHRvIHBy ZXNlbnQgaXQuICBJT1cuIFRoZSBKV1QgQmVhcmVyIERyYWZ0IGlzIG1vc3QgZGVmaW5pdGl2ZWx5 IG5vdCBhIEpXVCBIb0sgRHJhZnQuICA6LSkNCg0KUmVnYXJkbGVzcywgeW91IGFyZSBpbnRyb2R1 Y2luZyBhIG5ldyBwcm9maWxlIHdoaWNoIGlzIHVuZGVmaW5lZC4NCg0KSSB0aGluayBJIHNlZSB0 aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFraW5nIG5vdywgbGV0IG1lIHRyeSB0byByZS1zdGF0ZSBp dDoNCg0KV2hpbGUgdGhlIGJhc2ljcyBvZiAiaG93IHRvIHByZXNlbnQgYSBKV1QgYXMgYSBjbGll bnQgY3JlZGVudGlhbCIgaXMgZGVmaW5lZCBoZXJlOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA1Lmh0bWwjcmZjLnNlY3Rpb24uMi4yICwgaXQn cyBub3QgY29tcGxldGVseSBzcGVjaWZpZWQgaW4gdGhhdCBpdCBkb2Vzbid0IGZ1bGx5IHJlc3Ry aWN0IHRoZSBzaWduYXR1cmUgc2VjcmV0IHNvdXJjZSwgdGhlIGF1ZGllbmNlIGNsYWltLCBhbmQg b3RoZXIgdGhpbmdzIHRoYXQgdGhlIEFTIHdvdWxkIG5lZWQgdG8gY2hlY2sgYW5kIHZhbGlkYXRl LiBSaWdodD8gVGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGRyYWZ0IGNhbiBkZWZpbmUgdGhvc2Ug Y2FzZXMgaW4gZ3JlYXRlciBkZXRhaWwgaWYgbmVlZGVkICh0aG91Z2ggSSB0aGluayBpdCBkb2Vz IHNvIHN1ZmZpY2llbnRseSBhcy1pcywgSSB3ZWxjb21lIG1vcmUgY2xhcml0eSkuDQoNCkknZCBi ZSBPSyB3aXRoIGFkZGluZyB0aGUgU0FNTCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwg b24gdGhlIEpXVCBiaXRzLCBvciBkcm9wcGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50 cyB0byBkbyBhbnkgb2YgdGhvc2UgYWN0aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpX VCBzdHVmZiBpcyBhbHJlYWR5IGluIHVzZSBhbmQgZnVuY3Rpb25pbmcgYW5kIGl0J2QgYmUgYSBz aGFtZSB0byBsZWF2ZSBpdCBvdXQuDQoNCkkgZ3Vlc3MgdGhlbiB0aGUgbWlzdGFrZSB0aGUgSldU IEJlYXJlciBhbmQgU0FNTCBCZWFyZXIgZHJhZnRzIGF1dGhvcnMgbWFkZSBpcyB0aGV5IGFzc3Vt ZWQgZXZlcnlvbmUgaGFkIHRoZSBzYW1lIGRlZmluaXRpb24gb2YgYmVhcmVyIHRva2VuLiAgVG8g bWUgYSBiZWFyZXIgdG9rZW4gb3BhcXVlIHRvIHRoZSBjbGllbnQuIEl0IHRoZXJlZm9yZSBjYW5u b3QgZG8gYW55IHNpZ25hdHVyZSB3b3JrIHdpdGggcmVnYXJkcyB0byB0aGUgdG9rZW4gaXRzZWxm LiAgTm93LCB0aGF0J3Mgbm90IHRvIHNheSBhIHByb29mIGRpZG4ndCBvY2N1ciBiZXR3ZWVuIHRo ZSBjbGllbnQgYW5kIHRoZSB0b2tlbiBpc3N1ZXIsIGJ1dCB3aGVuIHRoZSBjbGllbnQgd2llbGRz IHRoZSB0b2tlbiwgaXQgaXMgaGFuZGxpbmcgYW4gb3BhcXVlIHN0cmluZy4NCg0KVGhlIGNvbmNl cHQgb2YgY2xpZW50X3NlY3JldF9qd3Qgc3VnZ2VzdHMgYW4gSG9LIHByb2ZpbGUuICBUaGVyZWZv cmUgb2YgY291cnNlIHRoZSBiZWFyZXIgZHJhZnRzIGFyZSBhIGxpdHRsZSB1bmRlcnNwZWNpZmll ZCB3aGVuIGl0IGNvbWVzIHRvIEhvSyBwcm9maWxlcy4NCg0KU28gZm9yIGV4YW1wbGUsIHlvdSBu ZWVkIGEgZHJhZnQgbGlrZSB0aGUgTUFDIGRyYWZ0IGZvciB0aGlzLg0KDQpJJ20gaGF2aW5nIHRy b3VibGUgb3ZlcmFsbCBoZXJlLiBJdCBzZWVtcyB0aGUgYXV0aG4gdHlwZXMgc3VnZ2VzdCBPTkxZ IHN0cm9uZyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50cywgeWV0IGR1cmluZyB0aGUgcmVnaXN0 cmF0aW9uIHByb2Nlc3MgdGhlIGN1cnJlbnQgZHJhZnQgaXNuJ3QgYWJsZSB0byBjb3JyZWxhdGUg bXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHNvZnR3YXJlIChldmVuIGluIGEgc2VsZi1h c3NlcnRlZCB3YXkpLiAgSWYgeW91IGhhdmVuJ3QgYXV0aGVudGljYXRlZCB0aGUgc29mdHdhcmUg YXQgYWxsLCB3aHkgaGF2ZSBzdHJvbmcgY2xpZW50IGF1dGg/DQoNClRoZXJlIGlzIG5vIGF1dGhl bnRpY2F0aW9uIG1ldGhvZCBkZWZpbmVkIGZvciAiY2xpZW50X2JlYXJlcl9zYW1sIiBvciAiY2xp ZW50X2JlYXJlcl9qd3QiIG9yICJjbGllbnRfYmVhcmVyX3JlZiIuICBTaW5jZSB0aGUgYmVhcmVy IHNwZWNzIHNheSB0aGlzIGlzIGFjY2VwdGFibGUsICB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24g c3BlYyBzaG91bGQgYWNjZXB0IHRoZXNlLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBiaXQg LS0gd2hlcmUgYXJlIHRoZXNlIGRlZmluZWQgaW4gUkZDNjc1MD8gSSBkb24ndCBldmVuIGtub3cg d2hhdCBjbGllbnRfYmVhcmVyX3JlZiB3b3VsZCByZWZlciB0by4NCg0KNjc1MCBzYXlzIHlvdSBj YW4gdXNlIGEgYmVhcmVyIGFzc2VydGlvbiAoZS5nLiBvYnRhaW5lZCBmcm9tIGFuIElEUCkgYW5k IHdpZWxkIGl0IGFzIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbi4gIFRoZSBjbGllbnQgaXMg Tk9UIGNyZWF0aW5nIG9yIG1vZGlmeWluZyB0aGUgYXNzZXJ0aW9uLiBUaGUgY2xpZW50IGlzIHNp bXBseSBwYXNzaW5nIG9uZSBpdCBwcmV2aW91c2x5IG9idGFpbmVkLg0KDQpXaGF0IHlvdSBhcmUg ZGVzY3JpYmluZyBpcyBub3QgYmVhcmVyLiBJdCBpcyBob2xkZXIgb2Yga2V5LiBWZXJ5IHZlcnkg ZGlmZmVyZW50Lg0KDQoNCkEgcG9zc2libGUgc3VnZ2VzdGlvbiBpcyB0byByZW1vdmUgY2xpZW50 X3NlY3JldF9qd3QgYW5kIHByaXZhdGVfa2V5X2p3dCBhbmQgZGVmaW5lIHRob3NlIGFzIHJlZ2lz dGVyIGV4dGVuc2lvbnMgc2luY2UgdGhlc2UgcHJvZmlsZXMgYXJlIG5vdCBkZWZpbmVkLg0KDQpU aGF0J3MgcG9zc2libGUsIGJ1dCB0aGV5IGFyZSBpbiBhY3RpdmUgdXNlIGFscmVhZHkuDQoNClRo YXQgbWF5IGJlIHRydWUuIEJ1dCB0aGVuIHlvdSBuZWVkIHRvIHdyaXRlIGFub3RoZXIgZHJhZnQg c28gdGhlIHJlc3Qgb2YgdXMgY2FuIGltcGxlbWVudCBpdCBpbiBhbiBpbnRlcm9wZXJhYmxlIHdh eS4gIE1lIEkgcHJlZmVyIG5vdCB0byBndWVzcyB3aGF0IHlvdSBhcmUgZG9pbmcuDQoNClRoaXMg bXVjaCBJIGFncmVlIHdpdGguDQoNCkp1c3RpbiwgSm9obiwgYW5kIEkgZGlzY3Vzc2VkIHRoaXMg aXNzdWUgYW5kIGFncmVlIHdpdGggeW91ciBzdWdnZXN0aW9uLCBQaGlsLiAgU2luY2UgdGhleSBh cmUgbm90IGNvbXBsZXRlbHkgc3BlY2lmaWVkLCB3ZSB3aWxsIHJlbW92ZSB0aGUgY2xpZW50X3Nl Y3JldF9qd3QgYW5kIHByaXZhdGVfa2V5X2p3dCBtZXRob2RzIGZyb20gdGhlIHNwZWNpZmljYXRp b24gYW5kIGFkZCBhIHJlZ2lzdHJ5LCBlbmFibGluZyBzcGVjaWZpY2F0aW9uIHRoYXQgZG8gZnVs bHkgc3BlY2lmeSB0aGVzZSBhbmQgb3RoZXIgdG9rZW4gZW5kcG9pbnQgYXV0aGVudGljYXRpb24g bWV0aG9kcywgaW5jbHVkaW5nIHBvdGVudGlhbCBtZXRob2RzIHVzaW5nIFNBTUwgYXNzZXJ0aW9u cywgdG8gcmVnaXN0ZXIgdGhlbSBpbiB0aGUgcmVnaXN0cnksIHJhdGhlciB0aGFuIHRyeWluZyB0 byBiYWtlIHRoZW0gaW50byB0aGUgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHNwZWNpZmlj YXRpb24uDQoNCkFib3V0ICJ0b3NfdXJpIiBhbmQgInBvbGljeV91cmkiDQoNClRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIHRvc191cmkgYW5kIHBvbGljeV91cmkgaXMgdW5jbGVhci4gIENhbiB3ZSBj bGFyaWZ5IG9yIGNvbWJpbmUgdGhlbT8NCg0KVGVybXMgb2Ygc2VydmljZSBhbmQgcG9saWN5IGFy ZSB0d28gZGlmZmVyZW50IGRvY3VtZW50cy4gT25lIGlzIHNvbWV0aGluZyB0aGF0IGEgdXNlciBh Y2NlcHRzIChnZW5lcmFsbHkgZGVzY3JpYmluZyB3aGF0IHRoZSB1c2VyIHdpbGwgZG8pLCBvbmUg aXMgYSBzdGF0ZW1lbnQgb2Ygd2hhdCB0aGUgc2VydmljZSBwcm92aWRlciAoaW4gdGhpcyBjYXNl LCB0aGUgY2xpZW50KSB3aWxsIGRvLiBNb3JlIGltcG9ydGFudGx5LCB3ZSB1c2VkIHRvIGhhdmUg b25seSBvbmUsIGFuZCBzZXZlcmFsIHBlb3BsZSBhc2tlZCBmb3IgdGhlbSB0byBiZSBzcGxpdC4N Cg0KU2V2ZXJhbCBkZXZlbG9wZXJzIHdlcmUgY29uZnVzZWQgYnkgdGhpcy4gSW4gcGFydGljdWxh ciB0aGV5IGNvdWxkbid0IGZpZ3VyZSBvdXQgd2hpY2ggd2FzIHVzZWQgZm9yIHdoYXQuICBKdXN0 IHBhc3NpbmcgYWxvbmcgdGhlIGZlZWRiYWNrLg0KDQpPSywgdGhlIGRpc3RpbmN0aW9uIHRoYXQg SSBzZWUgaXMgdGhhdCB0aGUgVE9TIGlzIGNvbnRyYWN0dWFsLCB0aGUgUG9saWN5IGlzIGEgc3Rh dGVtZW50LiBSZS1yZWFkaW5nIHRoZSBkZWZpbml0aW9ucyBpbiB0aGVyZSByaWdodCBub3csIHRo YXQgY2FuIGJlIG1hZGUgbXVjaCBjbGVhcmVyLiAoSXQgZXZlbiBsb29rcyBsaWtlIHNvbWUgT0lE QyB0ZXh0IGxlYWtlZCBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIHBvbGljeV91cmkgYW5kIHRoYXQg aGFkbid0IGJlZW4gY2F1Z2h0IHlldC4pDQoNCkkgc3VwcG9ydCBjbGFyaWZ5aW5nIHRoZSBsYW5n dWFnZSBvbiB0aGVzZSBkZWZpbml0aW9ucywgYW5kIHdpbGwgd29yayB3aXRoIEp1c3RpbiB0byBk byBzby4NCg0KQWxzbywgYXJlbid0IHRoZXNlIHJlYWxseSBVUklzIG9yIGFyZSB0aGV5IG1lYW50 IHRvIGJlIFVSTHM/DQoNClRoZXJlIHdhcyBhbHJlYWR5IGRpc2N1c3Npb24gYWJvdXQgdGhpcyBv biB0aGUgbGlzdDogVGhlIElFVEYgaXMgYXBwYXJlbnRseSB0cnlpbmcgdG8gZGVwcmVjYXRlIFVS TCBpbiBmYXZvciBvZiBVUkkgaW4gbmV3IHNwZWNzLiBTbyBpbiBwcmFjdGljZSB0aGV5J2xsIG5l YXJseSBhbHdheXMgYmUgVVJMcywgYnV0IHNpbmNlIGFsbCBVUkxzIGFyZSBVUklzIHdlJ3JlIG5v dCB0ZWNobmljYWxseSBpbmNvcnJlY3QgaW4gZm9sbG93aW5nIHRoZSBuZXcgcG9saWN5LiBBbmQg aXQgbWFrZXMgdGhlIElFU0cgbGVzcyBtYWQgYXQgdXMsIHdoaWNoIGlzIGEgcGx1cy4NCg0KQXJn LiBOaWNlLiAgVGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5IHRoZSB2YWx1ZSBwYXNzZWQgbXVzdCBy ZXNvbHZlIHRvIGEgdmFsaWQgd2ViIHBhZ2UsIGRvY3VtZW50LCB3aGF0ZXZlci4NCg0KVGhhdCdz IGZhaXIsIGFuZCBpdCdzIHNvbWV0aGluZyB0aGF0IHRoZSBBUyBjYW4gZXZlbiBjaGVjayBpZiBp dCB3YW50cyB0by4NCg0KQWdyZWVkIG9uIHRoaXMgY2xhcmlmaWNhdGlvbi4NCg0KQWJvdXQgImp3 a3NfdXJpIg0KDQpBIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDkgaXMgbmVlZGVkLg0KDQpZZXMs IHlvdSdyZSBjb3JyZWN0LCBJJ2xsIGFkZCB0aGF0Lg0KDQpTaG91bGQgYmUgVVJMIGluc3RlYWQg b2YgVVJJPw0KDQpTZWUgYWJvdmUuIDopDQoNCkFncmVlZCBvbiBhZGRpbmcgdGhpcyByZWZlcmVu Y2UuDQoNClNlY3Rpb24gMi4xDQoNCkluIHRoZSB0YWJsZSB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6 Z3JhbnQtdHlwZTpqd3QtYmVhcmVyDQppcyBtaXNzaW5nLg0KDQpJdCdzIHRoZXJlIGluIHRoZSBj b3B5IG9mIC0xMCBJJ20gcmVhZGluZyBvZmYgb2YgaWV0Zi5vcmc8aHR0cDovL2lldGYub3JnLz4g cmlnaHQgbm93IOKApiA/DQonDQpTb3JyeSBJIG1lYW50OiB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6 Z3JhbnQtdHlwZTpzYW1sLWJlYXJlcg0KDQpBaCwgdGhhdCBtYWtlcyBtb3JlIHNlbnNlLiBJZiB0 aGUgV0cgd2FudHMgdG8gYWRkIGluIFNBTUwgc3VwcG9ydCB0byBwYXJhbGxlbCB0aGUgSldUIHN1 cHBvcnQsIEknZCBiZSBPSyB3aXRoIHRoYXQuDQoNCuKAnEFzIHN1Y2gsIGEgc2VydmVyIHN1cHBv cnRpbmcgdGhlc2UgZmllbGRzIFNIT1VMRCB0YWtlIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IGEgY2xp ZW50IGNhbm5vdCByZWdpc3RlciBpdHNlbGYgaW50byBhbiBpbmNvbnNpc3RlbnQgc3RhdGUu4oCd DQoNCldlIG1heSB3YW50IHRvIGRlZmluZSBtb3JlIGRldGFpbGVkIEhUVFAgZXJyb3IgcmVzcG9u c2UuIEUuZy4gNDAwIHN0YXR1cyBjb2RlICsgZGVmaW5lZCBlcnJvciBjb2RlICjigJxpbnZhbGlk X2NsaWVudF9tZXRhZGF0YeKAnSk/DQoNCkknZCBiZSBmaW5lIHdpdGggZGVmaW5pbmcgYSBtb3Jl IGV4cGxpY2l0IGVycm9yIHN0YXRlIGluIHRoaXMgY2FzZS4gSSB0aGluayBpdCB3b3VsZCBoZWxw IGludGVyb3AgZm9yIHRoZSBzZXJ2ZXJzIHRoYXQgd2FudCB0byBlbmZvcmNlIGdyYW50LXR5cGUg YW5kIHJlc3BvbnNlLXR5cGUgcmVzdHJpY3Rpb25zLCBidXQgc2VydmVycyB0aGF0IGNhbid0IG9y IGRvbid0IGNhcmUgYWJvdXQgcmVzdHJpY3RpbmcgZ3JhbnRzIHR5cGVzIGFuZCB3aGF0bm90IGRv bid0IGhhdmUgdG8gZG8gYW55dGhpbmcgc3BlY2lhbC4NCg0KSSAqdGhpbmsqIHRoYXQgdGhpcyBn b2VzIGF3YXkgd2l0aCB0aGUgZGVsZXRpb24gb2YgY2xpZW50X3NlY3JldF9qd3QgYW5kIHByaXZh dGVfa2V5X2p3dCBpbiBmYXZvciBvZiB0aGUgcmVnaXN0cnnigKYgIEnigJlsbCBkbyBhIGNvbnNp c3RlbmN5IGNoZWNrIGFuZCB2ZXJpZnkgdGhhdCB3aGVuIHRoZSBzcGVjIGlzIHVwZGF0ZWQgYWNj b3JkaW5nbHkuDQpbUEhdIEFncmVlZC4NCg0KDQpTZWN0aW9uIDIuMg0KDQpNYXkgd2FudCB0byBh ZGQ6DQoNCldoZW4g4oCcI+KAnSBsYW5ndWFnZSB0YWcgaXMgbWlzc2luZywgKGUuZy4g4oCcI2Vu 4oCdIGlzIG1pc3NpbmcgaW4g4oCcY2xpZW50X25hbWXigJ0sIGluc3RlYWQgb2Yg4oCcY2xpZW50 X25hbWUjZW7igJ0pIHRoZSBPQXV0aCBzZXJ2ZXIgbWF5IHVzZSBpbnRlcnByZXQgdGhlIGxhbmd1 YWdlIHVzZWQgYmFzZWQgb24gc2VydmVyIGNvbmZpZ3VyYXRpb24gb3IgaGV1cmlzdGljcy4NCg0K VGhhdCBzZWVtcyBpbmNvbnNpc3RlbnQgd2l0aCB3aGF0IHdlIGFscmVhZHkgaGF2ZToNCg0KSWYg YW55IGh1bWFuLXJlYWRhYmxlIGZpZWxkIGlzIHNlbnQgd2l0aG91dCBhIGxhbmd1YWdlIHRhZywg cGFydGllcyB1c2luZyBpdCBNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9ucyBhYm91dCB0aGUg bGFuZ3VhZ2UsIGNoYXJhY3RlciBzZXQsIG9yIHNjcmlwdCBvZiB0aGUgc3RyaW5nIHZhbHVlLCBh bmQgdGhlIHN0cmluZyB2YWx1ZSBNVVNUIGJlIHVzZWQgYXMtaXMgd2hlcmV2ZXIgaXQgaXMgcHJl c2VudGVkIGluIGEgdXNlciBpbnRlcmZhY2UuDQoNCldoaWNoIGlzIHRvIHNheSwgdHJlYXQgaXQg YXMgYSByYXcgYnl0ZS12YWx1ZS1zdHJpbmcgYW5kIGRvbid0IHRyeSB0byBnZXQgZmFuY3kuDQoN Ckkgd2lsbCBkaXNjdXNzIHdpdGggb3VyIGRldmVsb3BlcnMuIEknbSBub3Qgc3VyZSB0aGUgYXMt aXMgd29ya3MuDQoNCklzIGl0IHRoZSBpbnRlbnQgdGhhdCB3aGVuIHRoZSBjbGllbnQgaGFzIGxv Y2FsaXplZCAiY2xpZW50X25hbWUiIGZvciBleGFtcGxlLCBpdCBzaG91bGQgcGFzcyBhbGwgbGFu Z3VhZ2UgdmFyaWF0aW9ucyBpbiBhIEpTT04gYXJyYXk/DQoNCk9yLCBzaG91bGQgcGFydCBvZiB0 aGUgcmVnaXN0cmF0aW9uIGJlIHRvIGluZGljYXRlIHdoaWNoIGludGVyZmFjZSBsYW5ndWFnZSB0 aGUgY2xpZW50IHdpc2hlcyB0byB1c2U/ICBUaGVuIGl0IG9ubHkgcGFzc2VzIGEgc2luZ2xlIHZh bHVlIGZvciB0aGF0IHJlZ2lzdHJhdGlvbj8NCg0KDQpObywgdGhlIGNsaWVudCBzaG91bGQgcGFz cyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNlcGFyYXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhp cyBpbiBpdHMgZXhhbXBsZToNCg0KDQogICAiY2xpZW50X25hbWUiOiAiTXkgRXhhbXBsZSIsDQoN CiAgICJjbGllbnRfbmFtZSNqYS1KcGFuLUpQIjoNCg0KICAgICAi44Kv44Op44Kk44Ki44Oz44OI 5ZCNIiwNClNob3VsZCB3ZSBhZGQgdGhhdCB0byBhdCBsZWFzdCBvbmUgb2YgdGhlIGV4YW1wbGVz IGluIER5blJlZz8gKFRoZSBsYW5ndWFnZSB0YWdzIGFyZSBhIGxhdGUgYWRkaXRpb24sIHNvIHRo ZSBleGFtcGxlcyBkb24ndCByZWZsZWN0IGl0LikNCg0KQW4gZXhhbXBsZSB3b3VsZCBkZWZpbml0 ZWx5IGhlbHAuDQpJZiB0aGUgY2xpZW50IHBhc3NlcyBvbmx5IGEgc2luZ2xlIHVuYWRvcm5lZCBm aWVsZCwgdGhlIEFTIGNhbid0IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgd2hhdCBsYW5ndWFn ZSBpdCBpcy4gVGhpbmsgb2YgdGhpcyBhcyB0aGUgaW50ZXJuYXRpb25hbGl6ZWQgdmFsdWUgb2Yg dGhlIGZpZWxkIHdoaWxlIHRoZSBsYW5ndWFnZSB0YWdzIGFyZSB0aGUgbG9jYWxpemVkIHZlcnNp b25zIG9mIHRoZSBmaWVsZC4gVGhpcyBpcyB3aHkgd2UgcmVjb21tZW5kIHRoYXQgdGhlIGJhcmUt dmFsdWUgYWx3YXlzIGJlIHNlbnQgYnkgdGhlIGNsaWVudCwgc28gdGhhdCBpbiB0aGUgbGFjayBv ZiBhbnl0aGluZyBtb3JlIHNwZWNpZmljLCB0aGUgQVMgY2FuIGF0IGxlYXN0IGRvICpzb21ldGhp bmcqIHdpdGggaXQuDQoNClBhc3NpbmcgaW4gYSAiZGVmYXVsdCIgbGFuZ3VhZ2UgZmllbGQgKGxp a2UgZGVmYXVsdF9sb2NhbGUgb3IgdGhlIGxpa2UpIGlzIG9ubHkgZ29pbmcgdG8gbGVhZCB0byBw YWluIGZvciBpbXBsZW1lbnRvcnMgb2YgYm90aCBjbGllbnRzIGFuZCBzZXJ2ZXJzLCBhbmQgaXQn cyBnb2luZyB0byBodXJ0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mIHRoZSBodW1hbi1yZWFkYWJs ZSBmaWVsZHMuDQoNCkkgdGhpbmsgd2hhdCBJIG1lYW50IGlzIHNpbmNlIHlvdSBhcmUgYWxsb3dp bmcgZWFjaCBjbGllbnQgdG8gcmVnaXN0ZXIgZGlmZmVyZW50IHRoaW5ncywgQU5EIHRoZSBjbGll bnQgbGlrZWx5IGFscmVhZHkga25vd3MgdGhlIHVzZXIncyBwcmVmZXJyZWQgbGFuZ3VhZ2UsIHdo eSB3b3VsZG4ndCB0aGUgY2xpZW50IGp1c3QgcGFzcyB0ZXh0IHZhbHVlcyBpbiBvbmUgbGFuZ3Vh Z2UgYW5kIGFub3RoZXIgcGFyYW1ldGVyIGluZGljYXRpbmcgcHJlZmVycmVkIGxhbmd1YWdlIGlu IHRoZSBjYXNlIG9mIGFueSBzZXJ2aWNlIGdlbmVyYXRlZCB0ZXh0Lg0KDQpJcyB0aGUgcmVhc29u IHlvdSBhcmUgcGFzc2luZyBtdWx0aXBsZSBsb2NhbGl6YXRpb25zIGlzIHNvIHRoYXQgeW91IGNh biB1c2UgdGhlIHByZWZlcnJlZCBsYW5ndWFnZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgcmF0aGVy IHRoZW4gdGhlIGNsaWVudCB1c2VyPyBJIHdvbmRlciBpZiB0aGF0IGlzIGNvcnJlY3QuICBJZiB0 aGUgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgYXJlIGluIGZhY3QgZGlmZmVyZW50LCB3aGF0IHdvdWxk IHRoZSB1c2VyIG9mIHRoZSBjbGllbnQgYXBwIGV4cGVjdD8NCg0KLS0tLT4gYW55IG11bHRpLWxp bmd1YWwgcGVvcGxlIGhhdmUgYW55IG9waW5pb25zIGhlcmU/DQoNCldpdGhvdXQgc3BlY2lmaWMg cHJvcG9zZWQgdGV4dCBjaGFuZ2VzIHRvIHJldmlldywgaXTigJlzIGhhcmQgdG8ga25vdyB3aGF0 IHRvIHRoaW5rIGFib3V0IHRoaXMgY29tbWVudC4gIFVubGVzcyBhIHNwZWNpZmljIHByb3Bvc2Vk IHRleHQgY2hhbmdlIGlzIHNlbnQgdG8gdGhlIGxpc3Qgd2l0aCBjbGVhciByYXRpb25hbGUgZm9y IHdoeSBpdOKAmXMgYmV0dGVyIHRoYW4gd2hhdOKAmXMgdGhlcmUgbm93IGFuZCByZXZpZXdlZCBi eSB0aGUgd29ya2luZyBncm91cCwgSSBkb27igJl0IGJlbGlldmUgd2Ugc2hvdWxkIGNoYW5nZSB0 aGUgc3BlY2lmaWNhdGlvbiBpbiByZXNwb25zZSB0byB0aGlzIGNvbW1lbnQuDQoNCltQSF0gSSBh Z3JlZS4gSSBwbGFuIHRvIGZvbGxvdyB1cCBhbmQgc2VlIGlmIEkgY2FuJ3QgZ2V0IG1vcmUgY2xh cmlmaWNhdGlvbiBvbiByZXF1aXJlbWVudHMgZnJvbSBteSBzaWRlLg0KDQoNClNlY3Rpb24gMw0K DQpFeGlzdGluZyB0ZXh0Og0KDQrigJxJbiBvcmRlciB0byBzdXBwb3J0IG9wZW4gcmVnaXN0cmF0 aW9uIGFuZCBmYWNpbGl0YXRlIHdpZGVyIGludGVyb3BlcmFiaWxpdHksIHRoZSBDbGllbnQgUmVn aXN0cmF0aW9uIEVuZHBvaW50IFNIT1VMRCBhbGxvdyBpbml0aWFsIHJlZ2lzdHJhdGlvbiByZXF1 ZXN0cyB3aXRoIG5vIGF1dGhlbnRpY2F0aW9uLiAgVGhlc2UgcmVxdWVzdHMgTUFZIGJlIHJhdGUt bGltaXRlZCBvciBvdGhlcndpc2UgbGltaXRlZCB0byBwcmV2ZW50IGEgZGVuaWFsLW9mLXNlcnZp Y2UgYXR0YWNrIG9uIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50LuKAnQ0KDQpJIHdv dWxkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoZSBmaXJzdCDigJxTSE9VTETigJ0gdG8g4oCcTUFZ4oCd LiAgIEluIG1vc3QgY2xvdWQgc2VydmljZXMsIHRoZSBmaXJzdCBjbGllbnQgaXMgcmVnaXN0ZXJl ZCBieSBhIGh1bWFuIHVzZXIuIFRoZW4sIG90aGVyIGNsaWVudHMgY2FuIGJlIGZ1cnRoZXIgdXNl ZCB0byBhdXRvbWF0ZSBvdGhlciBjbGllbnQgcmVnaXN0cmF0aW9uLiAgU28sIHRoZSBmaXJzdCBy ZXF1ZXN0IHdvdWxkIHR5cGljYWxseSBjb21lIHdpdGggYW4gYXV0aGVudGljYXRlZCB1c2VyIGlk ZW50aXR5Lg0KDQpJIHRoaW5rIHRoZSB3ZWlnaHQgb2YgIlNIT1VMRCIgaXMgYXBwcm9wcmlhdGUg aGVyZSwgYmVjYXVzZSBJIGJlbGlldmUgdGhhdCB0dXJuaW5nIG9mZiBvcGVuIHJlZ2lzdHJhdGlv biBhdCB0aGUgQVMgKHdoaWNoIGlzIHdoYXQgdGhpcyBpcyB0YWxraW5nIGFib3V0KSByZWFsbHkg b3VnaHQgdG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRoZXIgdGhhbiB0aGUgcnVsZS4NCg0KSSB0aGlu ayB5b3UgYXJlIHJlYWRpbmcgaXQgd3JvbmcgLS0gYSBkb3VibGUtbmVnYXRpdmUgaXNzdWUuIFRo ZSBlbmQgb2YgdGhlIHNlbnRlbmNlIGlzICJubyBhdXRoZW50aWNhdGlvbiIuICBZb3UgYXJlIGlt cGx5aW5nIHRoYXQgTk8gQXV0aGVudGljYXRpb24gdXMgd2hhdCBzaG91bGQgbm9ybWFsbHkgYmUg ZG9uZS4gSSB0aGluayB5b3UgaW50ZW5kIGFub255bW91cyBhdXRoZW50aWNhdGlvbiB0byBiZSB0 aGUgZXhjZXB0aW9uIHJhdGhlciB0aGFuIHRoZSBydWxlIGRvbid0IHlvdT8NCg0KTm8sIEkgdGhp bmsgdGhhdCBhbm9ueW1vdXMgYXV0aGVudGljYXRpb24gc2hvdWxkIGJlIHRoZSBydWxlLiBPcGVu IHJlZ2lzdHJhdGlvbiBzaG91bGQgYmUgZGVmYXVsdC4NCg0KSSBkaXNhZ3JlZS4gIEFnYWluLCAg dGhlIHNwZWMgc2VlbXMgY29udHJhZGljdG9yeS4gSXQgc3VnZ2VzdHMgc3Ryb25nIGNsaWVudCBh dXRoIG1ldGhvZHMgYW5kIGF0IHRoZSBzYW1lIHRpbWUgYW5vbnltb3VzIHJlZ2lzdHJhdGlvbi4g IFllcyB5b3UgZ2FpbiB1bmlxdWVuZXNzLCBidXQgdGhhdCdzIGFib3V0IGl0Lg0KDQpPbiB0aGUg ZmxpcCBzaWRlLCB0aGUgZWFybGllciBwYXJhZ3JhcGg6DQoNCuKAnFRoZSBDbGllbnQgUmVnaXN0 cmF0aW9uIEVuZHBvaW50IE1BWSBhY2NlcHQgYW4gaW5pdGlhbCBhdXRob3JpemF0aW9uIGNyZWRl bnRpYWwgaW4gdGhlIGZvcm0gb2YgYW4gT0F1dGggMi4wIFtSRkM2NzQ5XSBhY2Nlc3MgdG9rZW4g aW4gb3JkZXIgdG8gbGltaXQgcmVnaXN0cmF0aW9uIHRvIG9ubHkgcHJldmlvdXNseSBhdXRob3Jp emVkIHBhcnRpZXMuIFRoZSBtZXRob2QgYnkgd2hpY2ggdGhpcyBhY2Nlc3MgdG9rZW4gaXMgb2J0 YWluZWQgYnkgdGhlIHJlZ2lzdHJhbnQgaXMgZ2VuZXJhbGx5IG91dC1vZi1iYW5kIGFuZCBpcyBv dXQgb2Ygc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnQ0KDQpJIHRlbmQgdG8gdGhpbmsg aXQgd291bGQgYmUgYmV0dGVyIHRvIGNoYW5nZSB0aGlzIOKAnE1BWeKAnSB0byDigJxTSE9VTETi gJ0uDQoNClRoYXQgYWNjZXNzIHRva2VuIHdvdWxkIGNhcnJ5IGEgaHVtYW4gdXNlciBhdXRoZW50 aWNhdGVkIGlkZW50aXR5IHNvbWVob3cuIEluIHNvbWUgY2FzZXMsIGl0IGNhbiBiZSBhIHB1cmUg YXV0aGVudGljYXRlZCB1c2VyIGFzc2VydGlvbiB0b2tlbi4NCg0KQWdhaW4sIGRpc2FncmVlLCBm b3IgdGhlIHNhbWUgcmVhc29uaW5nIGFzIGFib3ZlLg0KDQpTYW1lIHJlYXNvbmluZy4NCg0KDQpJ IGFncmVlIHdpdGggSnVzdGluIGhlcmUuICBUaGUgZGVmYXVsdCBzaG91bGQgYmUgdGhhdCBvcGVu IHJlZ2lzdHJhdGlvbnMgYXJlIGVuYWJsZWQuICBUaGUgZXhjZXB0aW9uIGNhc2UgaXMgdGhhdCBz cGVjaWZpYyBwZXJtaXNzaW9ucyBhcmUgcmVxdWlyZWQgdG8gcGVyZm9ybSBkeW5hbWljIGNsaWVu dCByZWdpc3RyYXRpb24uDQoNCltQSF0gSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIGxh c3Qgc2VudGVuY2UuIEl0IHNlZW1zIHRvIGNvbnRyYWRpY3QgeW91ciBwb3NpdGlvbi4gSWYgeW91 IG5lZWQgc3BlY2lmaWMgcGVybWlzc2lvbnMsIHRoZW4gc3VyZWx5IHlvdSBjYW4ndCBiZSBhbm9u eW1vdXM/Pz8NCg0KW21ial0gTW9yZSBjbGVhcmx5IHB1dCwgaXQgc2hvdWxkIGJlIGFuIGV4Y2Vw dGlvbiBmb3IgdGhlIHBhcnR5IHdhbnRpbmcgdG8gcmVnaXN0ZXIgYSBjbGllbnQgdG8gaGF2ZSB0 byBvYnRhaW4gc3BlY2lhbCBwZXJtaXNzaW9ucyB1cCBmcm9udCB0byByZWdpc3RlciB0aGUgY2xp ZW50LiAgSW4gdGhlIG5vcm1hbCBjYXNlLCB0aGUgcGFydHkgd2FudGluZyB0byByZWdpc3RlciBh IGNsaWVudCBzaG91bGQgcmVxdWlyZSBubyBzcGVjaWFsIHVwLWZyb250IHBlcm1pc3Npb25zLg0K DQpBYm91dCBzZWN0aW9uIDQuMzoNCg0KDQpJZiB0aGUgY2xpZW50IGRvZXMgbm90IGV4aXN0IG9u IHRoaXMgc2VydmVyLCB0aGUgc2VydmVyIE1VU1QgcmVzcG9uZA0KDQogICB3aXRoIEhUVFAgNDAx IFVuYXV0aG9yaXplZCwgYW5kIHRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIHVzZWQgdG8N Cg0KICAgbWFrZSB0aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQuDQoN CklmIHRoZSBDbGllbnQgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzZXJ2ZXIsIHNob3VsZG4ndCBp dCByZXR1cm4gYSAiNDA0IE5vdCBGb3VuZCI/DQoNCklmIHJldm9raW5nIHRoZSByZWdpc3RyYXRp b24gYWNjZXNzIHRva2VuLCBpcyBpdCBib3VuZCB0byBhIHNpbmdsZSBjbGllbnQgcmVnaXN0cmF0 aW9uPyAgVGhpcyBpcyBub3QgY2xlYXIuICBXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9y bWF0aW9uIFJlc3BvbnNlIGluIHNlY3Rpb24gNS4xLg0KDQpUaGUgbGFuZ3VhZ2UgYWJvdXQgdGhl IDQwMSBoZXJlIChhbmQgaW4gb3RoZXIgbmVhcmJ5IHNlY3Rpb25zKSBpcyBzcGVjaWZpY2FsbHkg c28gdGhhdCB5b3UgdHJlYXQgYSBtaXNzaW5nIGNsaWVudCBhbmQgYSBiYWQgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbiB0aGUgc2FtZSB3YXkuIFlvdSBzZWUsIHJldHVybmluZyBhIDQwNCBoZXJl IGFjdHVhbGx5IGluZGljYXRlcyB0aGluZ3Mgd2VyZSBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGUu IE5hbWVseSwgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMgc3RpbGwgdmFs aWQgYnV0IHRoZSBjbGllbnQgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiB3YXMg YXR0YWNoZWQgdG8gZG9lc24ndCBleGlzdCBhbnltb3JlLiBUaGUgcmVnaXN0cmF0aW9uIGFjY2Vz cyB0b2tlbiBpbiBtZWFudCB0byBiZSB0aWVkIHRvIGEgY2xpZW50J3MgaW5zdGFuY2UgKG9yIHJl Z2lzdHJhdGlvbiksIHNvIGl0J3MgYWN0dWFsbHkgbW9yZSBzZW5zaWJsZSB0byBhY3QgYXMgdGhv dWdoIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGlzbid0IHZhbGlkIGFueW1vcmUuIElu IGF0IGxlYXN0IHNvbWUgaW1wbGVtZW50YXRpb25zIChzcGVjaWZpY2FsbHkgb3VycyBhdCBNSVRS RSB0aGF0J3MgYnVpbHQgb24gU0VDT0FVVEggaW4gSmF2YSksIHlvdSdkIG5ldmVyIGJlIGFibGUg dG8gcmVhY2ggdGhlIDQwNCBzdGF0ZSBkdWUgdG8gY29uc2lzdGVuY3kgY2hlY2tpbmcgd2l0aCB0 aGUgaW5ib3VuZCB0b2tlbi4NCg0KU2luY2UgdGhlIGludGVudCBvZiB0aGUgcmVnaXN0cmF0aW9u IGFjY2VzcyB0b2tlbiBpcyB0aGF0IGl0J3MgYm91bmQgdG8gYSBzaW5nbGUgaW5zdGFuY2UsIGl0 cyBsaWZlY3ljbGUgaXMgZ2VuZXJhbGx5IHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBiZWdpbnMgYXQg dGhlIGlzc3VhbmNlIG9mIGEgbmV3IGNsaWVudF9pZCB3aXRoIHRoYXQgaW5zdGFuY2UuIFRoYXQg dG9rZW4gbWlnaHQgYmUgcmV2b2tlZCBhbmQgYSBuZXcgb25lIGlzc3VlZCBvbiBSZWFkIGFuZCBV cGRhdGUgcmVxdWVzdHMgdG8gdGhlIENsaWVudCBDb25maWd1cmF0aW9uIEVuZHBvaW50IChhbmQg dGhlIGNsaWVudCBuZWVkcyB0byBiZSBwcmVwYXJlZCBmb3IgdGhhdCAtLSBzYW1lIGFzIHRoZSBj bGllbnRfc2VjcmV0KSwgYW5kIGl0IHdpbGwgYmUgcmV2b2tlZCB3aGVuIHRoZSBjbGllbnQgaXMg ZGVsZXRlZCBlaXRoZXIgd2l0aCBhIERlbGV0ZSBjYWxsIHRvIHRoZSBDbGllbnQgQ29uZmlndXJh dGlvbiBFbmRwb2ludCBvciBzb21ldGhpbmcgaGFwcGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwg dGhlIGNsaWVudC4NCg0KU2hvdWxkIHdlIGFkZCBtb3JlIGV4cGxhbmF0b3J5IHRleHQgdG8gdGhl IGRlZmluaXRpb24gaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24/IEVsc2V3aGVyZT8gSSdtIHZl cnkgb3BlbiB0byBjb25jcmV0ZSBzdWdnZXN0aW9ucyB3aXRoIHRoaXMsIHNpbmNlIEkgZG9uJ3Qg dGhpbmsgaXQncyBhcyBjbGVhciBhcyB3ZSdkIGxpa2UuDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGxv b2sgYXQgaXQuDQoNCg0KRm9yIHNlY3VyaXR5IHJlYXNvbnMsIGl04oCZcyBnZW5lcmFsbHkgbm90 IGdvb2QgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiDigJxub3QgZm91bmTigJ0gYW5kIOKAnHVuYXV0 aG9yaXplZOKAnSBlcnJvcnMgaW4gcmVzcG9uc2VzLCBhcyB0aGF0IGNhbiBwcm92aWRlIHRoZSBh dHRhY2tlciBhbiBvcmFjbGUgdG8gcHJvYmUgd2hldGhlciBhIHBhcnRpY3VsYXIgZW50aXR5IGV4 aXN0cyAgSSBkb27igJl0IHRoaW5rIGEgY2hhbmdlIGlzIGNhbGxlZCBmb3IgaGVyZS4NCg0KW1BI XSBJIGFncmVlIGluIHByaW5jaXBsZS4gVGhpcyBpc3N1ZSBpcyBib3VuZCB1cCB0b28gaW4gd2hh dCB0aGUgbGlmZS1jeWNsZSBvZiB0aGUgcmVnaXN0cmF0aW9uIGFuZCB0aGUgYWNjZXNzIHRva2Vu IGFuZCBjbGllbnQgdG9rZW5zLiBXZSBuZWVkIHRvIGRlc2NyaWJlIHRob3NlIGZpcnN0IGJlZm9y ZSB0aGlzIGJlY29tZXMgY2xlYXIuICBGb3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBpcyBzdGls bCBhdXRoZW50aWNhdGVkLCBidXQgaXRzIHJlZ2lzdHJhdGlvbiBpcyBnb25lLCBpdCBzaG91bGQg YmUgbm90IGZvdW5kLiAgQnV0IEkgYWdyZWUgdGhpcyBkb2Vzbid0IG1ha2Ugc2Vuc2UsIGJlY2F1 c2UgdGhlICJpbXBsaWVkIiBhY3Rpb24gd2FzIHRoYXQgdGhlIGRlbGV0aW9uIG9mIGEgcmVnaXN0 cmF0aW9uIGludmFsaWRhdGVzIGFsbCBhc3NvY2lhdGVkIGNyZWRlbnRpYWxzLiAtLS0+IG1lYW5p bmcgdGhlIGNsaWVudCBzaG91bGQgbmV2ZXIgYmUgYWJsZSB0byBhdXRoZW50aWNhdGUgd2l0aCB0 aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IGFueXdheS4NCg0KW21ial0gQnkgdGhlIHdheSwgeW91 IHdyaXRpbmcgdGhhdCDigJx0aGUgY2xpZW50IHNob3VsZCBuZXZlciBiZSBhYmxlIHRvIGF1dGhl bnRpY2F0ZSB3aXRoIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgYW55d2F54oCdIG1ha2VzIHRo ZSBjYXNlIGZvciB3aHkgdGhlIHBlcm1pc3Npb25zIG9uIHRoZSBjbGllbnTigJlzIHJlZ2lzdHJh dGlvbiBlbmRwb2ludCBhcmUgZGlmZmVyZW50IHRoYW4gdGhvc2UgZ3JhbnRlZCB0byB0aGUgY2xp ZW50IOKAkyBoZW5jZSB0aGUgbmVlZCBmb3IgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4u DQoNCkFib3V0IHNlY3Rpb24gNS4xOg0KSXMgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiB1bmlx dWU/ICBPciBpcyBpdCBzaGFyZWQgYnkgbXVsdGlwbGUgaW5zdGFuY2VzPyAgIElmIHNoYXJlZCwg dGhlbiByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIGNhbid0IGJlIHJldm9rZWQgb24gZGVsZXRl IG9mIGNsaWVudC4NCg0KVGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMgdW5pcXVlIHRv IGEgcmVnaXN0ZXJlZCBjbGllbnQsIGluIHRoZSBSRkMgNjc0OSBzZW5zZSBvZiDigJxjbGllbnTi gJ0uICBBZ2FpbiwgaWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIOKAnGNsaWVudCBpbnN0YW5jZXPi gJ0sIHdlIG5lZWQgdG8gcmVjaGFydGVyIGFuZCB0YWtlIHRoaXMgZGlzdGluY3Qgd29yayBpdGVt IHVwIGV4cGxpY2l0bHkuDQoNCltQSF0gRGlzYWdyZWUuIEkgdGhpbmsgaXQgaXMgd2VsbCB3aXRo aW4gY2hhcnRlciBhbmQgaW4gZmFjdCBhIGZvdW5kYXRpb25hbCByZXF1aXJlbWVudC4NCg0KW21i al0gSSBpbnRlcnByZXQgeW91ciBjb21tZW50IGFib3ZlIGFzIHBhcnQgb2YgeW91ciBkZXNpcmUg Zm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGRlZmluZSBPQXV0aCBDbGllbnQgSW5zdGFuY2UgTWFu YWdlbWVudCBmdW5jdGlvbmFsaXR5LiAgQWdhaW4sIHRoYXTigJlzIGJpZ2dlciB0aGFuIGp1c3Qg cmVnaXN0cmF0aW9uLg0KDQpTdWdnZXN0IHJlbmFtZSDigJxleHBpcmVzX2F04oCdIHRvIOKAnGNs aWVudF9zZWNyZXRfZXhwaXJlc19hdOKAnSwNCg0KU3VnZ2VzdCB0byByZW5hbWUg4oCcaXNzdWVk X2F04oCdIHRvIOKAnGlkX2lzc3VlZF9hdOKAnQ0KDQpXaGlsZSBJIGRvIGxpa2UgdGhlIHN1Z2dl c3Rpb24gb2YgY2hhbmdpbmcgdGhlc2UgdG8gY2xpZW50X3NlY3JldF9leHBpcmVzX2F0IGFuZCBj bGllbnRfaWRfaXNzdWVkX2F0LCBhbmQgSSB0aGluayB0aGVzZSBhcmUgbW9yZSBjbGVhciBhbmQg cmVhZGFibGUsDQoNCg0KDQpJIGRvbid0IHdhbnQgdG8gY2hhbmdlIHRoZSBzeW50YXggZHVyaW5n IGxhc3QgY2FsbCB1bmxlc3MgdGhlcmUgaXMgYSBjbGVhciBuZWVkIGFuZCBhIGNsZWFyIGNvbnNl bnN1cyBmb3IgZG9pbmcgc28uDQoNClRoYXQncyB3aHkgd2UgYXJlIGhhdmluZyBsYXN0IGNhbGwu IFRvIGNvbmZpcm0gY29uc2Vuc3VzIG9uIHRoZSBkcmFmdC4NCg0KU2FtZSByZWFzb25pbmcgYXMg ZWFybGllci4gWW91IG5vdyBoYXZlIG11bHRpcGxlIHRva2VucyAocmVnaXN0cmF0aW9uIGFjY2Vz cyBhbmQgY2xpZW50KSBpbiBwbGF5LiBUaGUgc3BlYyBuZWVkcyB0byBiZSBjbGVhciB3aGljaCBv bmUgaXQgaXMgdGFsa2luZyBhYm91dC4NCg0KSSdtIGZpbmUgd2l0aCB0aGUgc3VnZ2VzdGVkIGNo YW5nZSBidXQgSSB3b3VsZCBsaWtlIG1vcmUgZmVlZGJhY2sgZnJvbSBvdGhlciBwZW9wbGUgYmVm b3JlIG1vdmluZyBmb3J3YXJkIHdpdGggaXQuIFRoZXJlJ3MgYSBsb3Qgb2YgdmFsdWUgaW4gImp1 c3QgcGljayBhIG5hbWUgYW5kIHNoaXAgaXQiIGFzIHdlbGwgdGhvdWdoLCBhbmQgSSBkb24ndCB3 YW50IHRvIGRldm9sdmUgaW50byBiaWtlIHNoZWRkaW5nLiAoSSdtIG5vdCBhY2N1c2luZyB5b3Ug b2YgYmlrZSBzaGVkZGluZyBxdWl0ZSB5ZXQsIGJ0dywganVzdCBhZnJhaWQgb2YgZ2V0dGluZyBp bnRvIGEgbG9uZyBkZWJhdGUgb24gbmFtZXMuKQ0KDQpBZ2FpbiwgdGhpcyB3YXMgYSBwcm9ibGVt IHJhaXNlZCBieSBwZW9wbGUgbmV3IHRvIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGV5IGZvdW5kIGl0 IGNvbmZ1c2luZy4gSSB0ZW5kIHRvIGFncmVlLiBXZSdyZSBub3QgdGFsa2luZyBhYm91dCB3aGF0 IGNvbG91ciB0byBwYWludCB0aGUgc2hlZC4gV2UncmUgdGFsa2luZyBhYm91dCB3aGV0aGVyIHRo ZSBiaWtlIHNoZWQgaXMgYSBob3VzZS4gIDotKQ0KDQpJJ20gbm90IHRvbyBmdXNzZWQgYWJvdXQg d2hldGhlciB5b3UgY2FsbCBpdCAiY2xfc2VjX2V4cGlyeSIgb3IgImNsaWVudF9zZWNyZXRfZXhw aXJlc19hdCIuDQoNCg0KSWYgdGhlIGRlZmluaXRpb25zIG9mIOKAnGV4cGlyZXNfYXTigJ0gb3Ig 4oCcaXNzdWVkX2F04oCdIGFyZSB1bmNsZWFyLCB3ZSBzaG91bGQgY2xhcmlmeSB0aGVtLiAgSWYg eW91IGJlbGlldmUgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIFBoaWwsIGNhbiB5b3Ugc3VwcGx5IHBy b3Bvc2VkIGFsdGVybmF0aXZlIGRlZmluaXRpb24gdGV4dCB0aGF0IGlzIGNsZWFyZXI/ICBUaGF0 IGJlaW5nIHNhaWQsIEkgYmVsaWV2ZSB0aGF0IGF0IHRoaXMgcG9pbnQgd2Ugc2hvdWxkIHN0aWNr IHdpdGggdGhlIGV4aXN0aW5nIHByb3RvY29sIGVsZW1lbnQgbmFtZXMgdW5sZXNzIG92ZXJ3aGVs bWluZyB3b3JraW5nIGdyb3VwIHNlbnRpbWVudCBlbWVyZ2VzIHRvIGNoYW5nZSB0aGVtLiAgVGhl eSBhcmUgYWxyZWFkeSB3b3JraW5nIGZpbmUgYXMtaXMgaW4gcHJvZHVjdGlvbiBkZXBsb3ltZW50 cy4NCg0KW1BIXSBJJ20ganVzdCByZXBvcnRpbmcgdGhlIGNvbmZ1c2lvbiBwZW9wbGUgaGF2ZSBo YWQgd2l0aCBhbWJpZ3VpdHkuDQoNCg0KU2VjdGlvbiA3DQoNCldoZW4gYSBjbGllbnRfc2VjcmV0 IGV4cGlyZXMgaXMgaXQgdGhlIGludGVudCB0aGF0IGNsaWVudHMgZG8gYW4gdXBkYXRlIG9yIHJl ZnJlc2ggdG8gZ2V0IGEgbmV3IGNsaWVudCBzZWNyZXQ/DQoNClllcywgdGhlIGNsaWVudCBpcyBz dXBwb3NlZCB0byBlaXRoZXIgY2FsbCB0aGUgcmVhZCBvciB1cGRhdGUgbWV0aG9kcyBvbiB0aGUg Y2xpZW50IGNvbmZpZ3VyYXRpb24gZW5kcG9pbnQgdG8gZ2V0IGl0cyBuZXcgc2VjcmV0LiBBcyBk aXNjdXNzZWQgYWJvdmUsIEknbSBub3Qgc3VyZSB0aGF0J3MgYXMgY2xlYXIgYXMgaXQgbmVlZHMg dG8gYmUsIGFuZCBJIHdlbGNvbWUgc3VnZ2VzdGlvbnMgb24gaG93IHRvIGNsYXJpZnkgdGhpcy4N Cg0KRWl0aGVyIGlzIGEgcmVhc29uYWJsZSBiZWhhdmlvciBvbiB0aGUgYmVoYWxmIG9mIGNsaWVu dHMsIGRlcGVuZGluZyB1cG9uIGNvbnRleHQuICBJIHN1cHBvcnQgYWRkaW5nIHRleHQgdG8gY2xh cmlmeSB0aGlzLg0KDQpBZ2FpbiwgdGhhbmtzIGZvciB0aGUgdmVyeSB0aG9yb3VnaCByZWFkIHRo cm91Z2guIEhhdmUgeW91IGltcGxlbWVudGVkIGFueSBvZiB0aGUgc3BlYyB5ZXQsIGVpdGhlciBh cy1pcyBvciB3aXRoIGFueSBvZiB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2VzPw0KDQpZZXMuIE11Y2gg b2YgdGhlIGZlZWRiYWNrIGlzIGNvbWluZyBmcm9tIG91ciBkZXZlbG9wbWVudCBjb21tdW5pdHku DQoNCkFoLCB2ZXJ5IGNvb2wuIERldmVsb3BlciBleHBlcmllbmNlIGlzIHRoZSBtb3N0IHZhbHVh YmxlIGZlZWRiYWNrLCBpbiBteSBvcGluaW9uLiBJZiB5b3UgY2FuJ3QgYWN0dWFsbHkgYnVpbGQg dGhlIGJsYXN0ZWQgdGhpbmcsIHdoYXQgZ29vZCBpcyBpdD8gOikNCg0KR2xhZCB0byBoZWFyIHRo YXQgeW914oCZcmUgd29ya2luZyB3aXRoIGRldmVsb3BlcnMgYnVpbGRpbmcgdGhlIHNwZWMuICBQ bGVhc2UgdGhhbmsgdGhlbSBmb3IgdGhlIGZlZWRiYWNrLg0KDQogLS0gSnVzdGluDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJl c3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpbUEhdIFRoYW5rc3MuDQoNCg== --_000_4E1F6AAD24975D4BA5B168042967394367734D79TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDEx IDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0K c3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVy dGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSByZXBsaWVzIGFyZQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5pbiBncmVlbiBhbmQg bWFya2VkIFttYmpdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4uPG86cD48L286cD48L3NwYW4+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+ IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgTWF5IDE3LCAyMDEzIDI6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9u ZXM8YnI+DQo8Yj5DYzo8L2I+IFJpY2hlciwgSnVzdGluIFAuOyBvYXV0aEBpZXRmLm9yZyBXRzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBMYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzdGFydGVkIGEgc2VwYXJhdGUgdGhyZWFkIG9uIGhhdmlu ZyBkeW4gcmVnIGNvcnJlbGF0ZSBjbGllbnQgc29mdHdhcmUuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBvdGhlciBjb21tZW50cyBhcmUgZW1iZWRkZWQg bWFya2VkIHdpdGggW1BIXS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDIwMTMtMDUtMTcsIGF0IDE6MDggUE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZmVlZGJhY2ss IFBoaWwuJm5ic3A7IFNvcnJ5IGZvciB0aGUgZGVsYXllZCByZXNwb25zZSDigJMgSSB3YXMgcHJl dHR5IGZ1bGx5IGVuZ2FnZWQgYXQgdGhlIEV1cm9wZWFuIElkZW50aXR5IENvbmZlcmVuY2UgKHdo ZXJlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTEwMjYiPk9BdXRoDQogMi4wIHdvbiB0aGUg YXdhcmQgZm9yIGJlc3QgbmV3IHN0YW5kYXJkPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPikuJm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+TXkNCiBmZWVkYmFjayBvbiB0aGUgcG9pbnRzIHJh aXNlZCBpcyBpbmxpbmUgaW4gZ3JlZW7igKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPihQZXJoYXBzIGlmIGFueSBvZiB5b3UgcmVwbHkgdG8gdGhpcyB0aHJlYWQsIHlv dSBjb3VsZCBhbHNvIGNob29zZSBhIGRpc3RpbmN0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6cmVkIj5jb2xvcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmZvcg0KIHlvdXIgaW5saW5lIHJlcGxpZXMsIHNvIHRoYXQgaXQgd2lsbCBiZSBlYXNpbHkgZXZp ZGVudCB3aG8gc2FpZCB3aGF0LiZuYnNwOyBBcyBpdCBpcywganVzdCB0aGUgYmFjay1hbmQtZm9y dGggYmV0d2VlbiBQaGlsIGFuZCBKdXN0aW4gaXMgYWxyZWFkeSB2ZXJ5IGRpZmZpY3VsdCB0byBm b2xsb3cuJm5ic3A7IFRoYW5rcy4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjpp bml0aWFsIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPls8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBNYXkgMTYsIDIw MTMgMTI6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJpY2hlciwgSnVzdGluIFAuPGJyPg0KPGI+Q2M6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XRzxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW09BVVRILVdH XSBMYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SnVzdGluLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBNb3Jl IGNvbW1lbnRzIGJlbG93Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlRXLiBJJ20gaGFwcHkgdG8g Y29udHJpYnV0ZSB0ZXh0LiBKdXN0IHdhbnQgdG8gZ2V0IHRvIHNvbWUgcm91Z2ggYWdyZWVtZW50 IGZpcnN0LiAmbmJzcDtGb3IgZXhhbXBsZSwgSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgYSBhd2F5 IHRvIHJlY29nbml6ZSB0d28gcGllY2VzIG9mIHNvZnR3YXJlIGFzIGJlaW5nIHRoZSBzYW1lIChl dmVuIGlmIHNlbGYtYXNzZXJ0ZWQpLiAmbmJzcDtPbmNlIGRlZmluZWQsIEkgY2FuIHB1dCB0b2dl dGhlcg0KIHNvbWUgaW50cm8gdGV4dCwgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVu dGlkLmNvbS8iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAyMDEzLTA1LTE2LCBhdCA1OjE2IEFNLCBSaWNoZXIsIEp1c3RpbiBQLiB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSAxNSwgMjAxMywgYXQgMTA6MzAgUE0sIFBoaWwg SHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxMy0wNS0xNSwgYXQgNTo1 MyBQTSwgUmljaGVyLCBKdXN0aW4gUC4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbCwgbWFueSB0aGFua3MgZm9y IHRoZSBleHRyZW1lbHkgdGhvcm91Z2ggcmV2aWV3ISBJdCBpcyB2ZXJ5IHVzZWZ1bCBpbmRlZWQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbW1lbnRzIGFuZCByZXNwb25zZXMgdG8gZWFjaCBwb2lu dCBhcmUgaW5saW5lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSAxNSwgMjAxMywgYXQgNDozMCBQ TSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBz ZWVtcyB1bmZvcnR1bmF0ZSB0aGF0IEkgaGF2ZSBub3QgZ290dGVuIGEgY2hhbmNlIHRvIGdldCBp bnRvIHRoaXMgbGV2ZWwgb2YgZGV0YWlsIG11Y2ggZWFybGllci4gQnV0IHRoZW4sIEkgZ3Vlc3Mg dGhhdCdzIHdoYXQgTEMgcmV2aWV3IGlzIGZvciEgTXkgYXBvbG9naWVzIGZvciBub3QgZ2V0dGlu ZyBtYW55IG9mIHRoZXNlIGNvbmNlcm5zIHRvIHRoZSBXRyBtdWNoIGVhcmxpZXIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5PdmVyYWxsICZuYnNwOzwvaT48L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGlzIGEgY3JpdGlj YWwgcGFydCBvZiB0aGUgT0F1dGggZnJhbWV3b3JrIG5vdyB0aGF0IHdlIGFyZSBzdGFydGluZyB0 byBjb25zaWRlciBob3cgaW5kaXZpZHVhbCBjbGllbnQgYXBwbGljYXRpb25zIHNob3VsZCBvcGVy YXRlIHdoZW4gdGhlcmUgaXMgb25lIG9yIG1vcmUgZGVwbG95bWVudHMgb2YgYSBwYXJ0aWN1bGFy IHJlc291cmNlIEFQSS4gV2UndmUgbW92ZWQNCiBmcm9tIHRoZSBzaW1wbGUgdXNlIGNhc2Ugb2Yg YSBzaW5nbGUgQVBJIHByb3ZpZGVyIGxpa2UgRmFjZWJvb2sgb3IgRmxpY2tyIGFuZCBtb3ZlZCBv biB0byBzdGFuZGFyZHMgYmFzZWQsIG9wZW4gc291cmNlIGJhc2VkLCBhbmQgY29tbWVyY2lhbCBi YXNlZCBkZXBsb3ltZW50cyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgc2VydmljZSBlbmRwb2lu dHMgYW5kIG1hbnkgY2xpZW50cyB0byBtYW5hZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGR5 bmFtaWMgcmVnaXN0cmF0aW9uIHNwZWMgaXMgYWN0dWFsbHkgZGVhbGluZyB3aXRoIGEgY291cGxl IG9mIGlzc3VlcyB0aGF0IEkgd291bGQgbGlrZSB0byBzZWUgbWFkZSBtb3JlIGNsZWFyIGluIGVh cmx5IHBhcnQgb2YgdGhlIHNwZWM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gJm5ic3A7SG93IGlz IGEgbmV3IGNsaWVudCBhcHBsaWNhdGlvbiByZWNvZ25pemVkIGZvciB0aGUgZmlyc3QgdGltZSB3 aGVuIGRlcGxveWVkIGFnYWluc3QgYSBwYXJ0aWN1bGFyIFNQIGVuZHBvaW50PyAmbmJzcDtTaG91 bGQgY2xpZW50cyBhY3R1YWxseSBhc3NlcnQgYW4gYXBwbGljYXRpb25faWQgVVVJRCB0aGF0IG5l dmVyIGNoYW5nZXMgYW5kIHBvc3NpYmx5IGEgdmVyc2lvbiBpZCB0aGF0IGRvZXMgY2hhbmdlIHdp dGgNCiB2ZXJzaW9ucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBnZW5lcmFs IGNhc2UsIHdoeSBpcyBhbnkgcmVjb2duaXRpb24gcmVxdWlyZWQ/IElmIHlvdSdyZSBkb2luZyB0 aGluZ3MgYXMgcGFydCBvZiBhIGxhcmdlciBwcm90b2NvbCBlY29zeXN0ZW0sIGxpa2UgQmx1ZSBC dXR0b24mIzQzOyBvciBhIHBhcnRpY3VsYXIgT3BlbklEIENvbm5lY3QgcHJvdmlkZXIsIHRoZW4g eW91IGNhbiBkZWZpbmUgc2VtYW50aWNzIGZvciB0eWluZyB0b2dldGhlciBjbGFzc2VzIG9mDQog Y2xpZW50cyAoc2VlIGJlbG93IGZvciBtb3JlIGRpc2N1c3Npb24gb24gdGhpcyB2ZXJ5IHBvaW50 KS4gQnV0IGluIGdlbmVyYWwsIGEgY2xpZW50IGlzIGp1c3QgZ29pbmcgdG8gc2hvdyB1cCBhcyBh IG5ldyBpbnN0YW5jZSB0byB0aGUgQVMgYW5kIGdldCBpc3N1ZWQgYSBuZXcsIHVuaXF1ZSBjbGll bnRfaWQsIGFuZCB0aGF0J3MgdGhhdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSBoYXZlIHRvIGRlZmluZSBtb3JlIGNsZWFybHkg d2hhdCBhbiAmcXVvdDtpbnN0YW5jZSZxdW90OyBpcy4gRm9yIG1lLCB0aGVyZSBhcmUgYXBwbGlj YXRpb25zIGFuZCB0aGVyZSBhcmUgaW5zdGFuY2VzIG9mIHRoYXQgYXBwbGljYXRpb24uICZuYnNw O0l0IGlzIHVzZWZ1bCB0byB1bmRlcnN0YW5kIHRoYXQgYSBjbGllbnQgYXBwbGljYXRpb24gcmVw cmVzZW50cyBhIHNldCBvZiBjb2RlIHRoYXQgc2hvdWxkIGJlaGF2ZQ0KIGluIGEgY29uc2lzdGVu dCB3YXkuICZuYnNwO0l0IHNlZW1zIHRvIG1lIHRoZSBmaXJzdCB0aW1lIGEgbmV3IGFwcGxpY2F0 aW9uIHNob3dzIHVwIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gdGhlIHN1YnNlcXVlbnQgaW5zdGFu Y2VzIHRoYXQgcmVnaXN0ZXIuIEZvciBleGFtcGxlLCBhZnRlciB0aGUgZmlyc3QgcmVnaXN0cmF0 aW9uLCBzdWJzZXF1ZW50IGluc3RhbmNlcyBkb24ndCBuZWVkIHNwZWNpYWwgcmV2aWV3IG9yIGFw cHJvdmFsIHRvIHRoZSBzYW1lDQogZGVncmVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CdXQgd2l0aG91dCBvdGhlciBtZWNoYW5pc21zIHRvIHRpZSB0aGluZ3MgdG9nZXRo ZXIsIHRoZXJlJ3Mgbm8gd2F5IGZvciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBrbm93IGlm IGFueSBjbGllbnQgaW5zdGFuY2UgaXMgdGllZCB0byBhbnkgb3RoZXIgY2xpZW50IGluc3RhbmNl LiBUaGVyZWZvcmUsIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGFuIEFTLCB0aGUgZmlyc3QgaW5z dGFuY2Ugb2YgYW4gYXBwbGljYXRpb24NCiAoaS5lLiwgcGFydGljdWxhciBjb25maWd1cmF0aW9u IG9mIGEgc2V0IG9mIGNvZGUpIHRvIHJlZ2lzdGVyIGlzIG5vIGRpZmZlcmVudCB0byBzdWJzZXF1 ZW50IGluc3RhbmNlcyBvZiB0aGF0IHNhbWUgYXBwbGljYXRpb24uIEhvdyB3ZXJlIHlvdSBlbnZp c2lvbmluZyBhbiBBUyBrbm93aW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGZpcnN0IGFu ZCBzdWJzZXF1ZW50IGluc3RhbmNlcyBvZiBhbiBhcHBsaWNhdGlvbiwgc3BlY2lmaWNhbGx5Pw0K IElmIHRoZXJlJ3MgYW4gJnF1b3Q7YXBwbGljYXRpb25faWQmcXVvdDsgbGlrZSB5b3UgbWVudGlv biBhYm92ZSwgSSB0aGluayBpdCByYWlzZXMgbW9yZSBxdWVzdGlvbnMgdGhhbiBpdCByZXNvbHZl czogV2hvIGlzc3VlcyB0aGUgYXBwbGljYXRpb25faWQsIHNvbWUgc2VydmVyIG9yIHRoZSBhcHBs aWNhdGlvbiBpdHNlbGY/IElzIGl0IHZhbGlkYXRlZCBhdCBhbGw/IFNob3VsZCBpdCBiZSBjb25z aWRlcmVkIHNlY3JldD8gV2hhdCBoYXBwZW5zIHdoZW4gc29tZW9uZQ0KIHNpbXBseSBzdGVhbHMg YW4gYXBwbGljYXRpb25faWQ/IERvZXMgYW4gQVMgaGF2ZSB0byBkbyBhbnl0aGluZyB0byBjaGVj ayB3aXRoIGFueSBvdGhlciBBUyB0byBzZWUgaWYgdGhlIGFwcGxpY2F0aW9uX2lkIGhhcyBhbHJl YWR5IGJlZW4gdXNlZCBlbHNld2hlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBhZ3JlZSB0 aGF0IGEgZGlzY3Vzc2lvbiBvZiAmcXVvdDtpbnN0YW5jZSB2cy4gYXBwbGljYXRpb24mcXVvdDsg d291bGQgYmUgaGVscGZ1bCBpbiBjbGVhcmluZyB0aGlzIHVwLCBJJ2xsIG1ha2UgYSBub3RlIHRv IGFkZCB0ZXh0IHRvIHRoYXQgZWZmZWN0LiAoV2UgaGFkIHRvIGRvIHNvbWV0aGluZyBzaW1pbGFy IGZvciBCQiYjNDM7KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IGl0IGlzIHNpbXBsZSBlbm91Z2ggdG8gYXQgbGVhc3QgYWRkIGEgc2VsZiBnZW5lcmF0ZWQgVVVJ RCBmb3IgdGhlIGFwcGxpY2F0aW9uIElELiAmbmJzcDtUaG91Z2ggSSB3b3VsZCBhbGxvdyBmb3Ig Y2FzZXMgd2hlcmUgdGhlIGFwcGxpY2F0aW9uIElEIGlzIGFzc2lnbmVkIHdoZW4gdGhlIGNsaWVu dCBkZXZlbG9wZXIgYW5kIHRoZSBBUElzIG93bmVyIGRvIGEgZm9ybWFsIGFzc2lnbm1lbnQgb2Yg YXBwbGljYXRpb24NCiBJRHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYSBzZW5zZSB0aGlzIGlz IGp1c3QgYSBsb3dlciB0ZWNoIHdheSBvZiBkb2luZyBpdCB0aGFuIHdoYXQgeW91IGRlc2NyaWJl ZCBhcyB0aGUgaW5pdGlhbCBjbGllbnQgY3JlZGVudGlhbCBpbiBCbHVlIEJ1dHRvbiYjNDM7IHdo ZXJlIHlvdSBlbmNvZGVkIGV4dHJhIGNsYWltcyBpbnRvIHRoZSBpbml0aWFsIGFwcCBjcmVkZW50 aWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgdGhlIFVVSUQgZG9lcyBpcyBsaW5rIG11bHRp cGxlIGluc3RhbmNlcyBvZiBhIGNsaWVudCBhcHAgdG9nZXRoZXIgYXMgdGhlIHNhbWUgJnF1b3Q7 dGhpbmcmcXVvdDsgdGhhdCBzaG91bGQgaGF2ZSBzaW1pbGFyIGhldXJpc3RpY3MvYmVoYXZpb3Vy cy4gJm5ic3A7VGhpcyBpcyB2ZXJ5IHVzZWZ1bCBpZiB5b3Ugd2FudCB0byBiZSBhYmxlIHRvIHJl dm9rZSBhY2Nlc3MgdG8gYSBzZXQgb2YgY2xpZW50cyBpZGVudGlmaWVkIGJ5IGFwcGxpY2F0aW9u DQogaWQgKG9yIGEgdmVyc2lvbiBvZiB0aGF0IGFwcCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPldoaWxlIEnigJltIHN5bXBhdGhldGljIHRvIHRoZSBPQXV0aCB3b3JraW5nIGdy b3VwIGV2ZW50dWFsbHkgZG9pbmcgd29yayBvbiBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBpbnN0 YW5jZXMgb2YgYW4gT0F1dGggY2xpZW50LCBJ4oCZbGwgbm90ZSB0aGF0IGluIFJGQyA2NzQ5IG9y DQogUkZDIDY3NTAgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIGNsaWVudCBpbnN0YW5jZS4m bmJzcDsgVGhlcmUgYXJlIG9ubHkgY2xpZW50cywgd2hpY2ggYXJlIGlkZW50aWZpZWQgYnkgY2xp ZW50X2lkIHZhbHVlcy4mbmJzcDsgSWYgd2Ugd2FudCB0byBkbyB3b3JrIG9uIGNsaWVudCBpbnN0 YW5jZXMsIHdlIHNob3VsZCByZWNoYXJ0ZXIgdG8gYWRkIHRoaXMgbmV3IHdvcmsgYXMgYSB3b3Jr aW5nIGdyb3VwIGRlbGl2ZXJhYmxlLiZuYnNwOyBXZSBzaG91bGQgbm90IHRyeQ0KIHRvIHNob2Vo b3JuIGJpdHMgYW5kIHBpZWNlcyBvZiBpdCBpbnRvIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBz cGVjLCBhbnkgbW9yZSB0aGFuIHdlIHNob3VsZCBoYXZlIHRyaWVkIHRvIHNob2Vob3JuIGl0IGlu dG8gUkZDIDY3NDkgb3IgUkZDIDY3NTAuJm5ic3A7IE9hdXRoLWR5bi1yZWcgaXMgdGhlcmUgdG8g cmVnaXN0ZXIgY2xpZW50cyBhcyBkZWZpbmVkIGluIFJGQyA2NzQ5LiZuYnNwOyBJdOKAmXMgbm90 IHRoZSByaWdodCBwbGFjZSB0byBleHRlbmQgd2hhdA0KIGFuIE9BdXRoIGNsaWVudCBpcyBpbiBu ZXcgd2F5cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltQSF0gU2VlIG5l dyB0aHJlYWQgSSBoYXZlIGJlZ3VuLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuICZuYnNwO0hvdyBhcmUgY2xpZW50IGNy ZWRlbnRpYWxzIG1hbmFnZWQuIEFyZSB3ZSBhc3N1bWluZyBjbGllbnQgY3JlZGVudGlhbHMgaGF2 ZSBhIGxpbWl0ZWQgbGlmZXRpbWUgb3Igcm90YXRpb24gcG9saWN5PzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgaW50ZW50IHdhcyB0aGF0IGNsaWVudF9zZWNyZXQgY291bGQgYmUgcm90YXRlZCwg YXMgaW5kaWNhdGVkIGJ5IHRoZSBleHBpcmVzX2F0IG1lbWJlciBvZiB0aGUgcmVzcG9uc2UuIElm IGEgY2xpZW50J3Mgc2VjcmV0IGV4cGlyZXMsIGl0IGNhbGxzIHRoZSByZWFkIG9wZXJhdGlvbiBv biB0aGUgQ2xpZW50IENvbmZpZ3VyYXRpb24gRW5kcG9pbnQgKMKnNC4yKSB0byBnZXQgaXRzIG5l dyBjbGllbnRfc2VjcmV0Lg0KIElmIHRoaXMgaXMgdW5jbGVhciBpbiB0aGUgY3VycmVudCB0ZXh0 ICh3aGljaCBJIHN1c3BlY3QgaXQgbWF5IGJlIGFmdGVyIG11bHRpcGxlIHJlZmFjdG9yaW5ncyks IHRoZW4gSSB3ZWxjb21lIHN1Z2dlc3Rpb25zIGFuZCBzcGVjaWZpYyB0ZXh0IGFzIHRvIGhvdyB0 byBtYWtlIHRoYXQgY2xlYXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Tb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCB0aGlzIGJlIHVwIGluIHRo ZSBpbnRyb2R1Y3RvcnkgdGV4dCwgc29tZXdoZXJlIGVsc2UsIG9yIGhhdmUgaXRzIG93biBzZWN0 aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIHN0YXJ0aW5nIHRvIHRoaW5rIGNyZWRlbnRpYWwgbWFuYWdlbWVudCBpcyBhIGtl eSBwYXJ0IG9mIHRoZSBkcmFmdC4gSXQgbWF5IGJlIHdvcnRoIGludHJvZHVjaW5nIGEgc3BlY2lm aWMgc2VjdGlvbiBvdXRsaW5nIHRoZSByZWdpc3RyYXRpb24gbGlmZS1jeWNsZSwgcmVnaXN0cmF0 aW9uIGFjY2VzcyB0b2tlbiB1c2FnZSwgYW5kIGNsaWVudCB0b2tlbiB1c2FnZSBhbmQgYm9vdHN0 cmFwcGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+SSB0aGluayB0aGF0IGFk ZGluZyBhIGRpc2N1c3Npb24gb24gdGhpcyB3b3VsZCBiZSBmaW5lLCBhcyBpdCBjb3VsZCBoZWxw IGRldmVsb3BlcnMgdW5kZXJzdGFuZCB0aGUgd29ya2Zsb3cgb2YgcmVnaXN0ZXJpbmcsIHVzaW5n LCBhbmQgdXBkYXRpbmcgcmVnaXN0ZXJlZCBjbGllbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRv ZXMgYSBjbGllbnQgYXV0aGVudGljYXRlIHRoZSBmaXJzdCB0aW1lIGFuZCBzdWJzZXF1ZW50IHRp bWVzIHRvIHRoZSByZWdpc3RyYXRpb24gc2VydmljZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgaXMgYSBzZXBhcmF0ZSBxdWVzdGlvbiBhbGwgdG9nZXRoZXIsIGFzIGl0IGRvZXMg bm90IGludm9sdmUgdGhlIGNsaWVudF9zZWNyZXQgb3IgY2xpZW50X2lkIGF0IGFsbC4gUmF0aGVy LCB0aGUgZmlyc3QgdGltZSB0aGUgY2xpZW50IHNob3dzIHVwIHRvIHRoZSByZWdpc3RyYXRpb24g c2VydmljZSwgaXQgbWF5IGVpdGhlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgLSBOb3QgYXV0aGVudGljYXRlIGF0IGFsbCAodGhpcyBpcyB0aGUgdHJ1ZSBwdWJs aWMsIG9wZW4gcmVnaXN0cmF0aW9uLCBhbmQgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCBzZXJ2ZXJz IGRvIHRoaXMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBBdXRo ZW50aWNhdGUgdXNpbmcgYW4gT0F1dGggMi4wIHRva2VuICh3aGljaCBBVE0gbWVhbnMgYSBiZWFy ZXIgdG9rZW4pLiBIb3cgdGhlIGNsaWVudCBnZXRzIHRoYXQgYmVhcmVyIHRva2VuIGFuZCB3aGF0 IHRoZSBiZWFyZXIgdG9rZW4gbWVhbnMgdG8gdGhlIEFTIGJleW9uZCAmcXVvdDt0aGlzIGNsaWVu dCBpcyBhdXRob3JpemVkIHRvIHJlZ2lzdGVyJnF1b3Q7IGlzIG91dCBvZiBzY29wZSBmb3IgdGhl IHNwZWMsIGJ5IGRlc2lnbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWJzZXF1ZW50IHRpbWVzIHRo YXQgdGhlIHNhbWUgcmVnaXN0ZXJlZCBjbGllbnQgKGJ5IHdoaWNoIHdlIG1lYW4gdGhlIHNhbWUg aW5zdGFuY2Ugb2YgYSBjbGllbnQgd2l0aCBhIHBhcnRpY3VsYXIgY2xpZW50X2lkKSBzaG93cyB1 cCBhdCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IChhY3R1YWxseSwgdGhlIENsaWVudCBDb25m aWd1cmF0aW9uIEVuZHBvaW50KSwgaXQgdXNlcyBpdHMgUmVnaXN0cmF0aW9uDQogQWNjZXNzIFRv a2VuIHRoYXQgaXQgd2FzIGlzc3VlZCBvbiBpbml0aWFsIHJlZ2lzdHJhdGlvbi4gVGhpcyBpcyBh biBPQXV0aCAyLjAgQmVhcmVyIHRva2VuIHRoYXQgaXMgdW5pcXVlIHRvIHRoZSBjbGllbnQgaW5z dGFuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZXRo aW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PSywgdGhlIGRlZmluaXRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBh Y2Nlc3MgdG9rZW4gY2FuIGJlIGV4cGFuZGVkLCBidXQgSSB0aGluayB0aGF0IHRoZSByZXN0IG9m IGl0IGlzIGFscmVhZHkgaW4gdGhlcmUgaW4gwqczLiBJJ2Qgd2VsY29tZSBzdWdnZXN0aW9ucyBv biB3aGljaCBiaXRzIG9mIHRoaXMgY291bGQgYmUgbWFkZSBjbGVhcmVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDBCMDUwIj5TZWUgdGhlIGRpc2N1c3Npb24gb24gd2hhdCB0aGUgcmVnaXN0 cmF0aW9uX2FjY2Vzc190b2tlbiBpcyBpbiB0aGUgdGhyZWFkIOKAnENsaWVudCBDcmVkZW50aWFs IEV4cGlyeSBhbmQgbmV3IFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gLSBkcmFmdC1pZXRmLW9h dXRoLWR5bi1yZWctMTDigJ0uJm5ic3A7DQogSSB3aWxsIHdvcmsgd2l0aCBKdXN0aW4gdG8gYXBw bHkgdGhlc2UgY2xhcmlmaWNhdGlvbnMgdG8gdGhlIHNwZWNpZmljYXRpb24uJm5ic3A7IFRoaXMg bWF5IGdvIGludG8gdGhlIHByb3Bvc2VkIGNyZWRlbnRpYWwgbWFuYWdlbWVudCBvdmVydmlldyBz ZWN0aW9uIGRpc2N1c3NlZCBhYm92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuICZuYnNwO0hvdyBp cyB2ZXJzaW9uaW5nIG9mIGNsaWVudHMgbWFuYWdlZD8gU2hvdWxkIGVhY2ggbmV3IHZlcnNpb24g b2YgYSBjbGllbnQgcmVxdWlyZSBhIGNoYW5nZSBpbiBjbGllbnQgcmVnaXN0cmF0aW9uIGluY2x1 ZGluZyBwb3NzaWJseSBjaGFuZ2luZyBjbGllbnRfaWQgYW5kIGF1dGhlbnRpY2F0aW9uIGNyZWRl bnRpYWw/IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBmZWVsaW5nLCBidXQgaXQgaXMgc29tZXRoaW5n DQogdGhhdCBpbXBsZW1lbnRvcnMgc2hvdWxkIGNvbnNpZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB1cCB0byB0aGUgQVMsIHJlYWxseSwgYW5k IEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnkgZ2xvYmFsIHBvbGljeSB3b3VsZCBldmVyIGZseSBoZXJl LiBFc3BlY2lhbGx5IGlmIHlvdSBjb25zaWRlciB0aGF0IHRoZSBlbnRpcmUgbm90aW9uIG9mICZx dW90O3ZlcnNpb24mcXVvdDsgaXMgbW9yZSBmbHVpZCB0aGVzZSBkYXlzIHRoYW4gaXQgZXZlciBo YXMgYmVlbi4gSSB3b3VsZG4ndCBtaW5kIGFkZGluZyBhIGRpc2N1c3Npb24NCiBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgaWYgaXQgbWVyaXRzIG1lbnRpb25pbmcgdGhvdWdoLCBzbyB0 aGF0IHdlIGNhbiBoZWxwIGJvdGggY2xpZW50IGRldmVsb3BlcnMgYW5kIHNlcnZlciBkZXZlbG9w ZXJzIGluc3RpdHV0ZSByZWFzb25hYmx5IGdvb2QgcG9saWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIHRoZSBpc3N1ZSBpcyB0aGF0IHdoZW4gYSBjbGllbnQg dXBncmFkZXMgaXQgbWF5IGhhdmUgYWNjZXNzIHRvIHRoZSBvbGQgY3JlZGVudGlhbHMuIFdoYXQg aXMgdGhlIGludGVudCB0aGVuIG9mIHJlZ2lzdHJhdGlvbi4gJm5ic3A7U2luY2UgeW91IGhhdmUg YW4gdXBkYXRlIGFyZSBjbGllbnRzIGV4cGVjdGVkIHRvIHVwZGF0ZSAvcmUtcmVnaXN0ZXIgb3Ig bm90PyAmbmJzcDtJJ20gbm90IHN1cmUgdGhpcyBpcyBhIHNlY3VyaXR5DQogY29uc2lkZXJhdGlv biBidXQgbW9yZSBwYXJ0IG9mIHRoZSB3aG9sZSBjaGFuZ2UgbWFuYWdlbWVudCBmdW5jdGlvbiBk eW5hbWljIHJlZ2lzdHJhdGlvbiBzdXBwb3J0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgeW91ciB1cGdyYWRlZCB2ZXJzaW9uIG9mIHRoZSBjbGllbnQgc3RpbGwgaGFz IGFjY2VzcyB0byBpdHMgb2xkIGNyZWRlbnRpYWxzLCB3aHkgd291bGRuJ3QgaXQganVzdCB1c2Ug dGhvc2U/IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIGZvciBmb3JjaW5nIGEgcmUtcmVnaXN0cmF0aW9u LiBOb3IgZG8gSSBzZWUgYW55IHdheSB0aGF0IGFuIEFTIHdvdWxkIGV2ZW4gYmUgYWJsZSB0byB0 ZWxsIHRoYXQgYSBjbGllbnQNCiBoYWQgYmVlbiB1cGdyYWRlZC4gQW4gdXBncmFkZWQgY2xpZW50 IGFsd2F5cyBoYXMgdGhlICpvcHRpb24qIG9mIHJlLXJlZ2lzdGVyaW5nIGl0c2VsZiBhbmQgZ2V0 dGluZyBhIG5ldyBjbGllbnRfaWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGNvbmNlcm4gaGVyZSBpcyB0aGF0IHJv dGF0aW9uIG9mIGNsaWVudCBjcmVkZW50aWFsIGlzIG5vdCBzb21ldGhpbmcgZGlzY3Vzc2VkIGJl Zm9yZS4gQmVmb3JlIHdlIHB1dCBpdCBpbiB0aGUgc3BlYyB3ZSBzaG91bGQgY29uc2lkZXIgdGhl IHJlYXNvbnMgZm9yIGRvaW5nIGl0IGFuZCB3aGF0IHByb2JsZW1zIGl0IHNvbHZlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgbWF5IGJlIGp1c3QgYSBjYXNlIG9mIGxldHRpbmcg cGVvcGxlIGV4Y2hhbmdlIGNyZWRlbnRpYWxzIGZvciB3aGF0ZXZlciByZWFzb24gdGhleSBmZWVs IGlzIGFwcHJvcHJpYXRlLiAmbmJzcDtUaGUgdmVyc2lvbiB1cGdyYWRlIHRoaW5nIHN1Z2dlc3Rz IHRoYXQgd2hlbiBhIGNsaWVudCBpcyB1cGdyYWRlZCBpdCBzaG91bGQgZ28gdG8gdGhlIHJlZ2lz dHJhdGlvbiBzZXJ2ZXIgdG8gJnF1b3Q7cmUtcmVnaXN0ZXImcXVvdDsuDQogJm5ic3A7RGVwZW5k aW5nIG9uIHRoZSBwb2xpY3kgb2YgdGhlIHNlcnZlciwgaXQgbWF5IChvciBtYXkgbm90KSByZWNl aXZlIGEgbmV3IGNsaWVudF9pZCBhbmQvb3IgbmV3IGNyZWRlbnRpYWwuICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgYmVzdCBiZW5lZml0cyBJIGNhbiB0aGluayBvZiBpcyBp ZiB5b3UgZGlzY292ZXIgYSB2ZXJzaW9uIG9mIGEgY2xpZW50IGhhcyBhIHByb2JsZW0sIGJlaW5n IGFibGUgdG8gc2VsZWN0IGEgZ3JvdXAgb2YgY2xpZW50cyBieSBzb2Z0d2FyZSBhbmQgdmVyc2lv biBpcyBpbXBvcnRhbnQuIFRodXMgaWYgY2xpZW50X2lkIGRvZXNuJ3QgdHJhY2UgdG8gYSBwYXJ0 aWN1bGFyIHNvZnR3YXJlIGFuZCB2ZXJzaW9uLA0KIHRoYXQgbWFrZXMgaXQgaGFyZCB0byBkby4g Jm5ic3A7SSAmbmJzcDt0aGluayB5b3UgdGFsa2VkIGFib3V0IHRoaXMgYXMgYW4gaXNzdWUgZm9y IEJsdWUgQnV0dG9uJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+QWdhaW4s IFJGQyA2NzQ5IGRlZmluZXMgbm8gY2xpZW50IGluc3RhbmNlcyBvciBncm91cHMgb2YgY2xpZW50 cywgdGhlcmVmb3JlIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBpbmFwcHJvcHJpYXRlIHRvIGRvIHNv IGhlcmUuJm5ic3A7IFdlIGRvbuKAmXQgbmVlZCB0byBib2lsIHRoZSBvY2Vhbi4mbmJzcDsNCiBJ ZiBhIG5ldyBjaGFydGVyIGl0ZW0gaXMgYXBwcm92ZWQgdG8gZG8gd29yayBvbiBjbGllbnQgaW5z dGFuY2VzIGFuZCBwcm90b2NvbCBlbGVtZW50cyB0byB1c2UgYW5kIGV4cHJlc3MgdGhlbSwgdGhh dOKAmXMgdGhlIHRpbWUgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyIHRoYXQgcG9z c2liaWxpdHkg4oCTIG5vdCBhcyBwYXJ0IG9mIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltQSF0gV2UgZGlzYWdyZWUgc3Ry b25nbHkgaGVyZS4gJm5ic3A7SSB0aGluayBpdCBpcyB3ZWxsIHdpdGhpbiBjaGFydGVyIGFuZCBp biBmYWN0IGlmIHN1Y2ggYSBuZXcgY2hhcnRlciBpdGVtIHdlcmUgZGV2ZWxvcGVkIHdlIHdvdWxk IGJlIHF1aWNrbHkgbW92aW5nIHRvIHJlcGxhY2UgZHluIHJlZyB2ZXJzaW9uIDIuPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+W21ial0gUGVyIG15IGNvbW1lbnRzIG9uIHRoZSBuZXcgdGhyZWFkIHlvdSBz dGFydGVkLCB3ZSB3b3VsZG7igJl0IGJlIHJlcGxhY2luZyB0aGUgZXhpc3RpbmcgZHluYW1pYyBy ZWdpc3RyYXRpb24gc3BlYyDigJMgd2XigJlkIGJlIGNyZWF0aW5nIGEgbmV3IE9BdXRoIENsaWVu dCBJbnN0YW5jZQ0KIE1hbmFnZW1lbnQgc3BlYywgb25jZSBwaWVjZSBvZiB3aGljaCB3b3VsZCBi ZSBkZWZpbmluZyB0aGUgNSUgZXh0ZW5zaW9ucyBuZWVkZWQgdG8gdXNlIGl0IGZvciB0aGF0IHVz ZSBjYXNlLiZuYnNwOyAoQW5kIGFsc28gcGVyIG15IGNvbW1lbnRzIG9uIHRoYXQgdGhyZWFkLCBJ 4oCZbSBzdXJlIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBiaXRzIHdvdWxkbuKAmXQgYmUgYWxsIHRo YXQgd291bGQgYmUgaW4gdGhhdCBzcGVjIOKAkyB0aGV54oCZZCBwcm9iYWJseSBvbmx5IGJlDQog YSBzbWFsbCBwYXJ0IG9mIGl0Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+NC4gJm5ic3A7V2hhdCBpcyB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbj8g V2h5IGlzIGlzIHVzZWQ/IFdoYXQgaXMgaXRzIGxpZmUtY3ljbGU/ICZuYnNwO1doZW4gaXMgaXQg aXNzdWVkLCB3aGVuIGlzIGl0IGNoYW5nZWQ/IFdoZW4gaXMgaXQgZGVsZXRlZD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlZSB0aGUgcmVzcG9uc2UgYWJvdmUgYWJvdmUgYW5kIHRoZSBk ZWZpbml0aW9uIGluIMKnMS4yOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbjogQW4gT0F1dGggMi4wIEJlYXJlciBUb2tlbiBpc3N1 ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRocm91Z2ggdGhlIENsaWVudCBSZWdpc3Ry YXRpb24gRW5kcG9pbnQgd2hpY2ggaXMgdXNlZCBieSB0aGUgQ2xpZW50IHRvIGF1dGhlbnRpY2F0 ZSBpdHNlbGYgZHVyaW5nIHJlYWQsIHVwZGF0ZSwgYW5kIGRlbGV0ZSBvcGVyYXRpb25zLiBUaGlz IHRva2VuIGlzDQogYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBDbGllbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgdGhpcyBjYW4gYmUgY2xhcmlmaWVkLCBJIHdlbGNvbWUgdGV4dCBzdWdnZXN0aW9ucy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsYXR0 ZXIgcGFydCBvZiAxLjIgZGlkbid0IHNlZW0gbGlrZSB0ZXJtaW5vbG9neSBidXQgcmF0aGVyIGFy Y2hpdGVjdHVyZSBvciBwYXJ0IG9mIHRoZSBpbnRyb2R1Y3Rpb24gdGhhdCBkZXNjcmliZXMgd2hh dCB0aGUgc3BlYyBkb2VzLiBUaGUgdGhpcmQgcG9pbnQgZG9lc24ndCBzZWVtIHRvIGZpdCB3aXRo IHRoZSBvdGhlciB0d28gZXhjZXB0IHRvIHNheSB0aGF0IHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlv bg0KIGVuZHBvaW50cyB1c2UgdGhlaXIgb3duIGFjY2VzcyB0b2tlbnMgY2FsbGVkIHJlZ2lzdHJh dGlvbiBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cztvcnBoYW5zOiAyO3RleHQt YWxpZ246LXdlYmtpdC1hdXRvO3dpZG93czogMjstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DbGllbnQgUmVnaXN0cmF0aW9uIEVuZHBvaW50OiBU aGUgT0F1dGggMi4wIEVuZHBvaW50IHRocm91Z2ggd2hpY2g8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGEgQ2xpZW50IGNhbiByZXF1ZXN0IG5ldyByZWdpc3RyYXRpb24uJm5ic3A7IFRoZSBt ZWFucyBvZiB0aGUgQ2xpZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYnRhaW5pbmcg dGhlIFVSTCBmb3IgdGhpcyBlbmRwb2ludCBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJz cDsgQ2xpZW50IENvbmZpZ3VyYXRpb24gRW5kcG9pbnQ6IFRoZSBPQXV0aCAyLjAgRW5kcG9pbnQg dGhyb3VnaDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggYSBzcGVjaWZpYyBDbGll bnQgY2FuIG1hbmFnZSBpdHMgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uLDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcHJvdmlkZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIHRo ZSBDbGllbnQuJm5ic3A7IFRoaXMgVVJMIGZvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhpcyBlbmRwb2ludCBpcyBjb21tdW5pY2F0ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9y aXphdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VydmVyIGluIHRoZSBDbGllbnQg SW5mb3JtYXRpb24gUmVzcG9uc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBSZWdpc3RyYXRpb24g QWNjZXNzIFRva2VuOiBBbiBPQXV0aCAyLjAgQmVhcmVyIFRva2VuIGlzc3VlZCBieSB0aGU8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcml6YXRpb24gU2VydmVyIHRocm91Z2ggdGhl IENsaWVudCBSZWdpc3RyYXRpb24gRW5kcG9pbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHdoaWNoIGlzIHVzZWQgYnkgdGhlIENsaWVudCB0byBhdXRoZW50aWNhdGUgaXRzZWxmIGR1cmlu ZyByZWFkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXBkYXRlLCBhbmQgZGVsZXRlIG9w ZXJhdGlvbnMuJm5ic3A7IFRoaXMgdG9rZW4gaXMgYXNzb2NpYXRlZCB3aXRoIGE8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcnRpY3VsYXIgQ2xpZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzZWN0aW9uIGlzIG1lYW50IHRvIGp1c3QgaW50cm9kdWNl IHRoZSBuZXcgdGVybXMgdGhhdCBhcmUgdGhlbiBleHBsYWluZWQgaW4gZ3JlYXRlciBkZXRhaWwg dGhyb3VnaG91dCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuIFllcywgaXQncyBhIGJpdCBhcmNo aXRlY3R1cmUsIGJ1dCBvbmx5IGluIHRoZSBzZW5zZSB0aGF0IHlvdSBuZWVkIHRvIGRlZmluZSB0 aGUgdGVybXMgdGhhdCBtYWtlIHVwIHlvdXINCiBhcmNoaXRlY3R1cmUuIEhvdyB3b3VsZCB5b3Ug c3VnZ2VzdCB0aGF0IGl0IGNoYW5nZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9i YWJseSB0aGlzIGlzIG1vcmUgYSBtYXR0ZXIgb2Ygc3R5bGUuICZuYnNwO0J1dCwgd2hhdCBoYXBw ZW5lZCBmb3IgbWUgaXMgSSBuYXR1cmFsbHkgc2tpcHBlZCB0aGUgdGVybWlub2xvZ3kgc2VjdGlv biwgYXMgSSB3YXNuJ3QgZXhwZWN0aW5nIHByb3RvY29sIGNvbXBvbmVudHMgdG8gYmUgdGhlcmUu ICZuYnNwOyZxdW90O3Rlcm1pbm9sb2d5JnF1b3Q7IGlzIHNvbWV0aGluZyBJIHRoaW5rIHBlb3Bs ZSB0ZW5kIHRvIHVzZSBhcyBhIGRpY3Rpb25hcnkNCiByYXRoZXIgdGhhbiBhcyBwcm90b2NvbCBj b21wb25lbnQgZGVzY3JpcHRpb24uICZuYnNwO01heWJlIHRoZSBjaGFpcnMgY2FuIGFkdmlzZT88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBkaXN0aW5ndWlz aCBiZXR3ZWVuIGZpcnN0IHRpbWUgcmVnaXN0cmF0aW9uIG9mIGEgcGFydGljdWxhciBjbGllbnQg c29mdHdhcmUgcGFja2FnZSwgaXQgaXMgcG9zc2libGUgdGhhdCBzb21ldGhpbmdzIGxpa2UgYXV0 aGVudGljYXRpb24gbWV0aG9kIGNhbiBiZSBuZWdvdGlhdGUgaW4gb3Igb3V0LW9mLWJhbmQgYXQg dGhhdCB0aW1lLiBTdWJzZXF1ZW50IHJlZ2lzdHJhdGlvbnMgc2hvdWxkIG9ubHkgaGF2ZQ0KIHBh cmFtZXRlcnMgZm9yIGl0ZW1zIHRoYXQgY291bGQgY2hhbmdlIHBlciBkZXBsb3ltZW50IChsaWtl IHRvc191cmkpLiAmbmJzcDtJIHRoaW5rIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIGlzIG9u ZSB0aGluZyB0aGF0IHNob3VsZCBub3QgYmUgbmVnb3RpYXRlZCBwZXIgaW5zdGFuY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBzdWJzZXF1ZW50IGlu c3RhbmNlcyByZWdpc3RlciwgSSBoYXZlIHRvIGFzayB0aGUgcXVlc3Rpb24sIGZvciBleGFtcGxl IHdoZW4gd291bGQgdGhpbmdzIGxpa2UgJnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2Qm cXVvdDsgYmUgbmVnb3RpYXRlZCBvciBiZSBkaWZmZXJlbnQgZm9yIHRoZSBzYW1lIGNsaWVudCBz b2Z0d2FyZT8gU2hvdWxkIG5vdCBhbGwgaW5zdGFuY2VzIHVzZSB0aGUgc2FtZSBhdXRoZW50aWNh dGlvbg0KIG1ldGhvZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGNvbmZ1c2VkIGJ5IHRoaXMgLS0gYXMgZmFyIGFz IHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVjIGlzIGNvbmNlcm5lZCwgYWxsIGluc3RhbmNl cyBhcmUgc2VwYXJhdGUgZnJvbSBlYWNoIG90aGVyLiBBbGwgcGFyYW1ldGVycyBjaGFuZ2UgcGVy IGluc3RhbmNlLiBBbmQgaW5zdGFuY2UsIHlvdSBzaG91bGQga2VlcCBpbiBtaW5kLCBpcyBkZWZp bmVkIGFzIGFueSBvbmUgY29weSBvZiB0aGUgY2xpZW50DQogY29kZSBjb25uZWN0aW5nIHRvIGFu eSBuZXcgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoYXQgcGFpcmluZyBjcmVhdGVzIHRoZSBjbGll bnRfaWQsIGFuZCB0aGVyZWZvcmUgdGhlIGluc3RhbmNlLCBhbmQgdGhlcmVmb3JlIHRoZSByZWdp c3RyYXRpb24gYWNjZXNzIHRva2VuLCBhbmQgdGhlcmVmb3JlIHRoZSByZWdpc3RyYXRpb24gaXRz ZWxmIGF0IGEgY29uY2VwdHVhbCBsZXZlbC4gU28gdGhlcmUgaXMgbm8gd2F5IG90aGVyIHRoYW4g cGVyLWluc3RhbmNlDQogZm9yIGEgY2xpZW50IHRvIGFzayBmb3IgYSBwYXJ0aWN1bGFyIHRva2Vu X2VuZHBvaW50X2F1dGhfbWV0aG9kLiBXaGVyZSBlbHNlIHdvdWxkIHRoZSBBUyBmaW5kIG91dCBh Ym91dCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHN0 aWxsIGRpc2FncmVlIG9uIHRoaXMuIEl0IGlzIG15IGFzc2VydGlvbiB0aGF0IGNsaWVudHMgc2hv dWxkIE5FVkVSIGFzayBmb3IgYSBwYXJ0aWN1bGFyIHRva2VuIGF1dGggbWV0aG9kLiBTaW5jZSBp dCBpcyB0aGUgQVMgdGhhdCBpcyBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LCB0aGVuIGl0IGlz IHRoZSBBUydzIHJpZ2h0IHRvIHNldCB0aGUgYXV0aGVudGljYXRpb24gcG9saWN5LiAmbmJzcDtU aGUgcm9sZQ0KIG9mIGR5bmFtaWMgcmVnIGVuZHBvaW50IGlzIHRvIGluZm9ybSB0aGUgY2xpZW50 IHdoYXQgaXQgbXVzdCBkby4gJm5ic3A7TXkgYXNzdW1wdGlvbiBpcyB0aGF0IGR1cmluZyB0aGUg Zmlyc3QgdGltZSBhIHBpZWNlIG9mIHNvZnR3YXJlIGlzIHJlZ2lzdGVyZWQgKHRoZSBmaXJzdCBp bnN0YW5jZSksIHRoZXJlIGNvdWxkIGJlIHNvbWUgT09CIGRpc2N1c3Npb24gYnkgYW4gYWRtaW5p c3RyYXRvciB0byBhcHByb3ZlIHRoZSBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0aW9uDQogdHlwZSBm b3IgdGhlIEFTIGluIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZW4ndCBoZWFy ZCBhIHJlYXNvbiBqdXN0aWZ5aW5nIHRoaXMgcGFyYW1ldGVyIG90aGVyIHRoZW4gJnF1b3Q7aXQg aXMgbmVlZGVkJnF1b3Q7LiAmbmJzcDtXaHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHJvbGUgb2YgdGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHByb3Rv Y29sIGlzIHR3b2ZvbGQ6IGhhbGYgb2YgdGhhdCBpcyB0aGUgc2VydmVyIGluZm9ybWluZyB0aGUg Y2xpZW50IHdoYXQgaXQgbXVzdCBkby4gQnV0IHRoZSBvdGhlciBoYWxmIGlzIHRoZSBjbGllbnQg aW5mb3JtaW5nIHRoZSBzZXJ2ZXIgd2hhdCBpdCAqY2FuKiBkbywgb3Igd2hhdCBpdCAqd2FudHMq IHRvIGRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBhZ2FpbiwgdGhlcmUncyBubyB3 YXkgdG8gZGlzdGluZ3Vpc2ggYSBmaXJzdCBpbnN0YW5jZSBmcm9tIGEgc3Vic2VxdWVudCBpbnN0 YW5jZSB1bmxlc3MgeW91J3JlIGRvaW5nIHNvbWV0aGluZyBpbiBhZGRpdGlvbi4gTm90aGluZyBp cyBzdG9wcGluZyB0aGUgc2FtZSBhcHBsaWNhdGlvbiBmcm9tIHJlZ2lzdGVyaW5nIGEgbmV3IGlu c3RhbmNlIG9mIGl0c2VsZiBmb3IgZXZlcnkgc2luZ2xlIHVzZXIgb3INCiBldmVyeSBzaW5nbGUg dG9rZW4gdGhhdCBpdCB3YW50cyB0byBnZXQgYWNjZXNzIGZvci4gVGhhdCdzIGNvbXBsaWNhdGVk IGFuZCB3YXN0ZWZ1bCBhbmQgbm90IGEgZ3JlYXQgaWRlYSwgc3VyZSwgYnV0ICZuYnNwO3RoZXJl J3Mgbm8gdXNlZnVsIHdheSB0byBwcmV2ZW50IHRoYXQga2luZCBvZiBiZWhhdmlvciBpZiB5b3Ug YWxzbyB3YW50IG9wZW4gcmVnaXN0cmF0aW9uIG9mIGNsaWVudHMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgaG93IHJlY29nbml6aW5n IHN1YnNlcXVlbnQgaW5zdGFuY2VzIGlzIGVhc2lseSBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIEkgbWVudGlvbmVkIGluIHRoZSBvdGhlciB0aHJlYWQsIGlmIGEgZGV2ZWxvcGVyIGNob29z ZXMgdG8gbGltaXQgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgY2xpZW50IGl0IG11c3QgZG8gc28g YnkgbG9va2luZyB0byB0aGUgZGV2ZWxvcGVyIG9yIHN0YW5kYXJkIGJlaGluZCB0aGUgQVBJLiAm bmJzcDtPdGhlcndpc2UgdGhleSBhcmUgdGFraW5nIHRoZSBjaGFuY2UuICZuYnNwO1RoZXJlJ3Mg bm8gd2F5IGEgZGV2ZWxvcGVyDQogY2FuIHF1ZXJ5IGFsbCB0aGUgcG90ZW50aWFsIGRlcGxveWVy cyB0byBhc2sgd2hhdCBhdXRobiB0eXBlcyB3aWxsIHlvdSB1c2UuIEFzIEkgc2FpZCwgdGhlIG5l dCBlZmZlY3QgaW4gdGhlIGFic2VuY2Ugb2YgYW4gQVBJIHN0YW5kYXJkIGRpY3RhdGluZyB3aGF0 IHNob3VsZCBiZSBzdXBwb3J0ZWQsIHRoZSBkZXZlbG9wZXIgd2lsbCBoYXZlIHRvIGltcGxlbWVu dCBhbGwgbWV0aG9kcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBwb2ludCBoZXJlIGlzIHRoYXQg bm9uZSBvZiB0aGlzIGlzIGhlbHBlZCBieSB0aGUgY2xpZW50IGFwcCBzYXlpbmcgd2hhdCBpdCBz dXBwb3J0cy4gQSBkZXZlbG9wZXIgd2hvIHRha2VzIHRoZSByb3V0ZSBvZiBsaW1pdGluZyBpbXBs ZW1lbnRhdGlvbiB0YWtlcyB0aGUgY2hhbmNlIHRoYXQgdGhlIHNlcnZlciB3aWxsIG5vdCBhY2Nl cHQuICZuYnNwO1NvIHdoeSBuZWdvdGlhdGUgd2l0aGluIHJlZ2lzdHJhdGlvbj88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGVyZSdzIG5vIHdheSBvdGhlciB0aGFuIHBl ci1pbnN0YW5jZSBmb3IgdGhlIHNlcnZlciB0byB0ZWxsIHRoZSBjbGllbnQgd2hpY2ggdG9rZW5f ZW5kcG9pbnRfYXV0aF9tZXRob2QgdG8gdXNlLiBBbGwgaW5zdGFuY2VzIHdpbGwgcHJvYmFibHkg YXNrIGZvciB0aGUgc2FtZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCBmcm9tIGFsbCBhdXRo IHNlcnZlcnMgdGhleSB0YWxrIHRvLCByaWdodD8gQW5kDQogZWFjaCBBUyB3aWxsIHRlbGwgZWFj aCBpbnN0YW5jZSB0aGF0IHJlZ2lzdGVycyB3aXRoIGl0IHRvIHVzZSBhIHBhcnRpY3VsYXIgYXV0 aCBtZXRob2QuIFRoZXJlIGlzIG5vIHdheSB0byB0aWUgdG9nZXRoZXIgZGlmZmVyZW50IGluc3Rh bmNlcyBhY3Jvc3MgKG9yIHdpdGhpbikgYXV0aCBzZXJ2ZXJzIHdpdGhvdXQgc3BlY2lmeWluZyBh IHNpZ25pZmljYW50IGFtb3VudCBvZiBvdGhlciBtYWNoaW5lcnkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4N CldoaWNoIGlzIG5vdCB0byBzYXkgdGhhdCBpdCdzIG5vdCB1c2VmdWwgaW4gc29tZSBjaXJjdW1z dGFuY2VzIHRvIHRpZSB0b2dldGhlciBkaWZmZXJlbnQgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIGNv ZGUgYWNyb3NzIChvciB3aXRoaW4pIGF1dGggc2VydmVycy4gVGhpcyBpcyB3aHksIHdpdGggQmx1 ZSBCdXR0b24mIzQzOywgd2Ugc3BlY2lmaWVkIGEgc3BlY2lmaWMgdG9rZW4gZm9ybWF0IGZvciB0 aGUgaW5pdGlhbCBhY2Nlc3MgdG9rZW4gdGhhdCB0aGUgY2xpZW50cw0KIHVzZSB0byBjYWxsIHRo ZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgdGhlIGZpcnN0IHRpbWUsICZuYnNwO2FzIHdlbGwgYXMg YSBkaXNjb3ZlcnkgcHJvdG9jb2wgYWdhaW5zdCBhIGNlbnRyYWxpemVkIHNlcnZlciB0aGF0IGhh bmRsZXMgcHJlLXJlZ2lzdHJhdGlvbi4gQWxsIG9mIHRoaXMgbWFjaGluZXJ5IGlzLCBpbiBteSBv cGluaW9uLCBhIHN0dXBlbmRvdXMgb3ZlcmtpbGwgZm9yIHRoZSBnZW5lcmFsIGNhc2UsIHRob3Vn aCBpZiBzb21lIGZvbGtzIGZpbmQNCiB1c2UgZm9yIGl0IG91dHNpZGUgb2YgQkImIzQzOyB0aGVu IGl0J2QgYmUgYSBnb29kIHRoaW5nIHRvIGFic3RyYWN0IG91dCBhbmQgbWFrZSBpdHMgb3duIHNw ZWMgdGhhdCBleHRlbmRzIHRoZSBEeW4gUmVnIHNwZWMgaW4gYSBmdWxseSBjb21wYXRpYmxlIHdh eS4gRnVydGhlcm1vcmUsIGV2ZW4gaW4gQmx1ZSBCdXR0b24mIzQzOyB3ZSBzcGVjaWZ5IHRoYXQg YWxsIGF1dGggc2VydmVycyBNVVNUIGFsc28gYWNjZXB0IG9wZW4gcmVnaXN0cmF0aW9uLCB3aXRo b3V0DQogYW4gaW5pdGlhbCBhY2Nlc3MgdG9rZW4sIHdoZXJlIHRoZSBjbGllbnQgc2ltcGx5IHNo b3dzIHVwIGFuZCBzYXlzICZxdW90O2hleSwgaGVyZSBhcmUgbXkgcGFyYW1ldGVycy4mcXVvdDsg VGhlIGF1dGggc2VydmVyIGhhcyBubyB3YXkgdG8ga25vdyBpbiB0aGlzIGNhc2UgYW55IGtpbmQg b2Ygb3V0LW9mLWJhbmQgbmVnb3RpYXRpb24gZm9yIGRpZmZlcmVudCB0aGluZ3MuIEluIEJCJiM0 Mzsgd2UgYXJlIHdyaXRpbmcgdmVyeSBzcGVjaWZpYyBwb2xpY3kgZ3VpZGVsaW5lcw0KIGFib3V0 IGhvdyB0byBwcmVzZW50IHRoZSBVWCBhbmQgdGhpbmdzIHRvIHRoZSBlbmQgdXNlciBmb3IgYWxs IG9mIHRoZXNlIGRpZmZlcmVudCBjYXNlcy4gQnV0IGFnYWluLCBhbGwgb2YgdGhpcyBpcyBzcGVj aWZpYyB0byB0aGUgQkImIzQzOyB1c2UgY2FzZSwgYW5kIEkgZG9uJ3Qgc2VlIHZhbHVlIGluIGRy YWdnaW5nIGl0IGluIHRvIHRoZSByZWdpc3RyYXRpb24gc3BlYyBvbiBpdHMgb3duLiBJIGJlbGll dmUgaXQgd291bGQgYmUgZmFyIHRvbyBsaW1pdGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+U2VlIG15IHByZXZpb3VzIGNvbW1lbnRzIG9uIGRp ZmZlcmVudGlhdGluZyBjbGllbnQgaW5zdGFuY2VzIGJlaW5nIG91dCBvZiBzY29wZSB3aXRob3V0 IHJlY2hhcnRlcmluZyB0byBkbyB0aGlzIG5ldyB3b3JrIGFuZCBvbiB3aGF0IHRoZSByZWdpc3Ry YXRpb25fYWNjZXNzX3Rva2VuDQogaXMuJm5ic3A7IEluIHNob3J0LCB0aGUgcmVnaXN0cmF0aW9u X2FjY2Vzc190b2tlbiBpcyBhbiBSRkMgNjc1MCBiZWFyZXIgdG9rZW4gaXNzdWVkIHRvIHRoZSBw YXJ0eSByZWdpc3RlcmluZyB0aGUgY2xpZW50LCBlbmFibGluZyBpdCB0byBzdWJzZXF1ZW50bHkg cmV0cmlldmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIHRv IHBvdGVudGlhbGx5IHVwZGF0ZSB0aGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGZvciB0aGF0 DQogcmVnaXN0ZXJlZCBjbGllbnQuJm5ic3A7IEFnYWluLCBJ4oCZbGwgd29yayB3aXRoIEp1c3Rp biB0byBtYWtlIHN1cmUgdGhhdCB0aGlzIGlzIGFzIGNsZWFyIGFzIHBvc3NpYmxlIGluIHRoZSBz cGVjaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwgdGhlcmUgc2VlbXMgdG8g YmUgYW4gaW5jb25zaXN0ZW50IHN0eWxlIGFwcHJvYWNoIHdpdGgmbmJzcDs8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTAw LnR4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzQ0MDA4ODtiYWNrZ3Jv dW5kOndoaXRlIj5kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWc8L3NwYW4+PC9hPiZu YnNwO3doaWNoDQogdXNlcyBFVGFncy4gU2hvdWxkIHRoaXMgZHJhZnQgZG8gc28gYXMgd2VsbD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Np b24sIG5vdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIE5vYm9keSBoYXMsIHVudGlsIG5vdywgZXZl biBtZW50aW9uZWQgdGhlIHVzZSBvZiBFVGFncyBoZXJlLiBVTUEgKHdoZXJlIHRoZSByZXNvdXJj ZSByZWdpc3RyYXRpb24gZHJhZnQgY29tZXMgZnJvbSkgdXNlcyBFVGFncywgaGVuY2UgdGhlaXIg aW5jbHVzaW9uIHRoZXJlLiBJIHBlcnNvbmFsbHkgZG9uJ3QNCiBzZWUgdGhlaXIgdXRpbGl0eSBo ZXJlLCB0aG91Z2gsIGFuZCBJIHdvdWxkbid0IHdhbnQgdG8gaW5jbHVkZSBhIHdob2xseSBuZXcg bWVjaGFuaXNtIHRoaXMgbGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WWVzLiBUaG9tYXMnIGRyYWZ0IGlzIG5vdCBhIFdHIGRvY3VtZW50LiBCdXQgdGhhdCBkb2Vzbid0 IG1lYW4gaGUgZG9lc24ndCBoYXZlIGEgcG9pbnQuIEl0J3Mgd29ydGggZGlzY3Vzc2luZy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY291bGQgYXJndWUgdGhhdCB0aGUgcG9pbnQgb2Yg YW4gRVRhZyBpcyB0aGF0IGl0IGlzIHVzZWZ1bCBmb3IgY2hhbmdlIGRldGVjdGlvbiB3aGVuIHRo ZXJlIGFyZSBtdWx0aXBsZSB3cml0ZXJzIHRvIGEgcGFydGljdWxhciByZXNvdXJjZS4gJm5ic3A7 SW4gdGhlIGRlc2lnbiBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCwgdGhlcmUgc2hv dWxkIG9ubHkgYmUgb25lIHdyaXRlciAtLSB0aGUgY2xpZW50Lg0KIFRoaXMgaXMgYW4gaW1wb3J0 YW50IG9ic2VydmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0aGF0IGhhbmRsZSB0aGlzIC0tIG5hbWVseSwgdGhlIHJl Z2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gYW5kIHRoZSBjbGllbnRfaWQuIE1hbnkgaW5zdGFuY2Vz IGluY2x1ZGUgdGhlIGNsaWVudF9pZCBpbiBzb21lIGZvcm0gaW4gdGhlIGNsaWVudCBjb25maWd1 cmF0aW9uIGVuZHBvaW50J3MgVVJMIGZvciBzYW5pdHkgY2hlY2tpbmcsIGFzIGRlc2NyaWJlZCBp biDCpzQuMS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBldmVyeW9uZSBh Z3JlZXMsIEknbSBpbiBhZ3JlZW1lbnQuIEJ1dCBpdCB3aWxsIGxpa2VseSBtZWFuIGNoYW5nZXMg Zm9yIHRoZSByZXNvdXJjZSByZWcgZHJhZnQgaWYgYWRvcHRlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwQjA1MCI+RVRhZ3Mgc2VlbSBsaWtlIGFuIHVubmVjZXNzYXJ5IGFkZGl0aW9uIChh bmQgcG90ZW50aWFsIGNvbXBsaWNhdGlvbikgdG8gdGhlIHNwZWNpZmljYXRpb24uJm5ic3A7IEl0 4oCZcyBhbHJlYWR5IHdvcmtpbmcgZmluZSBhcy1pcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPlNwZWNpZmljIGl0ZW1zOjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+JnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QmcXVvdDs8L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgc29tZSBjb25mdXNpb24gYXMgdG8gd2hldGhl ciB0aGlzIGFwcGxpZXMgdG8gc2VydmVyIG9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gJm5ic3A7 U3VnZ2VzdCByZW5hbWluZyBwYXJhbWV0ZXIgdG8gJnF1b3Q7dG9rZW5fZW5kcG9pbnRfY2xpZW50 X2F1dGhfbWV0aG9kJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHRo ZSBmaXJzdCBJJ3ZlIGhlYXJkIG9mIHRoaXMgcGFydGljdWxhciBjb25mdXNpb24uIEknbSBmaW5l IHdpdGggZWl0aGVyIG5hbWUgYnV0IGF0IHRoaXMgc3RhZ2UgSSBkb24ndCB3YW50IHRvIG1ha2Ug c3ludGF4IGNoYW5nZXMgd2l0aG91dCB2ZXJ5LCB2ZXJ5IGNvbXBlbGxpbmcgcmVhc29ucyB0byBk byBzby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVz dGlvbiB3YXMgcmFpc2VkIHRvIG1lIGJ5IHNvbWUgbmV3IGRldmVsb3BlcnMuIEl0IHNlZW1zIG9i dmlvdXMgdG8gdXMgYXMgZXhwZXJpZW5jZWQgT0F1dGggcGVyc29ucywgYnV0IHRvIG5ldyBkZXZl bG9wZXJzIGl0IHNlZW1zIHVuY2xlYXIuICZuYnNwO0Fsc28sIG5vdyB0aGF0IHlvdSBhcmUgaW50 cm9kdWNpbmcgcmVnaXN0cmF0aW9uIGF1dGhlbnRpY2F0aW9uLCB0aGUgd2hvbGUgdGhpbmcgZ2V0 cyB2ZXJ5DQogY29uZnVzaW5nLiBTbyBpdCBpcyB1c2VmdWwgZGlzYW1iaWd1YXRlIGFsbCB0aGUg cGFyYW1ldGVycyB3aGVyZSBwb3NzaWJsZS4gJm5ic3A7VGhhdCBzYWlkLCBJIHdvdWxkbid0IG1p bmQgc2hvcnRlciBuYW1lcyAobWF5YmUgbm90IHF1aXRlIGFzIHNob3J0IGFzIHRoZSBKT1NFIHN0 dWZmIDstKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZhaXIg ZW5vdWdoLCBidXQgYWdhaW4sIEkgb25seSB3YW50IHRvIGRvIHN5bnRheCBjaGFuZ2VzIGlmIHRo ZSByZXN0IG9mIHRoZSBXRyAqcmVhbGx5KiB3YW50cyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwQjA1MCI+SSBhZ3JlZSB3aXRoIEp1c3RpbiBoZXJlLiZuYnNwOyBJ4oCZbSBmaW5lIGNs YXJpZnlpbmcgdGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgcGFyYW1ldGVyIHRvIHJlc29sdmUgdGhl IHBvdGVudGlhbCBhbWJpZ3VpdGllcyB0aGF0IHlvdSBjaXRlLCBQaGlsLiZuYnNwOyBJ4oCZbSBu b3QgT0sgcmV2aXNpbmcNCiB0aGUgc3ludGF4IHdpdGhvdXQgYSBjb21wZWxsaW5nIHJlYXNvbiB0 byBkbyBzby48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5bUEhdIEkgZG9uJ3QgdGhpbmsgd2UncmUgY2hhbmdpbmcgYW55 IHN5bnRheCBoZXJlLiBKdXN0IGNsYXJpZnlpbmcgdGhlIG5hbWUuIFRoaXMgc2VlbXMgaW1wb3J0 YW50IG5vdyB0aGF0IHRoZXJlIGFyZSAzIHR5cGVzIG9mIHRva2VucyBiZWluZyBtYW5hZ2VkIChy ZWdpc3RyYXRpb24sIGNsaWVudCwgYWNjZXNzKS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbXVjaCBwcmVmZXIganVz dCBkdW1waW5nIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIHJhdGhlciB0aGVuIHJlbmFt aW5nIHBhcmFtZXRlcnMgdGhhdCB3b3VsZCBvdGhlcndpc2UgYmUgdW5jbGVhci48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5bbWJqXSBDaGFuZ2luZyBhIG5hbWUgaXMgY2hhbmdp bmcgdGhlIHN5bnRheC4mbmJzcDsgQXMgZm9yIGR1bXBpbmcgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nl c3MgdG9rZW4sIGdpdmVuIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gaXMgdXNl ZCBieSB0aGUgY29kZSBhdXRob3INCiB0byBhY2Nlc3Mgb25lIHJlc291cmNlIGFuZCB0aGUgY2xp ZW50X2lkIGlzIHVzZWQgYnkgdGhlIGNvZGUgdG8gYWNjZXNzIGEgZGlmZmVyZW50IHJlc291cmNl LCBhbmQgdGhhdCB0aGUgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSB0d28ga2luZHMg b2YgYWNjZXNzIGFyZSB2ZXJ5IGRpZmZlcmVudCwgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGEgc2Vj dXJpdHkgYW5kIHVzYWJpbGl0eSBkaXNhc3RlciB0byB0cnkgdG8gYmxlbmQgdGhlbSB0b2dldGhl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiogQ3VycmVudGx5LCB0aGUgQVBJIG9ubHkgc3VwcG9ydHMgYSBzaW5nbGUgdmFsdWUgaW5z dGVhZCBvZiBhbiBhcnJheS4gJm5ic3A7SWYgdGhlIHB1cnBvc2UgaXMgdG8gYWxsb3cgdGhlIGNs aWVudCB0byBrbm93IHdoYXQgYXV0aCBtZXRob2RzIGl0IHN1cHBvcnRzLCB0aGlzIHNob3VsZCBi ZSBhbiBhcnJheSBpbmRpY2F0ZWQgd2hhdCBtZXRob2RzIHRoZSBjbGllbnQgc3VwcG9ydHMgLSBv ciBpdCBzaG91bGQgbm90IGJlDQogdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d291bGQgcmF0aGVyIGxpa2UgdGhpcyB0byBiZSBhbiBhcnJheSwgcGVyc29uYWxseSwgYW5kIGJy b3VnaHQgaXQgdXAgd2l0aCB0aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBhYm91dCBz aXggbW9udGhzIGFnby4gQnV0IHRoZXJlIGl0IHdhcyBkZWNpZGVkIHRoYXQgYSBzaW5nbGUgdmFs dWUgd2FzIHNpbXBsZXIgYW5kIHN1ZmZpY2llbnQgZm9yIHRoZSBwdXJwb3NlLiBUaGUgSUVURiBk cmFmdCBoYXMNCiBpbmhlcml0ZWQgdGhpcyBkZWNpc2lvbi4gSSAqYmVsaWV2ZSogKHRob3VnaCBh bSBub3QgMTAwJSBwb3NpdGl2ZSkgdGhhdCBJIGJyb3VnaHQgdXAgdGhpcyB2ZXJ5IGlzc3VlIGlu IHRoZSBXRyBoZXJlIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhbnkgdHJhY3Rpb24gb24gaXQsIHNvIHNp bmdsZSBpdCByZW1haW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNh biBnZXQgYmVoaW5kIG11bHRpcGxlIHZhbHVlcy4gSW4gdGhpcyBjYXNlLCBpdCBjaGFuZ2VzIHRo ZSBtZWFuaW5nIG9mIHRoZSBwYXJhbWV0ZXIuIEluc3RlYWQgb2YgdGhlIGNsaWVudCBmb3JjaW5n IHRoZSBzZXJ2ZXIgdG8gdXNlIGEgcGFydGljdWxhciBtZXRob2QsIHRoZSBjbGllbnQgaXMgaW5m b3JtaW5nIHRoZSBzZXJ2ZXIgYWJvdXQgd2hhdCBtZXRob2RzIGl0IGNhbiBwZXJmb3JtLiBUaGlz IGFsbG93cw0KIHRoZSBzZXJ2ZXIgdG8gYXNzaWduIHRoZSBhcHByb3ByaWF0ZSBtZXRob2QgYmFz ZWQgb24gaXRzIG93biBwb2xpY3kuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHNvIG5vdGUgdGhhdCB0aGlzIGZpZWxkLCBsaWtlIGFsbCBvdGhl cnMgaW4gwqcyLCByZXByZXNlbnRzIHR3byB0aGluZ3M6IHRoZSBjbGllbnQgdGVsbGluZyB0aGUg c2VydmVyICZxdW90O0kgd2FudCB0byB1c2UgdGhpcyB2YWx1ZSBmb3IgdGhpcyBmaWVsZCZxdW90 OywgYW5kIHRoZSBzZXJ2ZXIgdGVsbGluZyB0aGUgY2xpZW50ICZxdW90O3RoaXMgaXMgdGhlIHZh bHVlIHlvdSBoYXZlIGZvciB0aGlzIGZpZWxkJnF1b3Q7LiBJdCdzIG5vdCBleGFjdGx5DQogYSBu ZWdvdGlhdGlvbiwgbW9yZSBsaWtlIG1ha2luZyBhIHBvbGl0ZSByZXF1ZXN0IHRvIGFuIGFic29s dXRlIGRpY3RhdG9yIHdobyBoYXMgdGhlIGxhc3Qgd29yZCBhbnl3YXkuIEJ1dCBhdCBsZWFzdCB0 aGlzIGRpY3RhdG9yIGlzIG5pY2UgZW5vdWdoIHRvIHRlbGwgeW91IHdoYXQgdGhlaXIgZGVjaXNp b24gd2FzIGluc3RlYWQgb2YganVzdCBkZWNhcGl0YXRpbmcgeW91LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGlzIHRoZSBoZWFydCBvZiBteSBvYmplY3Rpb24uIFRoaXMgZnV6emluZXNzIGlz IGlzIGdvaW5nIHRvIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIGZ1enppbmVzcyB0aGF0IEkgY2FuIHNlZSBoZXJl LiBJdCdzIHBhcmFsbGVsaXNtIGJldHdlZW4gd2hhdCBnb2VzIGluIHRvIHRoZSBlbmRwb2ludCBh bmQgd2hhdCBjb21lcyBvdXQgb2YgaXQuIFRoZSBzZW1hbnRpY3MgZm9yIHRoZSByZXF1ZXN0IGFu ZCB0aGUgcmVzcG9uc2UgYXJlIGRpZmZlcmVudCwgYW5kIGRpZmZlcmVudGlhYmxlIGJ5IHRoZSBm YWN0IHRoYXQgb25lIGlzIGEgcmVxdWVzdA0KIGFuZCB0aGUgb3RoZXIgaXMgYSByZXNwb25zZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZXItb3AgaXNzdWUgSSB3 b3VsZCBsaWtlIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZSBzcGVjIGRvZXMgbm90IGN1cnJlbnRs eSBzcGVjaWZ5IGlmIHBhcnRpY3VsYXIgaW5wdXQgdmFsdWVzIGFyZSBzaW5ndWxhciBvciBtdWx0 aXBsZS4gJm5ic3A7SWYgYW4gaW1wbGVtZW50ZXIgYXNzdW1lcyBzaW5ndWxhciBhbmQgY2xpZW50 cyBhc3N1bWUgbXVsdGlwbGUsIHdlIGhhdmUgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDBCMDUwIj5UaGUgbXVsdGlwbGUvc2luZ2xlIGRpc2N1c3Npb24gYWJvdmUgZ2V0cyB0byB0 aGUgaGVhcnQgb2Ygd2hhdCBJICo8Yj5kbzwvYj4qIGJlbGlldmUgaXMgYSBkZWZpY2llbmN5IGlu IHRoZSBzcGVjaWZpY2F0aW9uLCBhcyBpdOKAmXMgY3VycmVudGx5IHdyaXR0ZW4uJm5ic3A7IFRo ZSBhdXRob3JzLA0KIG15c2VsZiBpbmNsdWRlZCwgaGF2ZSBmYWlsZWQgdG8gbWFrZSBpdCAxMDAl IGNsZWFyIHRoYXQgZGlzY292ZXJ5IG9mIEF1dGhvcml6YXRpb24gU2VydmVyIGZ1bmN0aW9uYWxp dHkgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHNwZWNpZmljYXRpb24uJm5ic3A7IEkgc3Ryb25n bHkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgdG8gYWRkIGEgY2xlYXIgc3RhdGVtZW50IHRvIHRoaXMg ZWZmZWN0IGluIHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIHNwZWNpZmljYXRpb24uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5UaGUgcHVycG9zZSBvZiB0aGUgRHluYW1p YyBDbGllbnQgUmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gaXMgZm9yIHRoZSBjbGllbnQgdG8g cmVnaXN0ZXIgd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRvIGluZm9ybSBpdCBv ZiBwcm9wZXJ0aWVzIG9mIHRoZQ0KIGNsaWVudCB0aGF0IHRoZSBBUyBtYXkgd2FudC9uZWVkIHRv IGJlIGF3YXJlIG9mLiZuYnNwOyBJdCAqPGI+aXMgbm90PC9iPiogdGhlIHB1cnBvc2Ugb2YgdGhp cyBzcGVjaWZpY2F0aW9uIGZvciBpdCB0byBiZSB1c2VkIGJ5IGNsaWVudHMgaW4gYW55IG1hbm5l ciB0byBkaXNjb3ZlciBmZWF0dXJlcyBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuJm5ic3A7 IFRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPltQSF0gQWdyZWVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkN1cnJlbnRseSwgY2xpZW50cyBhcmUg aW5zdHJ1Y3RlZCBieSBSRkMgNjc0OSB0byBkaXNjb3ZlciBpbmZvcm1hdGlvbiBhYm91dCBBdXRo b3JpemF0aW9uIFNlcnZlcnMgdGhleSBpbnRlcmFjdCB3aXRoIGJ5IGNvbnN1bHRpbmcgdGhlIOKA nDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+c2VydmljZQ0KIGRvY3Vt ZW50YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAi PuKAnSAoUkZDIDY3NDksIFNlY3Rpb25zIDMuMSBhbmQgMy4yKS4mbmJzcDsgVGhleSBjYW4gYWxz byBsZWFybiBpbmZvcm1hdGlvbiBhYm91dCBBdXRob3JpemF0aW9uIFNlcnZlcnMgaW4gc3BlY2lm aWMgY29udGV4dHMgdGhyb3VnaCBkaXNjb3ZlcnkgcHJvdG9jb2xzIHN1Y2ggYXMgT3BlbklEDQog Q29ubmVjdCBEaXNjb3ZlcnkgKDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5p ZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAi Pmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRt bDwvc3Bhbj48L2E+KSBhbmQgVU1BIERpc2NvdmVyeSAoVEJEKS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgc3VzcGVjdCB0aGF0IGF0IHNvbWUgcG9pbnQsIHNvbWVv bmUgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm9wb3NlIGRldmVsb3BpbmcgYSBn ZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBtZWNoYW5pc20sIHdoaWNoIHdpbGwgbGVhZCB0byBhIHJl Y2hhcnRlcmluZw0KIHRvIGluY2x1ZGUgdGhpcyB3b3JrIGluIHRoZSB3b3JraW5nIGdyb3Vw4oCZ cyBzZXQgb2YgZGVsaXZlcmFibGVzLiZuYnNwOyBJIHdvdWxkIHN1cHBvcnQgZG9pbmcgdGhpcyB3 b3JrIGFuZCB0aGUgbmVjZXNzYXJ5IHJlY2hhcnRlcmluZyB0byBkbyBzby48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W1BIXSBTbywgZ2l2ZW4gdGhlIGFib3ZlLCB0aGUgY2xpZW50IHNob3Vs ZG4ndCBiZSBkaWN0YXRpbmcgdG9rZW4gdHlwZS4gVGhlIEFTIHNob3VsZCBzaW1wbHkgYXNzaWdu IHRoZSBjcmVkZW50aWFsIGFuZCBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0IG11c3QgdXNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUw Ij5bbWJqXSBZb3Ugc2VlbSB0byBiZSAoaW50ZW50aW9uYWxseT8pIGlnbm9yaW5nIEpvaG4gQnJh ZGxleeKAmXMgcG9pbnQgdGhhdCBpdOKAmXMgdGhlIGNsaWVudCB0aGF0IGtub3dzIHdoaWNoIG9m IHRoZSBzZWN1cml0eSBwcm9maWxlcyBzdXBwb3J0ZWQgYnkgdGhlIEFTIHRoYXQNCiBpdCBuZWVk cyB0byB1c2Ug4oCTIG5vdCB0aGUgQVMuJm5ic3A7IFRoZXJlZm9yZSwgZm9yIHNlY3VyaXR5IHJl YXNvbnMsIGl0IG11c3QgYmUgdGhlIGNsaWVudCB0aGF0IHBpY2tzIHRoZSBtZXRob2QgZnJvbSBh bW9uZyB0aG9zZSBzdXBwb3J0ZWQgYnkgdGhlIEFTIOKAkyBub3QgdGhlIG90aGVyIHdheSBhcm91 bmQuJm5ic3A7IFRoZSBBUyBoYXMgbm8gd2F5IHRvIGtub3cgd2hpY2ggbWV0aG9kcyBhcmUgYXBw cm9wcmlhdGUgZm9yIHdoaWNoIGNsaWVudHMsIGJ1dCB0aGUNCiBjbGllbnRzIGRvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhZ3JlZSwgbm8gZGlzY292ZXJ5LiAm bmJzcDtCdXQgSSBhbHNvIHdhbnQgdG8gZWxpbWluYXRlIG5lZ290aWF0aW9uIHRoYXQgZG9lc24n dCBhY3R1YWxseSBoZWxwIGFueXRoaW5nLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIw NTAiPlttYmpdIEnigJltIG5vdCBkZXNjcmliaW5nIG5lZ290aWF0aW9uIGFib3ZlLiZuYnNwOyBJ 4oCZbSBkZXNjcmliaW5nIHRoZSBwYXJ0eSB3aXRoIHRoZSBrbm93bGVkZ2UgdG8gbWFrZSB0aGUg YXBwcm9wcmlhdGUgY2hvaWNlIGJlaW5nIGFibGUgdG8gbWFrZSB0aGF0IGNob2ljZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+VGhh dCBiZWluZyBzYWlkLCBJIHN0cm9uZ2x5IG9wcG9zZSB0cnlpbmcgdG8gc2hvZWhvcm4gcGllY2Vt ZWFsIGFzcGVjdHMgb2YgZGlzY292ZXJ5IGludG8gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJh dGlvbiBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJdCBpcyBkaXN0aW5jdCBmdW5jdGlvbmFsaXR5DQog YW5kIGRlc2VydmVzIGZpcnN0LWNsYXNzIGFuZCBzZXBhcmFibGUgdHJlYXRtZW50IGJ5IHRoZSB3 b3JraW5nIGdyb3VwLiZuYnNwOyBEaXNjb3ZlcnkgaXMgZm9yIHBvdGVudGlhbCBjbGllbnRzIHRv IGxlYXJuIHByb3BlcnRpZXMgb2YgdGhlIEFTIGJlZm9yZSByZWdpc3RyYXRpb24uJm5ic3A7IFJl Z2lzdHJhdGlvbiBpcyBmb3IgcG90ZW50aWFsIGNsaWVudHMgdG8gaW5mb3JtIHRoZSBBUyBvZiBp dHMgcHJvcGVydGllcywgY3JlYXRpbmcgYSByZWdpc3RlcmVkIGNsaWVudC4mbmJzcDsNCiBEaXNj b3Zlcnkgc2VuZHMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEFTIHRvIHRoZSBDbGllbnQuJm5ic3A7 IFJlZ2lzdHJhdGlvbiBzZW5kcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQ2xpZW50IHRvIHRoZSBB Uy4mbmJzcDsgVGhhdOKAmXMgYSBjbGVhbiBzZXBhcmF0aW9uLiZuYnNwOyBXZSBzaG91bGQgc3Ry b25nbHkgcmVzaXN0IG11ZGR5aW5nIHRoZSB0d28gZnVuY3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+T0F1dGggMi4wIGlzIGEgc3VjY2VzcyBiZWNhdXNlIGl0 IGRpZG7igJl0IHRyeSB0byBib2lsIHRoZSBvY2Vhbi4mbmJzcDsgSXQgc3BlY2lmaWVkIGhvdyB0 byBkbyBvbmUgdGhpbmcgd2VsbCBpbiBhIHNpbXBsZSwgd2ViLWZyaWVuZGx5IG1hbm5lci4mbmJz cDsgV2Ugc2hvdWxkIGRvIHRoZSBzYW1lDQog4oCTIGZvY3VzaW5nIG9uIHNwZWNpZnlpbmcgaW50 ZXJvcGVyYWJsZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24sIHdoaWxlIG1ha2luZyBpdCBj bGVhciB0aGF0IHRoaXMgaXMgZGlzdGluY3QgZnJvbSBkaXNjb3ZlcnkgYWJvdXQgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgcHJvcGVydGllcywgYW5kIG1ha2luZyBpdCBjbGVhciB0aGF0IGRpc2NvdmVy eSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMEIwNTAiPkkgYXBvbG9naXplIGF0IHRoaXMgcG9pbnQgb24gYmVoYWxmIG9mIG15 c2VsZiBhbmQgdGhlIG90aGVyIHNwZWMgZWRpdG9ycyBmb3Igbm90IGJlaW5nIDEwMCUgY2xlYXIg dGhhdCBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSBpcyBleHBsaWNpdGx5IG91dCBvZiBzY29wZSBm b3INCiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24uJm5ic3A7IElmIHdlIGhhZCBkb25lIHNv LCBJ4oCZbSBzdXJlIHRoYXQgbWFueSBvZiB0aGUgY3VycmVudCBxdWVzdGlvbnMgYW5kIGNvbmZ1 c2lvbnMgd291bGQgbm90IGhhdmUgYXJpc2VuLiZuYnNwOyBJIHRoaW5rIHdl4oCZZCBhc3N1bWVk IHRoYXQgdGhpcyB3YXMgb2J2aW91cywgYnV0IGZyb20gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbnMs IGl04oCZcyBhcHBhcmVudCB0aGF0IGl04oCZcyBub3Qgb2J2aW91cy4mbmJzcDsgSSB3aWxsIHBl cnNvbmFsbHkNCiBjb21taXQgdG8gY2xhcmlmeWluZyB0aGUgc3BlY2lmaWNhdGlvbiBhdCB0aGlz IHBvaW50IHRvIGVsaW1pbmF0ZSB0aGlzIHBvdGVudGlhbCBwb2ludCBvZiBjb25mdXNpb24uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5HZXR0aW5nIGJhY2sgdG8gdGhl IHNwZWNpZmljcywgdGhlIG9ubHkgdXNlZnVsIHB1cnBvc2Ugb2YgYSBtdWx0aS12YWx1ZWQg4oCc PC9zcGFuPnRva2VuX2VuZHBvaW50X2NsaWVudF9hdXRoX21ldGhvZDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj7igJ0NCiBtZW1iZXIgd291bGQgYmUgdG8gZW5hYmxl IHRoZSBjbGllbnQgdG8gZGlzY292ZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRoZSBBUyBhZnRlciB0aGUgcmVnaXN0cmF0aW9uIGhh ZCBiZWVuIHBlcmZvcm1lZC4mbmJzcDsgQnV0IHRoYXQgaXMgYSBkaXNjb3ZlcnkgZnVuY3Rpb24s IGFuZCBzbyBzaG91bGQgYmUgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHdvcmsg4oCTIG5vdCB0aGlz IHNwZWNpZmljYXRpb24uJm5ic3A7DQogV2Ugc2hvdWxkIHJlc2lzdCBzaG9laG9ybmluZyBpbiBi aXRzIG9mIGRpc2NvdmVyeSBpbnRvIHRoaXMgc3BlY2lmaWNhdGlvbi4mbmJzcDsgSXQgKjxiPmlz PC9iPiogYSB3b3J0aHdoaWxlIHRvcGljLCBidXQgZGVzZXJ2ZXMgZnVsbCBjb25zaWRlcmF0aW9u IGJ5IHRoZSB3b3JraW5nIGdyb3VwIGluIGl0cyBvd24gcmlnaHQuJm5ic3A7IFRoZXJlZm9yZSwg dGhpcyBtZW1iZXIgbXVzdCByZW1haW4gc2luZ2xlLXZhbHVlZCwgYW5kIGJlIGNsZWFybHkgc3Bl Y2lmaWVkDQogYXMgdGhlIG1ldGhvZCBieSB3aGljaCBhIGNsaWVudCBpbmZvcm1zIHRoZSBBUyB3 aGljaCB0b2tlbiBlbmRwb2ludCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaXQgd2lsbCB1c2UuJm5i c3A7IEFueXRoaW5nIGVsc2Ugd291bGQgYmUgc2NvcGUgY3JlZXAsIGFuZCByZXN1bHQgaW4gYW4g dW5uZWNlc3NhcmlseSBjb21wbGljYXRlZCBzcGVjaWZpY2F0aW9uIGFuZCB1bm5lY2Vzc2FyaWx5 IGNvbXBsaWNhdGVkIGNsaWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1BIXSBB Z3JlZWQuIExldCdzIHJlbW92ZSB0aGUgcGFyYW1ldGVyLmluIHRoZSByZXF1ZXN0LiBJdCBzaG91 bGQgb25seSBiZSBpbiB0aGUgcmVzcG9uc2UuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj4mbmJzcDtbbWJqXSBSZW1v dmluZyB0aGUgcGFyYW1ldGVyIHdvdWxkIG1ha2UgaXQgaW1wb3NzaWJsZSBmb3IgdGhlIGNsaWVu dCwgd2hpY2gga25vd3Mgd2hpY2ggc2VjdXJpdHkgcHJvZmlsZSBpdCBuZWVkcyB0byB1c2UsIHRv IGRlY2xhcmUgdG8gdGhlIEFTIHdoaWNoIG1ldGhvZCwNCiBmcm9tIGFtb25nIHRoZSBtZXRob2Rz IHN1cHBvcnRlZCBieSB0aGUgQVMsIHRoYXQgaXQgbmVlZHMgdG8gdXNlLiZuYnNwOyBUaGUgY2xp ZW50IE1VU1QgYmUgdGhlIG9uZSBkb2luZyB0aGUgY2hvb3NpbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBUaGVyZSBp cyBubyBhdXRobiBtZXRob2QgZm9yICZxdW90O2NsaWVudF9zZWNyZXRfc2FtbCZxdW90OyBvciAm cXVvdDtwcml2YXRlX2tleV9zYW1sJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm9ib2R5IGhhcyByZWFsbHkgYXNrZWQgdGhhdCB0aGVzZSB0d28gYmUgaW5jbHVkZWQgb3Igc3Bl Y2lmaWVkLiBUaGUgZXh0ZW5zaW9uIG1lY2hhbmlzbSAodXNpbmcgYW4gYWJzb2x1dGUgVVJJKSB3 b3VsZCBhbGxvdyBzb21lb25lIGVsc2UgdG8gZGVmaW5lIHRoZXNlLiBJcyB0aGUgZGVmaW5pdGlv biBpbiB0aGUgU0FNTCBBc3NlcnRpb24gZHJhZnQgc3VmZmljaWVudCBmb3IgdGhlaXIgdXNlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgY29taW5n IGZyb20gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIEpXVCBiZWFyZXIgZHJhZnQgYW5kIGEgU0FN TCBiZWFyZXIgZHJhZnQuICZuYnNwO1RoZSB0cnV0aCBpcyB5b3UgYXJlIGRlZmluaW5nIGFuIGF1 dGhlbnRpY2F0aW9uIHRoYXQgaXNuJ3QgZXZlbiBkZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPlRoZXJlIGFyZSBubyBwcm9maWxlcyByZWZlcmVuY2VkIG9y IGRlZmluZWQgZm9yICZxdW90O2NsaWVudF9zZWNyZXRfand0JnF1b3Q7IG9yICZxdW90O3ByaXZh dGVfa2V5X2p3dCZxdW90Oy4gTmVpdGhlciBvZiB0aGUgSldUIG9yIFNBTUwgQmVhcmVyIGRyYWZ0 cyByZWZlcmVuY2VkIGNvdmVyIHRoZXNlIHR5cGVzIG9mIGZsb3dzLiBUaGV5IG9ubHkgY292ZXIg YmVhcmVyIGZsb3dzLiAmbmJzcDsmcXVvdDtjbGllbnRfc2VjcmV0X2p3dCZxdW90OyBhbmQgJnF1 b3Q7cHJpdmF0ZV9rZXlfand0JnF1b3Q7DQogc2VlbSB0byBoYXZlIHNvbWUgbWVhbmluZyB3aXRo aW4gT3BlbklEIENvbm5lY3QsIGJ1dCBJIG5vdGUgdGhhdCBPSURDIGRvZXMgbm90IGZ1bGx5IGRl ZmluZSB0aGVzZSBlaXRoZXIuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEpX VCBhc3NlcnRpb24gZHJhZnQgZG9lcyBzYXkgaG93IHRvIHVzZSBhIEpXVCBmb3IgY2xpZW50IGF1 dGhlbnRpY2F0aW9uLCBhbmQgdGhlIER5blJlZyB0ZXh0IGRpZmZlcmVudGlhdGVzIGJldHdlZW4g YSBjbGllbnQgc2lnbmluZyBzYWlkIEpXVCB3aXRoIGl0cyBvd24gc2VjcmV0IHN5bW1ldHJpY2Fs bHkgdnMuIGEgY2xpZW50IHVzaW5nIGl0cyBvd24gcHJpdmF0ZSBrZXksIGFzeW1tZXRyaWNhbGx5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFsbHkgbXkg aW50ZXJwcmV0YXRpb24gaXMgdGhlIEpXVCBkcmFmdCBhc3N1bWVzIHRoZSBKV1QgQmVhcmVyIGlz IGEgYmVhcmVyIHRva2VuLiAmbmJzcDtUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IGlmIGEgY2xpZW50 IGhhcyB0aGUgYXNzZXJ0aW9uIGl0IGhhcyB0aGUgcmlnaHQgdG8gcHJlc2VudCBpdC4gJm5ic3A7 SU9XLiBUaGUgSldUIEJlYXJlciBEcmFmdCBpcyBtb3N0IGRlZmluaXRpdmVseSBub3QgYSBKV1Qg SG9LIERyYWZ0Lg0KICZuYnNwOzotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGxlc3MsIHlv dSBhcmUgaW50cm9kdWNpbmcgYSBuZXcgcHJvZmlsZSB3aGljaCBpcyB1bmRlZmluZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayBJIHNlZSB0aGUgcG9pbnQgdGhhdCB5b3UncmUgbWFraW5nIG5vdywgbGV0IG1lIHRyeSB0 byByZS1zdGF0ZSBpdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGUgYmFzaWNzIG9mICZx dW90O2hvdyB0byBwcmVzZW50IGEgSldUIGFzIGEgY2xpZW50IGNyZWRlbnRpYWwmcXVvdDsgaXMg ZGVmaW5lZCBoZXJlOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUuaHRtbCNyZmMuc2VjdGlvbi4yLjIiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUuaHRtbCNyZmMu c2VjdGlvbi4yLjI8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPiwNCiBpdCdzIG5vdCBjb21wbGV0ZWx5IHNwZWNpZmllZCBpbiB0aGF0IGl0IGRvZXNu J3QgZnVsbHkgcmVzdHJpY3QgdGhlIHNpZ25hdHVyZSBzZWNyZXQgc291cmNlLCB0aGUgYXVkaWVu Y2UgY2xhaW0sIGFuZCBvdGhlciB0aGluZ3MgdGhhdCB0aGUgQVMgd291bGQgbmVlZCB0byBjaGVj ayBhbmQgdmFsaWRhdGUuIFJpZ2h0PyBUaGUgZHluYW1pYyByZWdpc3RyYXRpb24gZHJhZnQgY2Fu IGRlZmluZSB0aG9zZSBjYXNlcyBpbiBncmVhdGVyIGRldGFpbCBpZg0KIG5lZWRlZCAodGhvdWdo IEkgdGhpbmsgaXQgZG9lcyBzbyBzdWZmaWNpZW50bHkgYXMtaXMsIEkgd2VsY29tZSBtb3JlIGNs YXJpdHkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBPSyB3aXRoIGFkZGluZyB0aGUgU0FN TCBiaXQsIGdvaW5nIGludG8gZ3JlYXRlciBkZXRhaWwgb24gdGhlIEpXVCBiaXRzLCBvciBkcm9w cGluZyB0aGUgSldUIGJpdHMsIGlmIHRoZSBXRyB3YW50cyB0byBkbyBhbnkgb2YgdGhvc2UgYWN0 aW9ucy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgdGhlIEpXVCBzdHVmZiBpcyBhbHJlYWR5IGluIHVz ZSBhbmQgZnVuY3Rpb25pbmcgYW5kIGl0J2QgYmUgYSBzaGFtZQ0KIHRvIGxlYXZlIGl0IG91dC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIHRoZW4gdGhlIG1pc3Rha2UgdGhl IEpXVCBCZWFyZXIgYW5kIFNBTUwgQmVhcmVyIGRyYWZ0cyBhdXRob3JzIG1hZGUgaXMgdGhleSBh c3N1bWVkIGV2ZXJ5b25lIGhhZCB0aGUgc2FtZSBkZWZpbml0aW9uIG9mIGJlYXJlciB0b2tlbi4g Jm5ic3A7VG8gbWUgYSBiZWFyZXIgdG9rZW4gb3BhcXVlIHRvIHRoZSBjbGllbnQuIEl0IHRoZXJl Zm9yZSBjYW5ub3QgZG8gYW55IHNpZ25hdHVyZSB3b3JrIHdpdGggcmVnYXJkcw0KIHRvIHRoZSB0 b2tlbiBpdHNlbGYuICZuYnNwO05vdywgdGhhdCdzIG5vdCB0byBzYXkgYSBwcm9vZiBkaWRuJ3Qg b2NjdXIgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgdG9rZW4gaXNzdWVyLCBidXQgd2hlbiB0 aGUgY2xpZW50IHdpZWxkcyB0aGUgdG9rZW4sIGl0IGlzIGhhbmRsaW5nIGFuIG9wYXF1ZSBzdHJp bmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbmNlcHQgb2YgY2xpZW50X3NlY3JldF9qd3Qg c3VnZ2VzdHMgYW4gSG9LIHByb2ZpbGUuICZuYnNwO1RoZXJlZm9yZSBvZiBjb3Vyc2UgdGhlIGJl YXJlciBkcmFmdHMgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lmaWVkIHdoZW4gaXQgY29tZXMgdG8g SG9LIHByb2ZpbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGZvciBleGFtcGxlLCB5b3UgbmVl ZCBhIGRyYWZ0IGxpa2UgdGhlIE1BQyBkcmFmdCBmb3IgdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20gaGF2aW5nIHRyb3VibGUgb3ZlcmFsbCBoZXJlLiBJdCBzZWVtcyB0aGUgYXV0 aG4gdHlwZXMgc3VnZ2VzdCBPTkxZIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50cywg eWV0IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgdGhlIGN1cnJlbnQgZHJhZnQgaXNu J3QgYWJsZSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHNvZnR3 YXJlIChldmVuIGluIGEgc2VsZi1hc3NlcnRlZA0KIHdheSkuICZuYnNwO0lmIHlvdSBoYXZlbid0 IGF1dGhlbnRpY2F0ZWQgdGhlIHNvZnR3YXJlIGF0IGFsbCwgd2h5IGhhdmUgc3Ryb25nIGNsaWVu dCBhdXRoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBpcyBubyBhdXRoZW50aWNhdGlvbiBtZXRob2QgZGVmaW5lZCBmb3IgJnF1b3Q7Y2xpZW50X2Jl YXJlcl9zYW1sJnF1b3Q7IG9yICZxdW90O2NsaWVudF9iZWFyZXJfand0JnF1b3Q7IG9yICZxdW90 O2NsaWVudF9iZWFyZXJfcmVmJnF1b3Q7LiAmbmJzcDtTaW5jZSB0aGUgYmVhcmVyIHNwZWNzIHNh eSB0aGlzIGlzIGFjY2VwdGFibGUsICZuYnNwO3RoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzcGVj IHNob3VsZCBhY2NlcHQgdGhlc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0 IHVuZGVyc3RhbmQgdGhpcyBiaXQgLS0gd2hlcmUgYXJlIHRoZXNlIGRlZmluZWQgaW4gUkZDNjc1 MD8gSSBkb24ndCBldmVuIGtub3cgd2hhdCBjbGllbnRfYmVhcmVyX3JlZiB3b3VsZCByZWZlciB0 by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Njc1MCBzYXlzIHlvdSBjYW4g dXNlIGEgYmVhcmVyIGFzc2VydGlvbiAoZS5nLiBvYnRhaW5lZCBmcm9tIGFuIElEUCkgYW5kIHdp ZWxkIGl0IGFzIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbi4gJm5ic3A7VGhlIGNsaWVudCBp cyBOT1QgY3JlYXRpbmcgb3IgbW9kaWZ5aW5nIHRoZSBhc3NlcnRpb24uIFRoZSBjbGllbnQgaXMg c2ltcGx5IHBhc3Npbmcgb25lIGl0IHByZXZpb3VzbHkgb2J0YWluZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgbm90IGJlYXJlci4gSXQgaXMgaG9sZGVy IG9mIGtleS4gVmVyeSB2ZXJ5IGRpZmZlcmVudC4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHBvc3NpYmxlIHN1Z2dlc3Rp b24gaXMgdG8gcmVtb3ZlIGNsaWVudF9zZWNyZXRfand0IGFuZCBwcml2YXRlX2tleV9qd3QgYW5k IGRlZmluZSB0aG9zZSBhcyByZWdpc3RlciBleHRlbnNpb25zIHNpbmNlIHRoZXNlIHByb2ZpbGVz IGFyZSBub3QgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBwb3Nz aWJsZSwgYnV0IHRoZXkgYXJlIGluIGFjdGl2ZSB1c2UgYWxyZWFkeS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCBtYXkgYmUgdHJ1ZS4gQnV0IHRoZW4geW91IG5lZWQgdG8gd3JpdGUg YW5vdGhlciBkcmFmdCBzbyB0aGUgcmVzdCBvZiB1cyBjYW4gaW1wbGVtZW50IGl0IGluIGFuIGlu dGVyb3BlcmFibGUgd2F5LiAmbmJzcDtNZSBJIHByZWZlciBub3QgdG8gZ3Vlc3Mgd2hhdCB5b3Ug YXJlIGRvaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIG11Y2ggSSBhZ3JlZSB3aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBC MDUwIj5KdXN0aW4sIEpvaG4sIGFuZCBJIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGFuZCBhZ3JlZSB3 aXRoIHlvdXIgc3VnZ2VzdGlvbiwgUGhpbC4mbmJzcDsgU2luY2UgdGhleSBhcmUgbm90IGNvbXBs ZXRlbHkgc3BlY2lmaWVkLCB3ZSB3aWxsIHJlbW92ZSB0aGUgY2xpZW50X3NlY3JldF9qd3QNCiBh bmQgcHJpdmF0ZV9rZXlfand0IG1ldGhvZHMgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgYWRk IGEgcmVnaXN0cnksIGVuYWJsaW5nIHNwZWNpZmljYXRpb24gdGhhdCBkbyBmdWxseSBzcGVjaWZ5 IHRoZXNlIGFuZCBvdGhlciB0b2tlbiBlbmRwb2ludCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLCBp bmNsdWRpbmcgcG90ZW50aWFsIG1ldGhvZHMgdXNpbmcgU0FNTCBhc3NlcnRpb25zLCB0byByZWdp c3RlciB0aGVtIGluIHRoZSByZWdpc3RyeSwNCiByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYmFrZSB0 aGVtIGludG8gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkFib3V0ICZxdW90O3Rvc191cmkmcXVvdDsgYW5kICZxdW90O3Bv bGljeV91cmkmcXVvdDs8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRpc3RpbmN0aW9uIGJl dHdlZW4gdG9zX3VyaSBhbmQgcG9saWN5X3VyaSBpcyB1bmNsZWFyLiAmbmJzcDtDYW4gd2UgY2xh cmlmeSBvciBjb21iaW5lIHRoZW0/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZXJtcyBv ZiBzZXJ2aWNlIGFuZCBwb2xpY3kgYXJlIHR3byBkaWZmZXJlbnQgZG9jdW1lbnRzLiBPbmUgaXMg c29tZXRoaW5nIHRoYXQgYSB1c2VyIGFjY2VwdHMgKGdlbmVyYWxseSBkZXNjcmliaW5nIHdoYXQg dGhlIHVzZXIgd2lsbCBkbyksIG9uZSBpcyBhIHN0YXRlbWVudCBvZiB3aGF0IHRoZSBzZXJ2aWNl IHByb3ZpZGVyIChpbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQpIHdpbGwgZG8uIE1vcmUgaW1wb3J0 YW50bHksDQogd2UgdXNlZCB0byBoYXZlIG9ubHkgb25lLCBhbmQgc2V2ZXJhbCBwZW9wbGUgYXNr ZWQgZm9yIHRoZW0gdG8gYmUgc3BsaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNldmVyYWwgZGV2ZWxvcGVycyB3ZXJlIGNvbmZ1c2VkIGJ5IHRoaXMuIEluIHBhcnRpY3Vs YXIgdGhleSBjb3VsZG4ndCBmaWd1cmUgb3V0IHdoaWNoIHdhcyB1c2VkIGZvciB3aGF0LiAmbmJz cDtKdXN0IHBhc3NpbmcgYWxvbmcgdGhlIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PSywgdGhlIGRpc3RpbmN0aW9uIHRoYXQgSSBzZWUgaXMgdGhhdCB0aGUg VE9TIGlzIGNvbnRyYWN0dWFsLCB0aGUgUG9saWN5IGlzIGEgc3RhdGVtZW50LiBSZS1yZWFkaW5n IHRoZSBkZWZpbml0aW9ucyBpbiB0aGVyZSByaWdodCBub3csIHRoYXQgY2FuIGJlIG1hZGUgbXVj aCBjbGVhcmVyLiAoSXQgZXZlbiBsb29rcyBsaWtlIHNvbWUgT0lEQyB0ZXh0IGxlYWtlZCBpbnRv IHRoZSBkZWZpbml0aW9uIG9mIHBvbGljeV91cmkNCiBhbmQgdGhhdCBoYWRuJ3QgYmVlbiBjYXVn aHQgeWV0Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+SSBzdXBwb3J0 IGNsYXJpZnlpbmcgdGhlIGxhbmd1YWdlIG9uIHRoZXNlIGRlZmluaXRpb25zLCBhbmQgd2lsbCB3 b3JrIHdpdGggSnVzdGluIHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFsc28sIGFyZW4ndCB0aGVzZSByZWFsbHkgVVJJcyBvciBhcmUgdGhleSBtZWFudCB0byBi ZSBVUkxzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgd2FzIGFscmVhZHkgZGlz Y3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRoZSBsaXN0OiBUaGUgSUVURiBpcyBhcHBhcmVudGx5IHRy eWluZyB0byBkZXByZWNhdGUgVVJMIGluIGZhdm9yIG9mIFVSSSBpbiBuZXcgc3BlY3MuIFNvIGlu IHByYWN0aWNlIHRoZXknbGwgbmVhcmx5IGFsd2F5cyBiZSBVUkxzLCBidXQgc2luY2UgYWxsIFVS THMgYXJlIFVSSXMgd2UncmUgbm90IHRlY2huaWNhbGx5IGluY29ycmVjdA0KIGluIGZvbGxvd2lu ZyB0aGUgbmV3IHBvbGljeS4gQW5kIGl0IG1ha2VzIHRoZSBJRVNHIGxlc3MgbWFkIGF0IHVzLCB3 aGljaCBpcyBhIHBsdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZy4g TmljZS4gJm5ic3A7VGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5IHRoZSB2YWx1ZSBwYXNzZWQgbXVz dCByZXNvbHZlIHRvIGEgdmFsaWQgd2ViIHBhZ2UsIGRvY3VtZW50LCB3aGF0ZXZlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIGZhaXIsIGFuZCBpdCdzIHNvbWV0 aGluZyB0aGF0IHRoZSBBUyBjYW4gZXZlbiBjaGVjayBpZiBpdCB3YW50cyB0by48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjttYXJn aW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+QWdyZWVkIG9uIHRoaXMgY2xhcmlmaWNhdGlv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5BYm91dCAmcXVvdDtqd2tz X3VyaSZxdW90OzwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIG5vcm1hdGl2ZSByZWZlcmVuY2Ug Zm9yJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1qb3NlLWpzb24td2ViLWtleS0wOSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWtleS0wOTwvYT4mbmJzcDtpcw0KIG5lZWRlZC4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB5b3UncmUgY29ycmVj dCwgSSdsbCBhZGQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TaG91bGQgYmUgVVJMIGluc3RlYWQgb2YgVVJJPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VlIGFib3ZlLiA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDBCMDUwIj5BZ3JlZWQgb24gYWRkaW5nIHRoaXMgcmVmZXJlbmNlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TZWN0aW9uIDIuMTwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiB0aGUgdGFibGUmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3Bh biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOmdyYW50LXR5cGU6and0LWJlYXJlcjwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgbWlzc2luZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0J3MgdGhlcmUgaW4gdGhlIGNvcHkgb2YgLTEwIEknbSByZWFkaW5n IG9mZiBvZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwOi8vaWV0Zi5vcmcvIj5pZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cmlnaHQgbm93IOKApiA/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPic8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBJIG1lYW50OiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij51cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpz YW1sLWJlYXJlcjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFoLCB0aGF0IG1ha2VzIG1vcmUgc2Vuc2UuIElmIHRoZSBXRyB3YW50cyB0byBhZGQgaW4g U0FNTCBzdXBwb3J0IHRvIHBhcmFsbGVsIHRoZSBKV1Qgc3VwcG9ydCwgSSdkIGJlIE9LIHdpdGgg dGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij7igJxBcyBzdWNoLCBhIHNlcnZlciBzdXBwb3J0aW5nIHRoZXNlIGZpZWxkcyBTSE9VTEQgdGFr ZSBzdGVwcyZuYnNwO3RvIGVuc3VyZSB0aGF0IGEgY2xpZW50IGNhbm5vdCByZWdpc3RlciBpdHNl bGYgaW50byBhbiBpbmNvbnNpc3RlbnQgc3RhdGUu4oCdPGJyPg0KPGJyPg0KV2UgbWF5IHdhbnQg dG8gZGVmaW5lIG1vcmUgZGV0YWlsZWQgSFRUUCBlcnJvciByZXNwb25zZS4mbmJzcDtFLmcuIDQw MCBzdGF0dXMgY29kZSAmIzQzOyBkZWZpbmVkIGVycm9yIGNvZGUgKOKAnGludmFsaWRfY2xpZW50 X21ldGFkYXRh4oCdKT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBmaW5lIHdp dGggZGVmaW5pbmcgYSBtb3JlIGV4cGxpY2l0IGVycm9yIHN0YXRlIGluIHRoaXMgY2FzZS4gSSB0 aGluayBpdCB3b3VsZCBoZWxwIGludGVyb3AgZm9yIHRoZSBzZXJ2ZXJzIHRoYXQgd2FudCB0byBl bmZvcmNlIGdyYW50LXR5cGUgYW5kIHJlc3BvbnNlLXR5cGUgcmVzdHJpY3Rpb25zLCBidXQgc2Vy dmVycyB0aGF0IGNhbid0IG9yIGRvbid0IGNhcmUgYWJvdXQgcmVzdHJpY3RpbmcgZ3JhbnRzDQog dHlwZXMgYW5kIHdoYXRub3QgZG9uJ3QgaGF2ZSB0byBkbyBhbnl0aGluZyBzcGVjaWFsLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5JICo8Yj50aGlu azwvYj4qIHRoYXQgdGhpcyBnb2VzIGF3YXkgd2l0aCB0aGUgZGVsZXRpb24gb2YgY2xpZW50X3Nl Y3JldF9qd3QgYW5kIHByaXZhdGVfa2V5X2p3dCBpbiBmYXZvciBvZiB0aGUgcmVnaXN0cnnigKYm bmJzcDsgSeKAmWxsIGRvIGEgY29uc2lzdGVuY3kgY2hlY2sgYW5kIHZlcmlmeQ0KIHRoYXQgd2hl biB0aGUgc3BlYyBpcyB1cGRhdGVkIGFjY29yZGluZ2x5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1BIXSBBZ3JlZWQuPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0Ij5TZWN0aW9uIDIuMjwvc3Bhbj48L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQiPk1heSB3YW50IHRvIGFkZDo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4mbmJzcDvigJwj 4oCdIGxhbmd1YWdlIHRhZyBpcyBtaXNzaW5nLCAoZS5nLiDigJwjZW7igJ0gaXMgbWlzc2luZyBp biDigJxjbGllbnRfbmFtZeKAnSwgaW5zdGVhZCZuYnNwO29mIOKAnGNsaWVudF9uYW1lI2Vu4oCd KSB0aGUgT0F1dGggc2VydmVyIG1heSB1c2UgaW50ZXJwcmV0IHRoZSZuYnNwO2xhbmd1YWdlIHVz ZWQgYmFzZWQmbmJzcDtvbiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBvciBoZXVyaXN0aWNzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCBzZWVtcyBpbmNvbnNpc3RlbnQgd2l0aCB3aGF0IHdlIGFscmVh ZHkgaGF2ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGFueSBodW1hbi1yZWFk YWJsZSBmaWVsZCBpcyBzZW50IHdpdGhvdXQgYSBsYW5ndWFnZSB0YWcsIHBhcnRpZXMgdXNpbmcg aXQgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGxhbmd1YWdlLCBjaGFy YWN0ZXIgc2V0LCBvciBzY3JpcHQgb2YgdGhlIHN0cmluZyB2YWx1ZSwgYW5kIHRoZSBzdHJpbmcg dmFsdWUgTVVTVCBiZSB1c2VkIGFzLWlzIHdoZXJldmVyIGl0IGlzIHByZXNlbnRlZA0KIGluIGEg dXNlciBpbnRlcmZhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggaXMgdG8gc2F5LCB0cmVhdCBpdCBhcyBhIHJh dyBieXRlLXZhbHVlLXN0cmluZyBhbmQgZG9uJ3QgdHJ5IHRvIGdldCBmYW5jeS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBkaXNjdXNz IHdpdGggb3VyIGRldmVsb3BlcnMuIEknbSBub3Qgc3VyZSB0aGUgYXMtaXMgd29ya3MuICZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0IHRoZSBpbnRlbnQgdGhhdCB3aGVuIHRoZSBjbGll bnQgaGFzIGxvY2FsaXplZCAmcXVvdDtjbGllbnRfbmFtZSZxdW90OyBmb3IgZXhhbXBsZSwgaXQg c2hvdWxkIHBhc3MgYWxsIGxhbmd1YWdlIHZhcmlhdGlvbnMgaW4gYSBKU09OIGFycmF5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9yLCBzaG91bGQgcGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIGJlIHRv IGluZGljYXRlIHdoaWNoIGludGVyZmFjZSBsYW5ndWFnZSB0aGUgY2xpZW50IHdpc2hlcyB0byB1 c2U/ICZuYnNwO1RoZW4gaXQgb25seSBwYXNzZXMgYSBzaW5nbGUgdmFsdWUgZm9yIHRoYXQgcmVn aXN0cmF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgdGhlIGNsaWVudCBzaG91bGQgcGFz cyBwYXJhbWV0ZXJzIGFzIG11bHRpcGxlIHNlcGFyYXRlIHZhbHVlcy4gQ29ubmVjdCBoYXMgdGhp cyBpbiBpdHMgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7ICZxdW90O2NsaWVudF9uYW1lJnF1b3Q7OiAmcXVv dDtNeSBFeGFtcGxlJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDsmbmJzcDsgJnF1b3Q7Y2xpZW50X25hbWUjamEtSnBhbi1KUCZxdW90 Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDsiPuOCr+ODqeOCpOOCouODs+ODiOWQjTwvc3Bhbj4mcXVvdDssPG86cD48 L286cD48L3ByZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNob3VsZCB3ZSBhZGQgdGhhdCB0byBhdCBsZWFzdCBvbmUgb2YgdGhl IGV4YW1wbGVzIGluIER5blJlZz8gKFRoZSBsYW5ndWFnZSB0YWdzIGFyZSBhIGxhdGUgYWRkaXRp b24sIHNvIHRoZSBleGFtcGxlcyBkb24ndCByZWZsZWN0IGl0Lik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBleGFtcGxl IHdvdWxkIGRlZmluaXRlbHkgaGVscC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBj bGllbnQgcGFzc2VzIG9ubHkgYSBzaW5nbGUgdW5hZG9ybmVkIGZpZWxkLCB0aGUgQVMgY2FuJ3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB3aGF0IGxhbmd1YWdlIGl0IGlzLiBUaGluayBvZiB0 aGlzIGFzIHRoZSBpbnRlcm5hdGlvbmFsaXplZCB2YWx1ZSBvZiB0aGUgZmllbGQgd2hpbGUgdGhl IGxhbmd1YWdlIHRhZ3MgYXJlIHRoZSBsb2NhbGl6ZWQgdmVyc2lvbnMgb2YgdGhlIGZpZWxkLiBU aGlzDQogaXMgd2h5IHdlIHJlY29tbWVuZCB0aGF0IHRoZSBiYXJlLXZhbHVlIGFsd2F5cyBiZSBz ZW50IGJ5IHRoZSBjbGllbnQsIHNvIHRoYXQgaW4gdGhlIGxhY2sgb2YgYW55dGhpbmcgbW9yZSBz cGVjaWZpYywgdGhlIEFTIGNhbiBhdCBsZWFzdCBkbyAqc29tZXRoaW5nKiB3aXRoIGl0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBhc3NpbmcgaW4gYSAmcXVvdDtkZWZhdWx0JnF1b3Q7IGxhbmd1YWdl IGZpZWxkIChsaWtlIGRlZmF1bHRfbG9jYWxlIG9yIHRoZSBsaWtlKSBpcyBvbmx5IGdvaW5nIHRv IGxlYWQgdG8gcGFpbiBmb3IgaW1wbGVtZW50b3JzIG9mIGJvdGggY2xpZW50cyBhbmQgc2VydmVy cywgYW5kIGl0J3MgZ29pbmcgdG8gaHVydCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgaHVt YW4tcmVhZGFibGUgZmllbGRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2hhdCBJIG1lYW50IGlzIHNpbmNl IHlvdSBhcmUgYWxsb3dpbmcgZWFjaCBjbGllbnQgdG8gcmVnaXN0ZXIgZGlmZmVyZW50IHRoaW5n cywgQU5EIHRoZSBjbGllbnQgbGlrZWx5IGFscmVhZHkga25vd3MgdGhlIHVzZXIncyBwcmVmZXJy ZWQgbGFuZ3VhZ2UsIHdoeSB3b3VsZG4ndCB0aGUgY2xpZW50IGp1c3QgcGFzcyB0ZXh0IHZhbHVl cyBpbiBvbmUgbGFuZ3VhZ2UgYW5kIGFub3RoZXIgcGFyYW1ldGVyDQogaW5kaWNhdGluZyBwcmVm ZXJyZWQgbGFuZ3VhZ2UgaW4gdGhlIGNhc2Ugb2YgYW55IHNlcnZpY2UgZ2VuZXJhdGVkIHRleHQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlIHJlYXNvbiB5b3UgYXJlIHBhc3NpbmcgbXVsdGlw bGUgbG9jYWxpemF0aW9ucyBpcyBzbyB0aGF0IHlvdSBjYW4gdXNlIHRoZSBwcmVmZXJyZWQgbGFu Z3VhZ2Ugb2YgdGhlIHJlc291cmNlIG93bmVyIHJhdGhlciB0aGVuIHRoZSBjbGllbnQgdXNlcj8g SSB3b25kZXIgaWYgdGhhdCBpcyBjb3JyZWN0LiAmbmJzcDtJZiB0aGUgbGFuZ3VhZ2UgcHJlZmVy ZW5jZXMgYXJlIGluIGZhY3QgZGlmZmVyZW50LCB3aGF0DQogd291bGQgdGhlIHVzZXIgb2YgdGhl IGNsaWVudCBhcHAgZXhwZWN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0mZ3Q7IGFueSBtdWx0 aS1saW5ndWFsIHBlb3BsZSBoYXZlIGFueSBvcGluaW9ucyBoZXJlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbjttYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+V2l0aG91dCBzcGVjaWZpYyBw cm9wb3NlZCB0ZXh0IGNoYW5nZXMgdG8gcmV2aWV3LCBpdOKAmXMgaGFyZCB0byBrbm93IHdoYXQg dG8gdGhpbmsgYWJvdXQgdGhpcyBjb21tZW50LiZuYnNwOyBVbmxlc3MgYSBzcGVjaWZpYyBwcm9w b3NlZCB0ZXh0IGNoYW5nZSBpcyBzZW50IHRvIHRoZQ0KIGxpc3Qgd2l0aCBjbGVhciByYXRpb25h bGUgZm9yIHdoeSBpdOKAmXMgYmV0dGVyIHRoYW4gd2hhdOKAmXMgdGhlcmUgbm93IGFuZCByZXZp ZXdlZCBieSB0aGUgd29ya2luZyBncm91cCwgSSBkb27igJl0IGJlbGlldmUgd2Ugc2hvdWxkIGNo YW5nZSB0aGUgc3BlY2lmaWNhdGlvbiBpbiByZXNwb25zZSB0byB0aGlzIGNvbW1lbnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltQ SF0gSSBhZ3JlZS4gSSBwbGFuIHRvIGZvbGxvdyB1cCBhbmQgc2VlIGlmIEkgY2FuJ3QgZ2V0IG1v cmUgY2xhcmlmaWNhdGlvbiBvbiByZXF1aXJlbWVudHMgZnJvbSBteSBzaWRlLiZuYnNwOzxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+U2VjdGlvbiAzPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4aXN0aW5nIHRleHQ6PGJyPg0K PGJyPg0K4oCcSW4gb3JkZXIgdG8gc3VwcG9ydCBvcGVuIHJlZ2lzdHJhdGlvbiBhbmQgZmFjaWxp dGF0ZSB3aWRlciZuYnNwO2ludGVyb3BlcmFiaWxpdHksIHRoZSBDbGllbnQgUmVnaXN0cmF0aW9u IEVuZHBvaW50Jm5ic3A7U0hPVUxEJm5ic3A7YWxsb3cgaW5pdGlhbCByZWdpc3RyYXRpb24mbmJz cDtyZXF1ZXN0cyB3aXRoIG5vJm5ic3A7YXV0aGVudGljYXRpb24uJm5ic3A7Jm5ic3A7VGhlc2Ug cmVxdWVzdHMgTUFZIGJlJm5ic3A7cmF0ZS1saW1pdGVkIG9yIG90aGVyd2lzZSBsaW1pdGVkIHRv IHByZXZlbnQgYSBkZW5pYWwtb2Ytc2VydmljZQ0KIGF0dGFjayBvbiB0aGUmbmJzcDtDbGllbnQm bmJzcDtSZWdpc3RyYXRpb24gRW5kcG9pbnQu4oCdPGJyPg0KPGJyPg0KSSB3b3VsZCBzdWdnZXN0 IHRvIGNoYW5nZSB0aGUgZmlyc3Qg4oCcU0hPVUxE4oCdIHRvIOKAnE1BWeKAnS4mbmJzcDsgJm5i c3A7SW4gbW9zdCBjbG91ZCBzZXJ2aWNlcywgdGhlIGZpcnN0IGNsaWVudCBpcyZuYnNwO3JlZ2lz dGVyZWQgYnkgYSBodW1hbiB1c2VyLiBUaGVuLCBvdGhlciZuYnNwO2NsaWVudHMgY2FuIGJlIGZ1 cnRoZXIgdXNlZCB0byBhdXRvbWF0ZSZuYnNwO290aGVyIGNsaWVudCByZWdpc3RyYXRpb24uJm5i c3A7Jm5ic3A7U28sIHRoZSBmaXJzdCZuYnNwO3JlcXVlc3Qgd291bGQgdHlwaWNhbGx5IGNvbWUg d2l0aA0KIGFuIGF1dGhlbnRpY2F0ZWQgdXNlciBpZGVudGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgdGhlIHdlaWdodCBvZiAmcXVvdDtTSE9VTEQmcXVvdDsgaXMgYXBwcm9w cmlhdGUgaGVyZSwgYmVjYXVzZSBJIGJlbGlldmUgdGhhdCB0dXJuaW5nIG9mZiBvcGVuIHJlZ2lz dHJhdGlvbiBhdCB0aGUgQVMgKHdoaWNoIGlzIHdoYXQgdGhpcyBpcyB0YWxraW5nIGFib3V0KSBy ZWFsbHkgb3VnaHQgdG8gYmUgdGhlIGV4Y2VwdGlvbiByYXRoZXIgdGhhbiB0aGUgcnVsZS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3UgYXJlIHJl YWRpbmcgaXQgd3JvbmcgLS0gYSBkb3VibGUtbmVnYXRpdmUgaXNzdWUuIFRoZSBlbmQgb2YgdGhl IHNlbnRlbmNlIGlzICZxdW90O25vIGF1dGhlbnRpY2F0aW9uJnF1b3Q7LiAmbmJzcDtZb3UgYXJl IGltcGx5aW5nIHRoYXQgTk8gQXV0aGVudGljYXRpb24gdXMgd2hhdCBzaG91bGQgbm9ybWFsbHkg YmUgZG9uZS4gSSB0aGluayB5b3UgaW50ZW5kIGFub255bW91cyBhdXRoZW50aWNhdGlvbiB0byBi ZSB0aGUNCiBleGNlcHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUgZG9uJ3QgeW91PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgSSB0aGluayB0aGF0IGFub255bW91cyBh dXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdGhlIHJ1bGUuIE9wZW4gcmVnaXN0cmF0aW9uIHNob3Vs ZCBiZSBkZWZhdWx0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaXNhZ3JlZS4gJm5ic3A7QWdhaW4sICZuYnNwO3RoZSBz cGVjIHNlZW1zIGNvbnRyYWRpY3RvcnkuIEl0IHN1Z2dlc3RzIHN0cm9uZyBjbGllbnQgYXV0aCBt ZXRob2RzIGFuZCBhdCB0aGUgc2FtZSB0aW1lIGFub255bW91cyByZWdpc3RyYXRpb24uICZuYnNw O1llcyB5b3UgZ2FpbiB1bmlxdWVuZXNzLCBidXQgdGhhdCdzIGFib3V0IGl0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIHRoZSBmbGlw IHNpZGUsIHRoZSBlYXJsaWVyIHBhcmFncmFwaDo8YnI+DQo8YnI+DQrigJxUaGUgQ2xpZW50IFJl Z2lzdHJhdGlvbiBFbmRwb2ludCZuYnNwO01BWSZuYnNwO2FjY2VwdCBhbiBpbml0aWFsIGF1dGhv cml6YXRpb24gY3JlZGVudGlhbCBpbiB0aGUgZm9ybSBvZiBhbiBPQXV0aCAyLjAmbmJzcDtbUkZD Njc0OV0gYWNjZXNzIHRva2VuIGluIG9yZGVyIHRvJm5ic3A7bGltaXQgcmVnaXN0cmF0aW9uIHRv IG9ubHkgcHJldmlvdXNseSZuYnNwO2F1dGhvcml6ZWQgcGFydGllcy4gVGhlIG1ldGhvZCBieSB3 aGljaCB0aGlzIGFjY2VzcyB0b2tlbiBpcyBvYnRhaW5lZCBieSB0aGUmbmJzcDtyZWdpc3RyYW50 DQogaXMgZ2VuZXJhbGx5IG91dC1vZi1iYW5kIGFuZCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uLuKAnTxicj4NCjxicj4NCkkgdGVuZCB0byB0aGluayBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gY2hhbmdlIHRoaXMg4oCcTUFZ4oCdIHRvIOKAnFNIT1VMROKAnS48YnI+DQo8YnI+ DQpUaGF0IGFjY2VzcyB0b2tlbiB3b3VsZCBjYXJyeSBhIGh1bWFuIHVzZXIgYXV0aGVudGljYXRl ZCZuYnNwO2lkZW50aXR5IHNvbWVob3cuIEluIHNvbWUgY2FzZXMsIGl0IGNhbiBiZSBhIHB1cmUg YXV0aGVudGljYXRlZCB1c2VyIGFzc2VydGlvbiZuYnNwO3Rva2VuLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2Fp biwgZGlzYWdyZWUsIGZvciB0aGUgc2FtZSByZWFzb25pbmcgYXMgYWJvdmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhbWUgcmVhc29uaW5nLiZuYnNwOzxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkkgYWdyZWUgd2l0 aCBKdXN0aW4gaGVyZS4mbmJzcDsgVGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgb3BlbiByZWdp c3RyYXRpb25zIGFyZSBlbmFibGVkLiZuYnNwOyBUaGUgZXhjZXB0aW9uIGNhc2UgaXMgdGhhdCBz cGVjaWZpYyBwZXJtaXNzaW9ucyBhcmUgcmVxdWlyZWQgdG8gcGVyZm9ybQ0KIGR5bmFtaWMgY2xp ZW50IHJlZ2lzdHJhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1BIXSBJJ20gbm90IHN1cmUgSSB1bmRlcnN0 YW5kIHlvdXIgbGFzdCBzZW50ZW5jZS4gSXQgc2VlbXMgdG8gY29udHJhZGljdCB5b3VyIHBvc2l0 aW9uLiBJZiB5b3UgbmVlZCBzcGVjaWZpYyBwZXJtaXNzaW9ucywgdGhlbiBzdXJlbHkgeW91IGNh bid0IGJlIGFub255bW91cz8/Pzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPltt YmpdIE1vcmUgY2xlYXJseSBwdXQsIGl0IHNob3VsZCBiZSBhbiBleGNlcHRpb24gZm9yIHRoZSBw YXJ0eSB3YW50aW5nIHRvIHJlZ2lzdGVyIGEgY2xpZW50IHRvIGhhdmUgdG8gb2J0YWluIHNwZWNp YWwgcGVybWlzc2lvbnMgdXAgZnJvbnQgdG8gcmVnaXN0ZXIgdGhlDQogY2xpZW50LiZuYnNwOyBJ biB0aGUgbm9ybWFsIGNhc2UsIHRoZSBwYXJ0eSB3YW50aW5nIHRvIHJlZ2lzdGVyIGEgY2xpZW50 IHNob3VsZCByZXF1aXJlIG5vIHNwZWNpYWwgdXAtZnJvbnQgcGVybWlzc2lvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5BYm91dCBzZWN0aW9uIDQuMzo8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+SWYgdGhlIGNsaWVudCBkb2VzIG5vdCBleGlzdCBvbiB0aGlz IHNlcnZlciwgdGhlIHNlcnZlciBNVVNUIHJlc3BvbmQ8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IHdpdGggSFRUUCA0MDEg VW5hdXRob3JpemVkLCBhbmQgdGhlIFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gdXNlZCB0bzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsmbmJzcDsgbWFrZSB0aGlzIHJlcXVlc3QgU0hPVUxEIGJlIGltbWVkaWF0ZWx5IHJldm9rZWQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBDbGllbnQgZG9lcyBub3QgZXhpc3Qgb24mbmJz cDt0aGlzIHNlcnZlciwgc2hvdWxkbid0IGl0IHJldHVybiBhICZxdW90OzQwNCBOb3QgRm91bmQm cXVvdDs/PGJyPg0KPGJyPg0KSWYgcmV2b2tpbmcgdGhlIHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9r ZW4sIGlzIGl0IGJvdW5kIHRvIGEgc2luZ2xlIGNsaWVudCByZWdpc3RyYXRpb24/ICZuYnNwO1Ro aXMgaXMgbm90IGNsZWFyLiAmbmJzcDtXaGF0IGlzIHRoZSBsaWZlY3ljbGUgYXJvdW5kIHJlZ2lz dHJhdGlvbiBhY2Nlc3MgdG9rZW4/IE9ubHkgaGludCBpcyBpbiB0aGUgQ2xpZW50IEluZm9ybWF0 aW9uIFJlc3BvbnNlIGluIHNlY3Rpb24gNS4xLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxhbmd1 YWdlIGFib3V0IHRoZSA0MDEgaGVyZSAoYW5kIGluIG90aGVyIG5lYXJieSBzZWN0aW9ucykgaXMg c3BlY2lmaWNhbGx5IHNvIHRoYXQgeW91IHRyZWF0IGEgbWlzc2luZyBjbGllbnQgYW5kIGEgYmFk IHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW4gdGhlIHNhbWUgd2F5LiBZb3Ugc2VlLCZuYnNwO3Jl dHVybmluZyBhIDQwNCBoZXJlIGFjdHVhbGx5IGluZGljYXRlcyB0aGluZ3Mgd2VyZSBpbiBhbiBp bmNvbnNpc3RlbnQNCiBzdGF0ZS4gTmFtZWx5LCB0aGF0IHRoZSByZWdpc3RyYXRpb24gYWNjZXNz IHRva2VuIHdhcyBzdGlsbCB2YWxpZCBidXQgdGhlIGNsaWVudCB0aGF0IHRoZSByZWdpc3RyYXRp b24gYWNjZXNzIHRva2VuIHdhcyBhdHRhY2hlZCB0byBkb2Vzbid0IGV4aXN0IGFueW1vcmUuIFRo ZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGluIG1lYW50IHRvIGJlIHRpZWQgdG8gYSBjbGll bnQncyBpbnN0YW5jZSAob3IgcmVnaXN0cmF0aW9uKSwgc28gaXQncyBhY3R1YWxseQ0KIG1vcmUg c2Vuc2libGUgdG8gYWN0IGFzIHRob3VnaCB0aGUgcmVnaXN0cmF0aW9uIGFjY2VzcyB0b2tlbiBp c24ndCB2YWxpZCBhbnltb3JlLiBJbiBhdCBsZWFzdCBzb21lIGltcGxlbWVudGF0aW9ucyAoc3Bl Y2lmaWNhbGx5IG91cnMgYXQgTUlUUkUgdGhhdCdzIGJ1aWx0IG9uIFNFQ09BVVRIIGluIEphdmEp LCB5b3UnZCBuZXZlciBiZSBhYmxlIHRvIHJlYWNoIHRoZSA0MDQgc3RhdGUgZHVlIHRvIGNvbnNp c3RlbmN5IGNoZWNraW5nIHdpdGggdGhlDQogaW5ib3VuZCB0b2tlbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TaW5jZSB0aGUgaW50ZW50IG9mIHRoZSByZWdpc3RyYXRpb24gYWNjZXNzIHRva2VuIGlz IHRoYXQgaXQncyBib3VuZCB0byBhIHNpbmdsZSBpbnN0YW5jZSwgaXRzIGxpZmVjeWNsZSBpcyBn ZW5lcmFsbHkgdGllZCB0byB0aGUgbGlmZWN5Y2xlIGJlZ2lucyBhdCB0aGUgaXNzdWFuY2Ugb2Yg YSBuZXcgY2xpZW50X2lkIHdpdGggdGhhdCBpbnN0YW5jZS4gVGhhdCB0b2tlbiBtaWdodCBiZSBy ZXZva2VkIGFuZCBhDQogbmV3IG9uZSBpc3N1ZWQgb24gUmVhZCBhbmQgVXBkYXRlIHJlcXVlc3Rz IHRvIHRoZSBDbGllbnQgQ29uZmlndXJhdGlvbiBFbmRwb2ludCAoYW5kIHRoZSBjbGllbnQgbmVl ZHMgdG8gYmUgcHJlcGFyZWQgZm9yIHRoYXQgLS0gc2FtZSBhcyB0aGUgY2xpZW50X3NlY3JldCks IGFuZCBpdCB3aWxsIGJlIHJldm9rZWQgd2hlbiB0aGUgY2xpZW50IGlzIGRlbGV0ZWQgZWl0aGVy IHdpdGggYSBEZWxldGUgY2FsbCB0byB0aGUgQ2xpZW50IENvbmZpZ3VyYXRpb24NCiBFbmRwb2lu dCBvciBzb21ldGhpbmcgaGFwcGVuaW5nIG91dC1vZi1iYW5kIHRvIGtpbGwgdGhlIGNsaWVudC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgd2UgYWRkIG1vcmUgZXhwbGFuYXRvcnkg dGV4dCB0byB0aGUgZGVmaW5pdGlvbiBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbj8gRWxzZXdo ZXJlPyBJJ20gdmVyeSBvcGVuIHRvIGNvbmNyZXRlIHN1Z2dlc3Rpb25zIHdpdGggdGhpcywgc2lu Y2UgSSBkb24ndCB0aGluayBpdCdzIGFzIGNsZWFyIGFzIHdlJ2QgbGlrZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB0aGluayB3ZSBzaG91bGQgbG9vayBhdCBpdC48YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5Gb3Igc2VjdXJpdHkgcmVhc29u cywgaXTigJlzIGdlbmVyYWxseSBub3QgZ29vZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIOKAnG5v dCBmb3VuZOKAnSBhbmQg4oCcdW5hdXRob3JpemVk4oCdIGVycm9ycyBpbiByZXNwb25zZXMsIGFz IHRoYXQgY2FuIHByb3ZpZGUgdGhlIGF0dGFja2VyIGFuDQogb3JhY2xlIHRvIHByb2JlIHdoZXRo ZXIgYSBwYXJ0aWN1bGFyIGVudGl0eSBleGlzdHMmbmJzcDsgSSBkb27igJl0IHRoaW5rIGEgY2hh bmdlIGlzIGNhbGxlZCBmb3IgaGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1BIXSBJIGFncmVlIGluIHByaW5j aXBsZS4gVGhpcyBpc3N1ZSBpcyBib3VuZCB1cCB0b28gaW4gd2hhdCB0aGUgbGlmZS1jeWNsZSBv ZiB0aGUgcmVnaXN0cmF0aW9uIGFuZCB0aGUgYWNjZXNzIHRva2VuIGFuZCBjbGllbnQgdG9rZW5z LiBXZSBuZWVkIHRvIGRlc2NyaWJlIHRob3NlIGZpcnN0IGJlZm9yZSB0aGlzIGJlY29tZXMgY2xl YXIuICZuYnNwO0ZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IGlzIHN0aWxsIGF1dGhlbnRpY2F0 ZWQsDQogYnV0IGl0cyByZWdpc3RyYXRpb24gaXMgZ29uZSwgaXQgc2hvdWxkIGJlIG5vdCBmb3Vu ZC4gJm5ic3A7QnV0IEkgYWdyZWUgdGhpcyBkb2Vzbid0IG1ha2Ugc2Vuc2UsIGJlY2F1c2UgdGhl ICZxdW90O2ltcGxpZWQmcXVvdDsgYWN0aW9uIHdhcyB0aGF0IHRoZSBkZWxldGlvbiBvZiBhIHJl Z2lzdHJhdGlvbiBpbnZhbGlkYXRlcyBhbGwgYXNzb2NpYXRlZCBjcmVkZW50aWFscy4gLS0tJmd0 OyBtZWFuaW5nIHRoZSBjbGllbnQgc2hvdWxkIG5ldmVyIGJlIGFibGUgdG8gYXV0aGVudGljYXRl DQogd2l0aCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IGFueXdheS48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDBCMDUwIj5bbWJqXSBCeSB0aGUgd2F5LCB5b3Ugd3JpdGluZyB0aGF0IOKA nDwvc3Bhbj50aGUgY2xpZW50IHNob3VsZCBuZXZlciBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB3 aXRoIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgYW55d2F5PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMEIwNTAiPuKAnQ0KIG1ha2VzIHRoZSBjYXNlIGZvciB3aHkgdGhlIHBl cm1pc3Npb25zIG9uIHRoZSBjbGllbnTigJlzIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCBhcmUgZGlm ZmVyZW50IHRoYW4gdGhvc2UgZ3JhbnRlZCB0byB0aGUgY2xpZW50IOKAkyBoZW5jZSB0aGUgbmVl ZCBmb3IgdGhlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8Yj5BYm91dCBzZWN0aW9uIDUuMTo8L2I+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXMgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiB1bmlxdWU/ICZuYnNwO09yIGlzIGl0 IHNoYXJlZCBieSBtdWx0aXBsZSBpbnN0YW5jZXM/ICZuYnNwOyBJZiBzaGFyZWQsIHRoZW4gcmVn aXN0cmF0aW9uX2FjY2Vzc190b2tlbiBjYW4ndCBiZSByZXZva2VkIG9uIGRlbGV0ZSBvZiBjbGll bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBC MDUwIj5UaGUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbiBpcyB1bmlxdWUgdG8gYSByZWdpc3Rl cmVkIGNsaWVudCwgaW4gdGhlIFJGQyA2NzQ5IHNlbnNlIG9mIOKAnGNsaWVudOKAnS4mbmJzcDsg QWdhaW4sIGlmIHdlIHdhbnQgdG8gZG8gd29yayBvbiDigJxjbGllbnQgaW5zdGFuY2Vz4oCdLCB3 ZSBuZWVkDQogdG8gcmVjaGFydGVyIGFuZCB0YWtlIHRoaXMgZGlzdGluY3Qgd29yayBpdGVtIHVw IGV4cGxpY2l0bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltQSF0gRGlzYWdyZWUuIEkg dGhpbmsgaXQgaXMgd2VsbCB3aXRoaW4gY2hhcnRlciBhbmQgaW4gZmFjdCBhIGZvdW5kYXRpb25h bCByZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPlttYmpdIEkgaW50ZXJwcmV0IHlvdXIgY29tbWVudCBhYm92ZSBhcyBwYXJ0IG9m IHlvdXIgZGVzaXJlIGZvciB0aGUgd29ya2luZyBncm91cCB0byBkZWZpbmUgT0F1dGggQ2xpZW50 IEluc3RhbmNlIE1hbmFnZW1lbnQgZnVuY3Rpb25hbGl0eS4mbmJzcDsgQWdhaW4sIHRoYXTigJlz IGJpZ2dlcg0KIHRoYW4ganVzdCByZWdpc3RyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU3VnZ2VzdCByZW5hbWUg4oCc ZXhwaXJlc19hdOKAnSB0byDigJxjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXTigJ0sJm5ic3A7PGJy Pg0KPGJyPg0KU3VnZ2VzdCB0byByZW5hbWUg4oCcaXNzdWVkX2F04oCdIHRvIOKAnGlkX2lzc3Vl ZF9hdOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSBkbyBsaWtlIHRoZSBzdWdnZXN0aW9u IG9mIGNoYW5naW5nIHRoZXNlIHRvIGNsaWVudF9zZWNyZXRfZXhwaXJlc19hdCBhbmQgY2xpZW50 X2lkX2lzc3VlZF9hdCwgYW5kIEkgdGhpbmsgdGhlc2UgYXJlIG1vcmUgY2xlYXIgYW5kIHJlYWRh YmxlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUg c3ludGF4IGR1cmluZyBsYXN0IGNhbGwgdW5sZXNzIHRoZXJlIGlzIGEgY2xlYXIgbmVlZCBhbmQg YSBjbGVhciBjb25zZW5zdXMgZm9yIGRvaW5nIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIHdoeSB3 ZSBhcmUgaGF2aW5nIGxhc3QgY2FsbC4gVG8gY29uZmlybSBjb25zZW5zdXMgb24gdGhlIGRyYWZ0 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhbWUgcmVhc29uaW5nIGFzIGVhcmxpZXIuIFlv dSBub3cgaGF2ZSBtdWx0aXBsZSB0b2tlbnMgKHJlZ2lzdHJhdGlvbiBhY2Nlc3MgYW5kIGNsaWVu dCkgaW4gcGxheS4gVGhlIHNwZWMgbmVlZHMgdG8gYmUgY2xlYXIgd2hpY2ggb25lIGl0IGlzIHRh bGtpbmcgYWJvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBmaW5l IHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgYnV0IEkgd291bGQgbGlrZSBtb3JlIGZlZWRiYWNr IGZyb20gb3RoZXIgcGVvcGxlIGJlZm9yZSBtb3ZpbmcgZm9yd2FyZCB3aXRoIGl0LiBUaGVyZSdz IGEgbG90IG9mIHZhbHVlIGluICZxdW90O2p1c3QgcGljayBhIG5hbWUgYW5kIHNoaXAgaXQmcXVv dDsgYXMgd2VsbCB0aG91Z2gsIGFuZCBJIGRvbid0IHdhbnQgdG8gZGV2b2x2ZSBpbnRvIGJpa2Ug c2hlZGRpbmcuDQogKEknbSBub3QgYWNjdXNpbmcgeW91IG9mIGJpa2Ugc2hlZGRpbmcgcXVpdGUg eWV0LCBidHcsIGp1c3QgYWZyYWlkIG9mIGdldHRpbmcgaW50byBhIGxvbmcgZGViYXRlIG9uIG5h bWVzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiwgdGhpcyB3YXMgYSBwcm9i bGVtIHJhaXNlZCBieSBwZW9wbGUgbmV3IHRvIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGV5IGZvdW5k IGl0IGNvbmZ1c2luZy4gSSB0ZW5kIHRvIGFncmVlLiBXZSdyZSBub3QgdGFsa2luZyBhYm91dCB3 aGF0IGNvbG91ciB0byBwYWludCB0aGUgc2hlZC4gV2UncmUgdGFsa2luZyBhYm91dCB3aGV0aGVy IHRoZSBiaWtlIHNoZWQgaXMgYSBob3VzZS4mbmJzcDsmbmJzcDs6LSkmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JJ20gbm90IHRvbyBmdXNzZWQgYWJvdXQgd2hldGhlciB5b3UgY2FsbCBpdCAm cXVvdDtjbF9zZWNfZXhwaXJ5JnF1b3Q7IG9yICZxdW90O2NsaWVudF9zZWNyZXRfZXhwaXJlc19h dCZxdW90Oy4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDBCMDUwIj5JZiB0aGUgZGVmaW5pdGlvbnMgb2Yg4oCcZXhwaXJlc19hdOKAnSBvciDi gJxpc3N1ZWRfYXTigJ0gYXJlIHVuY2xlYXIsIHdlIHNob3VsZCBjbGFyaWZ5IHRoZW0uJm5ic3A7 IElmIHlvdSBiZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBQaGlsLCBjYW4geW91IHN1cHBs eSBwcm9wb3NlZCBhbHRlcm5hdGl2ZQ0KIGRlZmluaXRpb24gdGV4dCB0aGF0IGlzIGNsZWFyZXI/ Jm5ic3A7IFRoYXQgYmVpbmcgc2FpZCwgSSBiZWxpZXZlIHRoYXQgYXQgdGhpcyBwb2ludCB3ZSBz aG91bGQgc3RpY2sgd2l0aCB0aGUgZXhpc3RpbmcgcHJvdG9jb2wgZWxlbWVudCBuYW1lcyB1bmxl c3Mgb3ZlcndoZWxtaW5nIHdvcmtpbmcgZ3JvdXAgc2VudGltZW50IGVtZXJnZXMgdG8gY2hhbmdl IHRoZW0uJm5ic3A7IFRoZXkgYXJlIGFscmVhZHkgd29ya2luZyBmaW5lIGFzLWlzIGluIHByb2R1 Y3Rpb24NCiBkZXBsb3ltZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bUEhdIEknbSBqdXN0IHJlcG9ydGluZyB0aGUgY29uZnVzaW9uIHBlb3BsZSBoYXZl IGhhZCB3aXRoIGFtYmlndWl0eS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TZWN0aW9uIDc8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hlbiBhIGNsaWVudF9zZWNyZXQgZXhwaXJlcyBpcyBpdCB0aGUgaW50ZW50 IHRoYXQgY2xpZW50cyBkbyBhbiB1cGRhdGUgb3IgcmVmcmVzaCB0byBnZXQgYSBuZXcgY2xpZW50 IHNlY3JldD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIGNsaWVudCBpcyBzdXBwb3NlZCB0 byBlaXRoZXIgY2FsbCB0aGUgcmVhZCBvciB1cGRhdGUgbWV0aG9kcyBvbiB0aGUgY2xpZW50IGNv bmZpZ3VyYXRpb24gZW5kcG9pbnQgdG8gZ2V0IGl0cyBuZXcgc2VjcmV0LiBBcyBkaXNjdXNzZWQg YWJvdmUsIEknbSBub3Qgc3VyZSB0aGF0J3MgYXMgY2xlYXIgYXMgaXQgbmVlZHMgdG8gYmUsIGFu ZCBJIHdlbGNvbWUgc3VnZ2VzdGlvbnMgb24gaG93IHRvIGNsYXJpZnkNCiB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5FaXRoZXIgaXMgYSByZWFzb25hYmxlIGJlaGF2aW9y IG9uIHRoZSBiZWhhbGYgb2YgY2xpZW50cywgZGVwZW5kaW5nIHVwb24gY29udGV4dC4mbmJzcDsg SSBzdXBwb3J0IGFkZGluZyB0ZXh0IHRvIGNsYXJpZnkgdGhpcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCB0aGFua3Mg Zm9yIHRoZSB2ZXJ5IHRob3JvdWdoIHJlYWQgdGhyb3VnaC4gSGF2ZSB5b3UgaW1wbGVtZW50ZWQg YW55IG9mIHRoZSBzcGVjIHlldCwgZWl0aGVyIGFzLWlzIG9yIHdpdGggYW55IG9mIHlvdXIgc3Vn Z2VzdGVkIGNoYW5nZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4g TXVjaCBvZiB0aGUgZmVlZGJhY2sgaXMgY29taW5nIGZyb20gb3VyIGRldmVsb3BtZW50IGNvbW11 bml0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWgsIHZlcnkg Y29vbC4gRGV2ZWxvcGVyIGV4cGVyaWVuY2UgaXMgdGhlIG1vc3QgdmFsdWFibGUgZmVlZGJhY2ss IGluIG15IG9waW5pb24uIElmIHlvdSBjYW4ndCBhY3R1YWxseSBidWlsZCB0aGUgYmxhc3RlZCB0 aGluZywgd2hhdCBnb29kIGlzIGl0PyA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+R2xhZCB0byBoZWFyIHRoYXQgeW914oCZcmUgd29y a2luZyB3aXRoIGRldmVsb3BlcnMgYnVpbGRpbmcgdGhlIHNwZWMuJm5ic3A7IFBsZWFzZSB0aGFu ayB0aGVtIGZvciB0aGUgZmVlZGJhY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEIwNTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBC MDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQmVzdCB3aXNoZXMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1BIXSBU aGFua3NzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B168042967394367734D79TK5EX14MBXC283r_-- From phil.hunt@oracle.com Fri May 17 18:18:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3321F8532 for ; Fri, 17 May 2013 18:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.503 X-Spam-Level: X-Spam-Status: No, score=-5.503 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJNUS1O+IsPG for ; Fri, 17 May 2013 18:18:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A408121F852D for ; Fri, 17 May 2013 18:18:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4I1Idtk024094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 May 2013 01:18:40 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4I1Idlu011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 18 May 2013 01:18:39 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4I1Ic7x011077; Sat, 18 May 2013 01:18:38 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 18:18:37 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367734CE0@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367734CE0@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2C29C8C8-8520-46F2-81C9-76837F99DA41 Content-Transfer-Encoding: 7bit Message-Id: <9DA23CF1-D172-4D79-AEE8-98F81FF3FF44@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Fri, 17 May 2013 18:18:36 -0700 To: Mike Jones X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2013 01:18:49 -0000 --Apple-Mail-2C29C8C8-8520-46F2-81C9-76837F99DA41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will spend some time next week and come up with proposals.=20 Does the group prefer a con call to work through the items or shall i post s= ection by section? Phil On 2013-05-17, at 16:33, Mike Jones wrote: > The Dynamic Client Registration spec exists to enable the developer of a p= iece of code to register that code with an Authorization Server to obtain a c= lient_id (and sometimes client_secret) so that the code can make authorizati= on requests to that AS. It enables OAuth client registrations to use standa= rd protocol interactions, rather than always using custom procedures at ever= y AS. That seems pretty valuable to me. > =20 > If you see no value in having clients anonymously registering with Authori= zation Servers to obtain client_id and client_secret values, then that impli= es that you see no value in open identity interactions in which Relying Part= ies that have not previously used an Identity Provider can dynamically conne= ct to that provider and use assertions issued by that provider. Yet I doubt= that that you really believe that. If rp.example.com hasn=E2=80=99t used i= dp.example.net before and Mary wants to use her mary@idp.example.net identit= y to sign into rp.example.com, this is exactly what=E2=80=99s needed. Maybe= you want to revise your statement about =E2=80=9Cseeing no value=E2=80=9D t= o something more pragmatic like =E2=80=9CI foresee circumstances in which it= would be valuable to manage instances of an OAuth client.=E2=80=9D? > =20 > I don=E2=80=99t see your statement about =E2=80=9Cthe new draft that does s= olve it would likely be 95% overlap=E2=80=9D as a negative =E2=80=93 rather,= I see it as you saying that the current draft already provides 95% of the f= unctionality needed for registration of client instances. The metadata fiel= d set is intentionally extensible. Rather than duplicating the 95%, I suspe= ct that the new draft that you envision would actually just define extension= s for the additional 5% functionality needed for that use case, and use the e= xisting dynamic registration specification. > =20 > Do you have a concrete proposal for what the additional 5% functionality s= hould be? Without understanding what new objects and operations that you be= lieve we would want to have for this additional functionality, the discussio= ns will remain at a hypothetical plane, at best. > =20 > I also believe that what you want us to work on is really OAuth Client Ins= tance Management functionality =E2=80=93 of which registration is only one p= art. I=E2=80=99d really like to see a concrete proposal all-up =E2=80=93 pr= eferably as an Internet Draft =E2=80=93 before we even consider doing the re= gistration piece of it. Otherwise we=E2=80=99re certain to miss things and g= et it wrong if we attempt this on a piecemeal basis. > =20 > Again, I=E2=80=99m not debating that client instance management could be v= aluable in some use cases. In fact, I=E2=80=99m sure that that=E2=80=99s th= e case. But I believe that this is a significant enough work item that it s= hould have its own draft(s) and be debated on its own merits. > =20 > We shouldn=E2=80=99t hold up the existing Dynamic Client Registration spec= for this not-written-down and speculative functionality when it=E2=80=99s a= lready been demonstrated to work well for dynamically registering clients, w= here the clients are as defined in RFC 6749. > =20 > Cheers, > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt > Sent: Friday, May 17, 2013 2:27 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Client Instances of An Application - Was: Re: Last cal= l review of draft-ietf-oauth-dyn-reg-10 > =20 > Mike, > =20 > Rather then embed comments in an extended thread, I'd like to open up a sp= ecific discussion on the objective of dyn reg. > =20 > I see limited to no value in having clients completely anonymously registe= ring and receiving tokens without any ability to correlate applications betw= een applications.=20 > =20 > Associating client_id's with known client applications to allow admins to k= now who is running what version of clients seems to be the most fundamental p= art of the reason for dynamic reg. How can you revoke access to particular c= lient app types? As Justin already talked about in his Blue Button+ scenari= o, there are often life and death situations where particular sets of client= s need to be revoked. =20 > =20 > Or put another way. I believe this will be a critical operational requirem= ent going forwards. If the spec is published as is, it will be quickly inval= idated by one that does at least partially address the problem. > =20 > We're ahead of schedule, lets talk through the requirement. > =20 > As I mentioned in my comments to the other thread. Let's say we agree not d= o this now. Well, then the new draft that does solve it would likely be 95% o= verlap. Thus I see this issue as within charter and should be solved now ra= ther then waiting for a V2 dyn reg in the next charter. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 >=20 >=20 > =20 > On 2013-05-17, at 1:08 PM, Mike Jones wrote: >=20 >=20 > Thanks for the detailed feedback, Phil. Sorry for the delayed response =E2= =80=93 I was pretty fully engaged at the European Identity Conference (where= OAuth 2.0 won the award for best new standard J). My feedback on the point= s raised is inline in green=E2=80=A6 > =20 > (Perhaps if any of you reply to this thread, you could also choose a disti= nct color for your inline replies, so that it will be easily evident who sai= d what. As it is, just the back-and-forth between Phil and Justin is alread= y very difficult to follow. Thanks.) > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Phil Hunt > Sent: Thursday, May 16, 2013 12:54 PM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 > =20 > Justin, > =20 > Thanks for the discussion. More comments below... > =20 > BTW. I'm happy to contribute text. Just want to get to some rough agreemen= t first. For example, I think we need to have a away to recognize two piece= s of software as being the same (even if self-asserted). Once defined, I ca= n put together some intro text, etc. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > =20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: > =20 > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > =20 > Phil, many thanks for the extremely thorough review! It is very useful ind= eed.=20 > =20 > My comments and responses to each point are inline.=20 > =20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: > =20 > It seems unfortunate that I have not gotten a chance to get into this leve= l of detail much earlier. But then, I guess that's what LC review is for! My= apologies for not getting many of these concerns to the WG much earlier. > =20 > Overall =20 > ----------- > I think dynamic registration is a critical part of the OAuth framework now= that we are starting to consider how individual client applications should o= perate when there is one or more deployments of a particular resource API. W= e've moved from the simple use case of a single API provider like Facebook o= r Flickr and moved on to standards based, open source based, and commercial b= ased deployments where there are multiple service endpoints and many clients= to manage. > =20 > The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec: > =20 > 1. How is a new client application recognized for the first time when dep= loyed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does ch= ange with versions? > =20 > In the general case, why is any recognition required? If you're doing thin= gs as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together c= lasses of clients (see below for more discussion on this very point). But in= general, a client is just going to show up as a new instance to the AS and g= et issued a new, unique client_id, and that's that.=20 > =20 > I think we have to define more clearly what an "instance" is. For me, ther= e are applications and there are instances of that application. It is usefu= l to understand that a client application represents a set of code that shou= ld behave in a consistent way. It seems to me the first time a new applicat= ion shows up is very different from the subsequent instances that register. = For example, after the first registration, subsequent instances don't need s= pecial review or approval to the same degree. > =20 > But without other mechanisms to tie things together, there's no way for an= authorization server to know if any client instance is tied to any other cl= ient instance. Therefore, from the perspective of an AS, the first instance o= f an application (i.e., particular configuration of a set of code) to regist= er is no different to subsequent instances of that same application. How wer= e you envisioning an AS knowing the difference between the first and subsequ= ent instances of an application, specifically? If there's an "application_id= " like you mention above, I think it raises more questions than it resolves:= Who issues the application_id, some server or the application itself? Is it= validated at all? Should it be considered secret? What happens when someone= simply steals an application_id? Does an AS have to do anything to check wi= th any other AS to see if the application_id has already been used elsewhere= ? > =20 > I do agree that a discussion of "instance vs. application" would be helpfu= l in clearing this up, I'll make a note to add text to that effect. (We had t= o do something similar for BB+) > =20 > I think it is simple enough to at least add a self generated UUID for the a= pplication ID. Though I would allow for cases where the application ID is a= ssigned when the client developer and the APIs owner do a formal assignment o= f application IDs. > =20 > In a sense this is just a lower tech way of doing it than what you describ= ed as the initial client credential in Blue Button+ where you encoded extra c= laims into the initial app credential. > =20 > What the UUID does is link multiple instances of a client app together as t= he same "thing" that should have similar heuristics/behaviours. This is ver= y useful if you want to be able to revoke access to a set of clients identif= ied by application id (or a version of that app). > =20 > While I=E2=80=99m sympathetic to the OAuth working group eventually doing w= ork on differentiating between instances of an OAuth client, I=E2=80=99ll no= te that in RFC 6749 or RFC 6750 there is no such thing as a client instance.= There are only clients, which are identified by client_id values. If we w= ant to do work on client instances, we should recharter to add this new work= as a working group deliverable. We should not try to shoehorn bits and pie= ces of it into the Dynamic Registration spec, any more than we should have t= ried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to re= gister clients as defined in RFC 6749. It=E2=80=99s not the right place to e= xtend what an OAuth client is in new ways. > =20 > 2. How are client credentials managed. Are we assuming client credentials= have a limited lifetime or rotation policy? > =20 > The intent was that client_secret could be rotated, as indicated by the ex= pires_at member of the response. If a client's secret expires, it calls the r= ead operation on the Client Configuration Endpoint (=C2=A74.2) to get its ne= w client_secret. If this is unclear in the current text (which I suspect it m= ay be after multiple refactorings), then I welcome suggestions and specific t= ext as to how to make that clear.=20 > Something like this should be in the draft. > =20 > Should this be up in the introductory text, somewhere else, or have its ow= n section? > =20 > I'm starting to think credential management is a key part of the draft. It= may be worth introducing a specific section outling the registration life-c= ycle, registration access token usage, and client token usage and bootstrapp= ing. > =20 > I think that adding a discussion on this would be fine, as it could help d= evelopers understand the workflow of registering, using, and updating regist= ered clients. > =20 > How does a client authenticate the first time and subsequent times to the r= egistration service? > =20 > This is a separate question all together, as it does not involve the clien= t_secret or client_id at all. Rather, the first time the client shows up to t= he registration service, it may either: > - Not authenticate at all (this is the true public, open registration, a= nd it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer token).= How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the s= pec, by design. > =20 > Subsequent times that the same registered client (by which we mean the sam= e instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Reg= istration Access Token that it was issued on initial registration. This is a= n OAuth 2.0 Bearer token that is unique to the client instance. > =20 > Something like this should be in the draft. > =20 > OK, the definition of the registration access token can be expanded, but I= think that the rest of it is already in there in =C2=A73. I'd welcome sugge= stions on which bits of this could be made clearer. > =20 > See the discussion on what the registration_access_token is in the thread =E2= =80=9CClient Credential Expiry and new Registration Access Token - draft-iet= f-oauth-dyn-reg-10=E2=80=9D. I will work with Justin to apply these clarifi= cations to the specification. This may go into the proposed credential mana= gement overview section discussed above. > =20 > 3. How is versioning of clients managed? Should each new version of a cli= ent require a change in client registration including possibly changing clie= nt_id and authentication credential? I don't have a strong feeling, but it i= s something that implementors should consider. > =20 > This is up to the AS, really, and I don't think that any global policy wou= ld ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding a= discussion in the security considerations if it merits mentioning though, s= o that we can help both client developers and server developers institute re= asonably good policy. > =20 > I guess the issue is that when a client upgrades it may have access to the= old credentials. What is the intent then of registration. Since you have a= n update are clients expected to update /re-register or not? I'm not sure t= his is a security consideration but more part of the whole change management= function dynamic registration supports. > =20 > If your upgraded version of the client still has access to its old credent= ials, why wouldn't it just use those? I don't see a reason for forcing a re-= registration. Nor do I see any way that an AS would even be able to tell tha= t a client had been upgraded. An upgraded client always has the *option* of r= e-registering itself and getting a new client_id.=20 > I think the concern here is that rotation of client credential is not some= thing discussed before. Before we put it in the spec we should consider the r= easons for doing it and what problems it solves. > =20 > I think this may be just a case of letting people exchange credentials for= whatever reason they feel is appropriate. The version upgrade thing sugges= ts that when a client is upgraded it should go to the registration server to= "re-register". Depending on the policy of the server, it may (or may not) r= eceive a new client_id and/or new credential. =20 > =20 > One of the best benefits I can think of is if you discover a version of a c= lient has a problem, being able to select a group of clients by software and= version is important. Thus if client_id doesn't trace to a particular softw= are and version, that makes it hard to do. I think you talked about this a= s an issue for Blue Button+ > =20 > Again, RFC 6749 defines no client instances or groups of clients, therefor= e I believe that it=E2=80=99s inappropriate to do so here. We don=E2=80=99t= need to boil the ocean. If a new charter item is approved to do work on cl= ient instances and protocol elements to use and express them, that=E2=80=99s= the time for the working group to consider that possibility =E2=80=93 not a= s part of Dynamic Client Registration. > =20 > 4. What is the registration access token? Why is is used? What is its lif= e-cycle? When is it issued, when is it changed? When is it deleted? > =20 > See the response above above and the definition in =C2=A71.2:=20 > =20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authori= zation Server through the Client Registration Endpoint which is used by the C= lient to authenticate itself during read, update, and delete operations. Thi= s token is associated with a particular Client. > =20 > If this can be clarified, I welcome text suggestions. > =20 > The latter part of 1.2 didn't seem like terminology but rather architectur= e or part of the introduction that describes what the spec does. The third p= oint doesn't seem to fit with the other two except to say that the dynamic r= egistration endpoints use their own access tokens called registration access= tokens. > =20 > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > =20 > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > =20 > o Registration Access Token: An OAuth 2.0 Bearer Token issued by the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > =20 > This section is meant to just introduce the new terms that are then explai= ned in greater detail throughout the rest of the document. Yes, it's a bit a= rchitecture, but only in the sense that you need to define the terms that ma= ke up your architecture. How would you suggest that it change? > =20 > Probably this is more a matter of style. But, what happened for me is I n= aturally skipped the terminology section, as I wasn't expecting protocol com= ponents to be there. "terminology" is something I think people tend to use a= s a dictionary rather than as protocol component description. Maybe the cha= irs can advise? > =20 > If we distinguish between first time registration of a particular client s= oftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sho= uld only have parameters for items that could change per deployment (like to= s_uri). I think token_endpoint_auth_method is one thing that should not be n= egotiated per instance. > =20 > When subsequent instances register, I have to ask the question, for exampl= e when would things like "token_endpoint_auth_method" be negotiated or be di= fferent for the same client software? Should not all instances use the same a= uthentication method. > =20 > I'm confused by this -- as far as the dynamic registration spec is concern= ed, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy of= the client code connecting to any new authorization server. That pairing cr= eates the client_id, and therefore the instance, and therefore the registrat= ion access token, and therefore the registration itself at a conceptual leve= l. So there is no way other than per-instance for a client to ask for a part= icular token_endpoint_auth_method. Where else would the AS find out about it= ? > =20 > We still disagree on this. It is my assertion that clients should NEVER as= k for a particular token auth method. Since it is the AS that is authenticat= ing the client, then it is the AS's right to set the authentication policy. = The role of dynamic reg endpoint is to inform the client what it must do. M= y assumption is that during the first time a piece of software is registered= (the first instance), there could be some OOB discussion by an administrato= r to approve the particular authentication type for the AS in question. > =20 > I haven't heard a reason justifying this parameter other then "it is neede= d". Why? > =20 > The role of the dynamic registration protocol is twofold: half of that is t= he server informing the client what it must do. But the other half is the cl= ient informing the server what it *can* do, or what it *wants* to do.=20 > =20 > And again, there's no way to distinguish a first instance from a subsequen= t instance unless you're doing something in addition. Nothing is stopping th= e same application from registering a new instance of itself for every singl= e user or every single token that it wants to get access for. That's complic= ated and wasteful and not a great idea, sure, but there's no useful way to p= revent that kind of behavior if you also want open registration of clients.=20= > =20 > I think we've discussed how recognizing subsequent instances is easily don= e. > =20 > As I mentioned in the other thread, if a developer chooses to limit the ca= pabilities of the client it must do so by looking to the developer or standa= rd behind the API. Otherwise they are taking the chance. There's no way a d= eveloper can query all the potential deployers to ask what authn types will y= ou use. As I said, the net effect in the absence of an API standard dictatin= g what should be supported, the developer will have to implement all methods= . > =20 > My point here is that none of this is helped by the client app saying what= it supports. A developer who takes the route of limiting implementation tak= es the chance that the server will not accept. So why negotiate within regi= stration? > =20 > And there's no way other than per-instance for the server to tell the clie= nt which token_endpoint_auth_method to use. All instances will probably ask f= or the same token_endpoint_auth_method from all auth servers they talk to, r= ight? And each AS will tell each instance that registers with it to use a pa= rticular auth method. There is no way to tie together different instances ac= ross (or within) auth servers without specifying a significant amount of oth= er machinery. > =20 > Which is not to say that it's not useful in some circumstances to tie toge= ther different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the i= nitial access token that the clients use to call the registration endpoint t= he first time, as well as a discovery protocol against a centralized server= that handles pre-registration. All of this machinery is, in my opinion, a s= tupendous overkill for the general case, though if some folks find use for i= t outside of BB+ then it'd be a good thing to abstract out and make its own s= pec that extends the Dyn Reg spec in a fully compatible way. Furthermore, ev= en in Blue Button+ we specify that all auth servers MUST also accept open re= gistration, without an initial access token, where the client simply shows u= p and says "hey, here are my parameters." The auth server has no way to know= in this case any kind of out-of-band negotiation for different things. In B= B+ we are writing very specific policy guidelines about how to present the U= X and things to the end user for all of these different cases. But again, al= l of this is specific to the BB+ use case, and I don't see value in dragging= it in to the registration spec on its own. I believe it would be far too li= miting. > =20 > See my previous comments on differentiating client instances being out of s= cope without rechartering to do this new work and on what the registration_a= ccess_token is. In short, the registration_access_token is an RFC 6750 bear= er token issued to the party registering the client, enabling it to subseque= ntly retrieve information about the client registration and to potentially u= pdate the registration information for that registered client. Again, I=E2= =80=99ll work with Justin to make sure that this is as clear as possible in t= he specification. > =20 > Finally, there seems to be an inconsistent style approach with draft-hardj= ono-oauth-resource-reg which uses ETags. Should this draft do so as well? > =20 > That's an individual submission, not a working group draft. Nobody has, un= til now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I persona= lly don't see their utility here, though, and I wouldn't want to include a w= holly new mechanism this late. > =20 > Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't h= ave a point. It's worth discussing.=20 > =20 > One could argue that the point of an ETag is that it is useful for change d= etection when there are multiple writers to a particular resource. In the d= esign of dynamic registration endpoint, there should only be one writer -- t= he client. This is an important observation. > =20 > There are other mechanisms that handle this -- namely, the registration ac= cess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as descr= ibed in =C2=A74.1.=20 > =20 > If everyone agrees, I'm in agreement. But it will likely mean changes for t= he resource reg draft if adopted. > =20 > ETags seem like an unnecessary addition (and potential complication) to th= e specification. It=E2=80=99s already working fine as-is. > =20 > Specific items: > --------------------- > "token_endpoint_auth_method" > =20 > There is some confusion as to whether this applies to server or client aut= hentication. Suggest renaming parameter to "token_endpoint_client_auth_meth= od" > =20 > This is the first I've heard of this particular confusion. I'm fine with e= ither name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. > =20 > The question was raised to me by some new developers. It seems obvious to u= s as experienced OAuth persons, but to new developers it seems unclear. Als= o, now that you are introducing registration authentication, the whole thing= gets very confusing. So it is useful disambiguate all the parameters where p= ossible. That said, I wouldn't mind shorter names (maybe not quite as short= as the JOSE stuff ;-) > =20 > Fair enough, but again, I only want to do syntax changes if the rest of th= e WG *really* wants to. > =20 > I agree with Justin here. I=E2=80=99m fine clarifying the description of t= his parameter to resolve the potential ambiguities that you cite, Phil. I=E2= =80=99m not OK revising the syntax without a compelling reason to do so. > =20 > * Currently, the API only supports a single value instead of an array. If= the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it sh= ould not be used. > =20 > I would rather like this to be an array, personally, and brought it up wit= h the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The IE= TF draft has inherited this decision. I *believe* (though am not 100% positi= ve) that I brought up this very issue in the WG here but didn't receive any t= raction on it, so single it remains. > =20 > I can get behind multiple values. In this case, it changes the meaning of t= he parameter. Instead of the client forcing the server to use a particular m= ethod, the client is informing the server about what methods it can perform.= This allows the server to assign the appropriate method based on its own po= licy. >=20 >=20 > Also note that this field, like all others in =C2=A72, represents two thin= gs: the client telling the server "I want to use this value for this field",= and the server telling the client "this is the value you have for this fiel= d". It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator is= nice enough to tell you what their decision was instead of just decapitatin= g you. > =20 > This is the heart of my objection. This fuzziness is is going to lead to i= nterop issues. > =20 > There is no fuzziness that I can see here. It's parallelism between what g= oes in to the endpoint and what comes out of it. The semantics for the reque= st and the response are different, and differentiable by the fact that one i= s a request and the other is a response.=20 > =20 > The inter-op issue I would like to point out is that the spec does not cur= rently specify if particular input values are singular or multiple. If an i= mplementer assumes singular and clients assume multiple, we have issues. > =20 > The multiple/single discussion above gets to the heart of what I *do* beli= eve is a deficiency in the specification, as it=E2=80=99s currently written.= The authors, myself included, have failed to make it 100% clear that disco= very of Authorization Server functionality is out of scope for this specific= ation. I strongly believe that we need to add a clear statement to this eff= ect in the introduction to the specification. > =20 > The purpose of the Dynamic Client Registration specification is for the cl= ient to register with the Authorization Server and to inform it of propertie= s of the client that the AS may want/need to be aware of. It *is not* the p= urpose of this specification for it to be used by clients in any manner to d= iscover features of the Authorization Server. That should be explicitly out= of scope. > =20 > Currently, clients are instructed by RFC 6749 to discover information abou= t Authorization Servers they interact with by consulting the =E2=80=9Cservic= e documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2). They can also le= arn information about Authorization Servers in specific contexts through dis= covery protocols such as OpenID Connect Discovery (http://openid.net/specs/o= penid-connect-discovery-1_0.html) and UMA Discovery (TBD). > =20 > I suspect that at some point, someone in the OAuth working group will prop= ose developing a generic OAuth discovery mechanism, which will lead to a rec= hartering to include this work in the working group=E2=80=99s set of deliver= ables. I would support doing this work and the necessary rechartering to do= so. > =20 > That being said, I strongly oppose trying to shoehorn piecemeal aspects of= discovery into the Dynamic Client Registration specification. It is distin= ct functionality and deserves first-class and separable treatment by the wor= king group. Discovery is for potential clients to learn properties of the A= S before registration. Registration is for potential clients to inform the A= S of its properties, creating a registered client. Discovery sends informat= ion about the AS to the Client. Registration sends information about the Cl= ient to the AS. That=E2=80=99s a clean separation. We should strongly resi= st muddying the two functions. > =20 > OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean. I= t specified how to do one thing well in a simple, web-friendly manner. We s= hould do the same =E2=80=93 focusing on specifying interoperable dynamic cli= ent registration, while making it clear that this is distinct from discovery= about Authorization Server properties, and making it clear that discovery i= s out of scope for this work. > =20 > I apologize at this point on behalf of myself and the other spec editors f= or not being 100% clear that discovery functionality is explicitly out of sc= ope for Dynamic Client Registration. If we had done so, I=E2=80=99m sure th= at many of the current questions and confusions would not have arisen. I th= ink we=E2=80=99d assumed that this was obvious, but from the current discuss= ions, it=E2=80=99s apparent that it=E2=80=99s not obvious. I will personall= y commit to clarifying the specification at this point to eliminate this pot= ential point of confusion. > =20 > Getting back to the specifics, the only useful purpose of a multi-valued =E2= =80=9Ctoken_endpoint_client_auth_method=E2=80=9D member would be to enable t= he client to discover information about the authentication methods supported= by the AS after the registration had been performed. But that is a discove= ry function, and so should be part of the discovery work =E2=80=93 not this s= pecification. We should resist shoehorning in bits of discovery into this s= pecification. It *is* a worthwhile topic, but deserves full consideration b= y the working group in its own right. Therefore, this member must remain si= ngle-valued, and be clearly specified as the method by which a client inform= s the AS which token endpoint authentication method it will use. Anything e= lse would be scope creep, and result in an unnecessarily complicated specifi= cation and unnecessarily complicated clients. > =20 > * There is no authn method for "client_secret_saml" or "private_key_saml".= > =20 > Nobody has really asked that these two be included or specified. The exten= sion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use?= > =20 > I think this is coming from the fact that there is a JWT bearer draft and a= SAML bearer draft. The truth is you are defining an authentication that is= n't even defined. > =20 > There are no profiles referenced or defined for "client_secret_jwt" or "pr= ivate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover th= ese types of flows. They only cover bearer flows. "client_secret_jwt" and "= private_key_jwt" seem to have some meaning within OpenID Connect, but I note= that OIDC does not fully define these either. > =20 > The JWT assertion draft does say how to use a JWT for client authenticatio= n, and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymme= trically. > =20 > Actually my interpretation is the JWT draft assumes the JWT Bearer is a be= arer token. The assumption is that if a client has the assertion it has the= right to present it. IOW. The JWT Bearer Draft is most definitively not a J= WT HoK Draft. :-) > =20 > Regardless, you are introducing a new profile which is undefined. > =20 > I think I see the point that you're making now, let me try to re-state it:= > =20 > While the basics of "how to present a JWT as a client credential" is defin= ed here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.se= ction.2.2 , it's not completely specified in that it doesn't fully restrict t= he signature secret source, the audience claim, and other things that the AS= would need to check and validate. Right? The dynamic registration draft can= define those cases in greater detail if needed (though I think it does so s= ufficiently as-is, I welcome more clarity). > =20 > I'd be OK with adding the SAML bit, going into greater detail on the JWT b= its, or dropping the JWT bits, if the WG wants to do any of those actions. M= y objection is that the JWT stuff is already in use and functioning and it'd= be a shame to leave it out. > =20 > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors mad= e is they assumed everyone had the same definition of bearer token. To me a= bearer token opaque to the client. It therefore cannot do any signature wor= k with regards to the token itself. Now, that's not to say a proof didn't o= ccur between the client and the token issuer, but when the client wields the= token, it is handling an opaque string. > =20 > The concept of client_secret_jwt suggests an HoK profile. Therefore of co= urse the bearer drafts are a little underspecified when it comes to HoK prof= iles. > =20 > So for example, you need a draft like the MAC draft for this.=20 > =20 > I'm having trouble overall here. It seems the authn types suggest ONLY str= ong authentication for clients, yet during the registration process the curr= ent draft isn't able to correlate multiple instances of the same software (e= ven in a self-asserted way). If you haven't authenticated the software at a= ll, why have strong client auth? > =20 > There is no authentication method defined for "client_bearer_saml" or "cli= ent_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is a= cceptable, the dynamic registration spec should accept these. > =20 > I don't understand this bit -- where are these defined in RFC6750? I don't= even know what client_bearer_ref would refer to. > =20 > 6750 says you can use a bearer assertion (e.g. obtained from an IDP) and w= ield it as an authentication assertion. The client is NOT creating or modif= ying the assertion. The client is simply passing one it previously obtained.= > =20 > What you are describing is not bearer. It is holder of key. Very very diff= erent.=20 >=20 >=20 > A possible suggestion is to remove client_secret_jwt and private_key_jwt a= nd define those as register extensions since these profiles are not defined.= > =20 > That's possible, but they are in active use already.=20 > =20 > That may be true. But then you need to write another draft so the rest of u= s can implement it in an interoperable way. Me I prefer not to guess what y= ou are doing. > =20 > This much I agree with. > =20 > Justin, John, and I discussed this issue and agree with your suggestion, P= hil. Since they are not completely specified, we will remove the client_sec= ret_jwt and private_key_jwt methods from the specification and add a registr= y, enabling specification that do fully specify these and other token endpoi= nt authentication methods, including potential methods using SAML assertions= , to register them in the registry, rather than trying to bake them into the= Dynamic Client Registration specification. > =20 > About "tos_uri" and "policy_uri" > =20 > The distinction between tos_uri and policy_uri is unclear. Can we clarify= or combine them? > =20 > Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a st= atement of what the service provider (in this case, the client) will do. Mor= e importantly, we used to have only one, and several people asked for them t= o be split. > =20 > Several developers were confused by this. In particular they couldn't figu= re out which was used for what. Just passing along the feedback. > =20 > OK, the distinction that I see is that the TOS is contractual, the Policy i= s a statement. Re-reading the definitions in there right now, that can be ma= de much clearer. (It even looks like some OIDC text leaked into the definiti= on of policy_uri and that hadn't been caught yet.) > =20 > I support clarifying the language on these definitions, and will work with= Justin to do so. > =20 > Also, aren't these really URIs or are they meant to be URLs? > =20 > There was already discussion about this on the list: The IETF is apparentl= y trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically i= ncorrect in following the new policy. And it makes the IESG less mad at us, w= hich is a plus. > =20 > Arg. Nice. Then the text should say the value passed must resolve to a va= lid web page, document, whatever. > =20 > That's fair, and it's something that the AS can even check if it wants to.= > =20 > Agreed on this clarification. > =20 > About "jwks_uri" > =20 > A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-09 is needed.=20 > =20 > Yes, you're correct, I'll add that. > =20 > Should be URL instead of URI? > =20 > See above. :) > =20 > Agreed on adding this reference. > =20 > Section 2.1 > =20 > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > is missing. > =20 > It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80= =A6 ? > ' > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > =20 > Ah, that makes more sense. If the WG wants to add in SAML support to paral= lel the JWT support, I'd be OK with that. > =20 > =E2=80=9CAs such, a server supporting these fields SHOULD take steps to en= sure that a client cannot register itself into an inconsistent state.=E2=80=9D= >=20 > We may want to define more detailed HTTP error response. E.g. 400 status c= ode + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)? > =20 > I'd be fine with defining a more explicit error state in this case. I thin= k it would help interop for the servers that want to enforce grant-type and r= esponse-type restrictions, but servers that can't or don't care about restri= cting grants types and whatnot don't have to do anything special. > =20 > I *think* that this goes away with the deletion of client_secret_jwt and p= rivate_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a consiste= ncy check and verify that when the spec is updated accordingly. > =20 > Section 2.2 > =20 > May want to add: > =20 > When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_= name#en=E2=80=9D) the OAuth server may use interpret the language used based= on server configuration or heuristics. > =20 > That seems inconsistent with what we already have: > =20 > If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or script= of the string value, and the string value MUST be used as-is wherever it is= presented in a user interface. > =20 > Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. > =20 > I will discuss with our developers. I'm not sure the as-is works. =20 > =20 > Is it the intent that when the client has localized "client_name" for exam= ple, it should pass all language variations in a JSON array? > =20 > Or, should part of the registration be to indicate which interface languag= e the client wishes to use? Then it only passes a single value for that reg= istration? > =20 > =20 > No, the client should pass parameters as multiple separate values. Connect= has this in its example: > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The languag= e tags are a late addition, so the examples don't reflect it.) > =20 > An example would definitely help. > If the client passes only a single unadorned field, the AS can't make any a= ssumption about what language it is. Think of this as the internationalized v= alue of the field while the language tags are the localized versions of the f= ield. This is why we recommend that the bare-value always be sent by the cl= ient, so that in the lack of anything more specific, the AS can at least do *= something* with it. > =20 > Passing in a "default" language field (like default_locale or the like) is= only going to lead to pain for implementors of both clients and servers, an= d it's going to hurt the interoperability of the human-readable fields.=20 > =20 > I think what I meant is since you are allowing each client to register dif= ferent things, AND the client likely already knows the user's preferred lang= uage, why wouldn't the client just pass text values in one language and anot= her parameter indicating preferred language in the case of any service gener= ated text. > =20 > Is the reason you are passing multiple localizations is so that you can us= e the preferred language of the resource owner rather then the client user? I= wonder if that is correct. If the language preferences are in fact differe= nt, what would the user of the client app expect? > =20 > ----> any multi-lingual people have any opinions here? > =20 > Without specific proposed text changes to review, it=E2=80=99s hard to kno= w what to think about this comment. Unless a specific proposed text change i= s sent to the list with clear rationale for why it=E2=80=99s better than wha= t=E2=80=99s there now and reviewed by the working group, I don=E2=80=99t bel= ieve we should change the specification in response to this comment. > =20 > Section 3 > =20 > Existing text: >=20 > =E2=80=9CIn order to support open registration and facilitate wider intero= perability, the Client Registration Endpoint SHOULD allow initial registrati= on requests with no authentication. These requests MAY be rate-limited or o= therwise limited to prevent a denial-of-service attack on the Client Registr= ation Endpoint.=E2=80=9D >=20 > I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CM= AY=E2=80=9D. In most cloud services, the first client is registered by a h= uman user. Then, other clients can be further used to automate other client r= egistration. So, the first request would typically come with an authenticat= ed user identity.=20 > =20 > I think the weight of "SHOULD" is appropriate here, because I believe that= turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule.=20 > =20 > I think you are reading it wrong -- a double-negative issue. The end of th= e sentence is "no authentication". You are implying that NO Authentication u= s what should normally be done. I think you intend anonymous authentication t= o be the exception rather than the rule don't you? > =20 > No, I think that anonymous authentication should be the rule. Open registr= ation should be default.=20 > =20 > I disagree. Again, the spec seems contradictory. It suggests strong clie= nt auth methods and at the same time anonymous registration. Yes you gain u= niqueness, but that's about it. >=20 > On the flip side, the earlier paragraph: >=20 > =E2=80=9CThe Client Registration Endpoint MAY accept an initial authorizat= ion credential in the form of an OAuth 2.0 [RFC6749] access token in order t= o limit registration to only previously authorized parties. The method by wh= ich this access token is obtained by the registrant is generally out-of-band= and is out of scope of this specification.=E2=80=9D >=20 > I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D to= =E2=80=9CSHOULD=E2=80=9D. >=20 > That access token would carry a human user authenticated identity somehow.= In some cases, it can be a pure authenticated user assertion token. > =20 > Again, disagree, for the same reasoning as above. > =20 > Same reasoning.=20 >=20 >=20 > I agree with Justin here. The default should be that open registrations a= re enabled. The exception case is that specific permissions are required to= perform dynamic client registration. >=20 > About section 4.3: > =20 > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used to > make this request SHOULD be immediately revoked. > =20 > If the Client does not exist on this server, shouldn't it return a "404 No= t Found"? >=20 > If revoking the registration access token, is it bound to a single client r= egistration? This is not clear. What is the lifecycle around registration a= ccess token? Only hint is in the Client Information Response in section 5.1.= > =20 > The language about the 401 here (and in other nearby sections) is specific= ally so that you treat a missing client and a bad registration access token t= he same way. You see, returning a 404 here actually indicates things were in= an inconsistent state. Namely, that the registration access token was still= valid but the client that the registration access token was attached to doe= sn't exist anymore. The registration access token in meant to be tied to a c= lient's instance (or registration), so it's actually more sensible to act as= though the registration access token isn't valid anymore. In at least some i= mplementations (specifically ours at MITRE that's built on SECOAUTH in Java)= , you'd never be able to reach the 404 state due to consistency checking wit= h the inbound token. > =20 > Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at t= he issuance of a new client_id with that instance. That token might be revok= ed and a new one issued on Read and Update requests to the Client Configurat= ion Endpoint (and the client needs to be prepared for that -- same as the cl= ient_secret), and it will be revoked when the client is deleted either with a= Delete call to the Client Configuration Endpoint or something happening out= -of-band to kill the client.=20 > =20 > Should we add more explanatory text to the definition in the terminology s= ection? Elsewhere? I'm very open to concrete suggestions with this, since I d= on't think it's as clear as we'd like. > =20 > I think we should look at it. >=20 >=20 > For security reasons, it=E2=80=99s generally not good to distinguish betwe= en =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors in r= esponses, as that can provide the attacker an oracle to probe whether a part= icular entity exists I don=E2=80=99t think a change is called for here. >=20 > About section 5.1: > Is registration_access_token unique? Or is it shared by multiple instance= s? If shared, then registration_access_token can't be revoked on delete of= client. > =20 > The registration_access_token is unique to a registered client, in the RFC= 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do work on =E2= =80=9Cclient instances=E2=80=9D, we need to recharter and take this distinct= work item up explicitly. >=20 > Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_expi= res_at=E2=80=9D,=20 >=20 > Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2=80= =9D > =20 > While I do like the suggestion of changing these to client_secret_expires_= at and client_id_issued_at, and I think these are more clear and readable, >=20 >=20 >=20 > I don't want to change the syntax during last call unless there is a clear= need and a clear consensus for doing so. > =20 > That's why we are having last call. To confirm consensus on the draft.=20 > =20 > Same reasoning as earlier. You now have multiple tokens (registration acce= ss and client) in play. The spec needs to be clear which one it is talking a= bout. > =20 > I'm fine with the suggested change but I would like more feedback from oth= er people before moving forward with it. There's a lot of value in "just pic= k a name and ship it" as well though, and I don't want to devolve into bike s= hedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid o= f getting into a long debate on names.) > =20 > Again, this was a problem raised by people new to the specification. They f= ound it confusing. I tend to agree. We're not talking about what colour to p= aint the shed. We're talking about whether the bike shed is a house. :-)=20= > =20 > I'm not too fussed about whether you call it "cl_sec_expiry" or "client_se= cret_expires_at".=20 >=20 >=20 > If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2= =80=9D are unclear, we should clarify them. If you believe that this is the= case Phil, can you supply proposed alternative definition text that is clea= rer? That being said, I believe that at this point we should stick with the= existing protocol element names unless overwhelming working group sentiment= emerges to change them. They are already working fine as-is in production = deployments. > =20 > Section 7 > =20 > When a client_secret expires is it the intent that clients do an update or= refresh to get a new client secret? > =20 > Yes, the client is supposed to either call the read or update methods on t= he client configuration endpoint to get its new secret. As discussed above, I= 'm not sure that's as clear as it needs to be, and I welcome suggestions on h= ow to clarify this. > =20 > Either is a reasonable behavior on the behalf of clients, depending upon c= ontext. I support adding text to clarify this. > =20 > Again, thanks for the very thorough read through. Have you implemented any= of the spec yet, either as-is or with any of your suggested changes? > =20 > Yes. Much of the feedback is coming from our development community.=20 > =20 > Ah, very cool. Developer experience is the most valuable feedback, in my o= pinion. If you can't actually build the blasted thing, what good is it? :) > =20 > Glad to hear that you=E2=80=99re working with developers building the spec= . Please thank them for the feedback. > =20 > -- Justin > =20 > Best wishes, > -- Mike > =20 --Apple-Mail-2C29C8C8-8520-46F2-81C9-76837F99DA41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I will spend some time next week and c= ome up with proposals. 

Does the group prefer a= con call to work through the items or shall i post section by section?
<= br>Phil

On 2013-05-17, at 16:33, Mike Jones <Michael.Jones@microsoft.com> wrote:<= br>

The Dynamic Client Registra= tion spec exists to enable the developer of a piece of code to register that= code with an Authorization Server to obtain a client_id (and sometimes client_secret) so that the code can make authorization reque= sts to that AS.  It enables OAuth client registrations to use standard p= rotocol interactions, rather than always using custom procedures at every AS= .  That seems pretty valuable to me.

 

If you see no value in havi= ng clients anonymously registering with Authorization Servers to obtain clie= nt_id and client_secret values, then that implies that you see no value in open identity interactions in which Relying Parties tha= t have not previously used an Identity Provider can dynamically connect to t= hat provider and use assertions issued by that provider.  Yet I doubt t= hat that you really believe that.  If rp.example.com hasn=E2=80=99t used= idp.example.net before and Mary want= s to use her mary@idp.example.net identity to sign into rp.example.com= , this is exactly what=E2=80=99s needed.  Maybe you want to revise your= statement about =E2=80=9Cseeing no value=E2=80=9D to something more pragmat= ic like =E2=80=9CI foresee circumstances in which it would be valuable to mana= ge instances of an OAuth client.=E2=80=9D?

 

I don=E2=80=99t see your st= atement about =E2=80=9Cthe new draft that does solve it would likely b= e 95% overlap=E2=80=9D as a negative =E2=80=93 rather, I see it as you saying that the current dra= ft already provides 95% of the functionality needed for registration of clie= nt instances.  The metadata field set is intentionally extensible. = ; Rather than duplicating the 95%, I suspect that the new draft that you envision would actually just define extensions for t= he additional 5% functionality needed for that use case, and use the existin= g dynamic registration specification.

 

Do you have a concrete prop= osal for what the additional 5% functionality should be?  Without under= standing what new objects and operations that you believe we would want to have for this additional functionality, the discussions wi= ll remain at a hypothetical plane, at best.

 

I also believe that what yo= u want us to work on is really OAuth Client Instance Management functionalit= y =E2=80=93 of which registration is only one part.  I=E2=80=99d really= like to see a concrete proposal all-up =E2=80=93 preferably as an Internet D= raft =E2=80=93 before we even consider doing the registration piece of it.&n= bsp; Otherwise we=E2=80=99re certain to miss things and get it wrong if we a= ttempt this on a piecemeal basis.

 

Again, I=E2=80=99m not deba= ting that client instance management could be valuable in some use cases.&nb= sp; In fact, I=E2=80=99m sure that that=E2=80=99s the case.  But I beli= eve that this is a significant enough work item that it should have its own draft(s) and b= e debated on its own merits.

 

We shouldn=E2=80=99t hold u= p the existing Dynamic Client Registration spec for this not-written-down an= d speculative functionality when it=E2=80=99s already been demonstrated to work well for dynamically registering clients, where the clients are as d= efined in RFC 6749.

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;    Cheers,

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 17, 2013 2:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Client Instances of An Application - Was: Re: Las= t call review of draft-ietf-oauth-dyn-reg-10

 

Mike,

 

Rather then embed comments in an extended thread, I'd= like to open up a specific discussion on the objective of dyn reg.

 

I see limited to no value in having clients completel= y anonymously registering and receiving tokens without any ability to correl= ate applications between applications. 

 

Associating client_id's with known client application= s to allow admins to know who is running what version of clients seems to be= the most fundamental part of the reason for dynamic reg. How can you revoke= access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, t= here are often life and death situations where particular sets of clients ne= ed to be revoked.  

 

Or put another way. I believe this will be a critical= operational requirement going forwards. If the spec is published as is, it w= ill be quickly invalidated by one that does at least partially address the p= roblem.

 

We're ahead of schedule, lets talk through the requir= ement.

 

As I mentioned in my comments to the other thread. Le= t's say we agree not do this now. Well, then the new draft that does solve i= t would likely be 95% overlap.  Thus I see this issue as within charter= and should be solved now rather then waiting for a V2 dyn reg in the next charter.

 

 



 

On 2013-05-17, at 1:08 PM, Mike Jones wrote:



Thanks for the detailed fee= dback, Phil.  Sorry for the delayed response =E2=80=93 I was pretty ful= ly engaged at the European Identity Conference (where OA= uth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green=E2=80=A6=

 

(Perhaps if any of you repl= y to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what. = As it is, just the back-and-forth between Phil and Justin is already very d= ifficult to follow.  Thanks.)

 

From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] = On Behalf Of Phil Hunt Sent: Thursday, May= 16, 2013 12:54 PM
To: Richer, Justin P= .
Cc: oauth@ietf.org&= nbsp;WG
Subject: Re: [OAUTH= -WG] Last call review of draft-ietf-oauth-dyn-reg-10

 

Justin,

 

Thanks for the discussion. More comments below...

 

BTW. I'm happy to contribute text. Just want to get t= o some rough agreement first.  For example, I think we need to have a a= way to recognize two pieces of software as being the same (even if self-asse= rted).  Once defined, I can put together some intro text, etc.

 

 

On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:

 

On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>

 wrote:

 

On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:

 

Phil, many thanks for the extremely thorough review! I= t is very useful indeed. 

 

My comments and responses to each point are inline.&n= bsp;

 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=

 

It seems unfortunate that I have not gotten a chance t= o get into this level of detail much earlier. But then, I guess that's what L= C review is for! My apologies for not getting many of these concerns to the W= G much earlier.

 

Overall  

-----------

I think dynamic registration is a critical part of th= e OAuth framework now that we are starting to consider how individual client= applications should operate when there is one or more deployments of a part= icular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr a= nd moved on to standards based, open source based, and commercial based depl= oyments where there are multiple service endpoints and many clients to manag= e.

 

The dynamic registration spec is actually dealing wit= h a couple of issues that I would like to see made more clear in early part o= f the spec:

 

1.  How is a new client application recognized f= or the first time when deployed against a particular SP endpoint?  Shou= ld clients actually assert an application_id UUID that never changes and pos= sibly a version id that does change with versions?

 

In the general case, why is any recognition required?= If you're doing things as part of a larger protocol ecosystem, like Blue Bu= tton+ or a particular OpenID Connect provider, then you can define semantics= for tying together classes of clients (see below for more discussion on this very point). But in general,= a client is just going to show up as a new instance to the AS and get issue= d a new, unique client_id, and that's that. 

 

I think we have to define more clearly what an "insta= nce" is. For me, there are applications and there are instances of that appl= ication.  It is useful to understand that a client application represen= ts a set of code that should behave in a consistent way.  It seems to me the first time a new application s= hows up is very different from the subsequent instances that register. For e= xample, after the first registration, subsequent instances don't need specia= l review or approval to the same degree.

 

But without other mechanisms to tie things together, t= here's no way for an authorization server to know if any client instance is t= ied to any other client instance. Therefore, from the perspective of an AS, t= he first instance of an application (i.e., particular configuration of a set of code) to register is no differe= nt to subsequent instances of that same application. How were you envisionin= g an AS knowing the difference between the first and subsequent instances of= an application, specifically? If there's an "application_id" like you mention above, I think it raises mo= re questions than it resolves: Who issues the application_id, some server or= the application itself? Is it validated at all? Should it be considered sec= ret? What happens when someone simply steals an application_id? Does an AS have to do anything to check wi= th any other AS to see if the application_id has already been used elsewhere= ?

 

I do agree that a discussion of "instance vs. applica= tion" would be helpful in clearing this up, I'll make a note to add text to t= hat effect. (We had to do something similar for BB+)

 

I think it is simple enough to at least add a self ge= nerated UUID for the application ID.  Though I would allow for cases wh= ere the application ID is assigned when the client developer and the APIs ow= ner do a formal assignment of application IDs.

 

In a sense this is just a lower tech way of doing it t= han what you described as the initial client credential in Blue Button+ wher= e you encoded extra claims into the initial app credential.

 

What the UUID does is link multiple instances of a cl= ient app together as the same "thing" that should have similar heuristics/be= haviours.  This is very useful if you want to be able to revoke access t= o a set of clients identified by application id (or a version of that app).

 

While I=E2=80=99m sympathet= ic to the OAuth working group eventually doing work on differentiating betwe= en instances of an OAuth client, I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only c= lients, which are identified by client_id values.  If we want to do wor= k on client instances, we should recharter to add this new work as a working= group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any m= ore than we should have tried to shoehorn it into RFC 6749 or RFC 6750. = ; Oauth-dyn-reg is there to register clients as defined in RFC 6749.  I= t=E2=80=99s not the right place to extend what an OAuth client is in new ways.

 

2.  How are client credentials managed. Are we a= ssuming client credentials have a limited lifetime or rotation policy?<= /o:p>

 

The intent was that client_secret could be rotated, a= s indicated by the expires_at member of the response. If a client's secret e= xpires, it calls the read operation on the Client Configuration Endpoint (=C2= =A74.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after mul= tiple refactorings), then I welcome suggestions and specific text as to how t= o make that clear. 

Something like this should be in the draft.

 

Should this be up in the introductory text, somewhere= else, or have its own section?

 

I'm starting to think credential management is a key p= art of the draft. It may be worth introducing a specific section outling the= registration life-cycle, registration access token usage, and client token u= sage and bootstrapping.

 

I think that adding a discu= ssion on this would be fine, as it could help developers understand the work= flow of registering, using, and updating registered clients.

 

How does a client authenticate the first time and sub= sequent times to the registration service?

 

This is a separate question all together, as it does n= ot involve the client_secret or client_id at all. Rather, the first time the= client shows up to the registration service, it may either:

  - Not authenticate at all (this is the true pu= blic, open registration, and it is recommended that servers do this)

 - Authenticate using an OAuth 2.0 token (which A= TM means a bearer token). How the client gets that bearer token and what the= bearer token means to the AS beyond "this client is authorized to register"= is out of scope for the spec, by design.

 

Subsequent times that the same registered client (by w= hich we mean the same instance of a client with a particular client_id) show= s up at the registration endpoint (actually, the Client Configuration Endpoi= nt), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2= .0 Bearer token that is unique to the client instance.

 

Something like this should be in the draft.

 

OK, the definition of the registration access token c= an be expanded, but I think that the rest of it is already in there in =C2=A7= 3. I'd welcome suggestions on which bits of this could be made clearer.=

 

See the discussion on what t= he registration_access_token is in the thread =E2=80=9CClient Credential Exp= iry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D= .  I will work with Justin to apply these clarifications to the specification.=   This may go into the proposed credential management overview section d= iscussed above.

 

3.  How is versioning of clients managed? Should= each new version of a client require a change in client registration includ= ing possibly changing client_id and authentication credential? I don't have a= strong feeling, but it is something that implementors should consider.

 

This is up to the AS, really, and I don't think that a= ny global policy would ever fly here. Especially if you consider that the en= tire notion of "version" is more fluid these days than it ever has been. I w= ouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we c= an help both client developers and server developers institute reasonably go= od policy.

 

I guess the issue is that when a client upgrades it m= ay have access to the old credentials. What is the intent then of registrati= on.  Since you have an update are clients expected to update /re-regist= er or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic= registration supports.

 

If your upgraded version of the client still has acce= ss to its old credentials, why wouldn't it just use those? I don't see a rea= son for forcing a re-registration. Nor do I see any way that an AS would eve= n be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registe= ring itself and getting a new client_id. 

I think the concern here is that rotation of client c= redential is not something discussed before. Before we put it in the spec we= should consider the reasons for doing it and what problems it solves.<= /o:p>

 

I think this may be just a case of letting people exc= hange credentials for whatever reason they feel is appropriate.  The ve= rsion upgrade thing suggests that when a client is upgraded it should go to t= he registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a n= ew client_id and/or new credential.  

 

One of the best benefits I can think of is if you dis= cover a version of a client has a problem, being able to select a group of c= lients by software and version is important. Thus if client_id doesn't trace= to a particular software and version, that makes it hard to do.  I  think you talked about this as an i= ssue for Blue Button+

 

Again, RFC 6749 defines no c= lient instances or groups of clients, therefore I believe that it=E2=80=99s i= nappropriate to do so here.  We don=E2=80=99t need to boil the ocean.&n= bsp; If a new charter item is approved to do work on client instances and protoc= ol elements to use and express them, that=E2=80=99s the time for the working= group to consider that possibility =E2=80=93 not as part of Dynamic Client R= egistration.

 

4.  What is the registration access token? Why i= s is used? What is its life-cycle?  When is it issued, when is it chang= ed? When is it deleted?

 

See the response above above and the definition in =C2= =A71.2: 

 

Registration Access Token: An OAuth 2.0 Bearer Token i= ssued by the Authorization Server through the Client Registration Endpoint w= hich is used by the Client to authenticate itself during read, update, and d= elete operations. This token is associated with a particular Client.

 

If this can be clarified, I welcome text suggestions.=

 

The latter part of 1.2 didn't seem like terminology b= ut rather architecture or part of the introduction that describes what the s= pec does. The third point doesn't seem to fit with the other two except to s= ay that the dynamic registration endpoints use their own access tokens called registration access tokens.

 

Client Registr=
ation Endpoint: The OAuth 2.0 Endpoint through which
= 
      a Client can request new regist=
ration.  The means of the Client
      obtaining the URL for this endp=
oint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2=
.0 Endpoint through
      which a specific Client can man=
age its registration information,
      provided by the Authorization S=
erver to the Client.  This URL for
      this endpoint is communicated t=
o the client by the Authorization
      Server in the Client Informatio=
n Response.
 
   o  Registration Access Token: An OAuth 2.0 B=
earer Token issued by the
      Authorization Server through th=
e Client Registration Endpoint
      which is used by the Client to a=
uthenticate itself during read,
      update, and delete operations.&=
nbsp; This token is associated with a
      particular Client.<=
/o:p>

 

This section is meant to just introduce the new terms= that are then explained in greater detail throughout the rest of the docume= nt. Yes, it's a bit architecture, but only in the sense that you need to def= ine the terms that make up your architecture. How would you suggest that it change?

 

Probably this is more a matter of style.  But, w= hat happened for me is I naturally skipped the terminology section, as I was= n't expecting protocol components to be there.  "terminology" is someth= ing I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can a= dvise?

 

If we distinguish between first time registration of a= particular client software package, it is possible that somethings like aut= hentication method can be negotiate in or out-of-band at that time. Subseque= nt registrations should only have parameters for items that could change per deployment (like tos_uri).  = ;I think token_endpoint_auth_method is one thing that should not be negotiat= ed per instance.

 

When subsequent instances register, I have to ask the= question, for example when would things like "token_endpoint_auth_method" b= e negotiated or be different for the same client software? Should not all in= stances use the same authentication method.

 

I'm confused by this -- as far as the dynamic registr= ation spec is concerned, all instances are separate from each other. All par= ameters change per instance. And instance, you should keep in mind, is defin= ed as any one copy of the client code connecting to any new authorization server. That pairing creates the c= lient_id, and therefore the instance, and therefore the registration access t= oken, and therefore the registration itself at a conceptual level. So there i= s no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else= would the AS find out about it?

 

We still disagree on this. It is my assertion that cl= ients should NEVER ask for a particular token auth method. Since it is the A= S that is authenticating the client, then it is the AS's right to set the au= thentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My a= ssumption is that during the first time a piece of software is registered (t= he first instance), there could be some OOB discussion by an administrator t= o approve the particular authentication type for the AS in question.

 

I haven't heard a reason justifying this parameter ot= her then "it is needed".  Why?

 

The role of the dynamic registration protocol is twof= old: half of that is the server informing the client what it must do. But th= e other half is the client informing the server what it *can* do, or what it= *wants* to do. 

 

And again, there's no way to distinguish a first inst= ance from a subsequent instance unless you're doing something in addition. N= othing is stopping the same application from registering a new instance of i= tself for every single user or every single token that it wants to get access for. That's complicated and w= asteful and not a great idea, sure, but  there's no useful way to preve= nt that kind of behavior if you also want open registration of clients. = ;

 

I think we've discussed how recognizing subsequent in= stances is easily done.

 

As I mentioned in the other thread, if a developer ch= ooses to limit the capabilities of the client it must do so by looking to th= e developer or standard behind the API.  Otherwise they are taking the c= hance.  There's no way a developer can query all the potential deployers to ask what authn types will you use.= As I said, the net effect in the absence of an API standard dictating what s= hould be supported, the developer will have to implement all methods.

 

My point here is that none of this is helped by the c= lient app saying what it supports. A developer who takes the route of limiti= ng implementation takes the chance that the server will not accept.  So= why negotiate within registration?

 

And there's no way other than per-instance for the se= rver to tell the client which token_endpoint_auth_method to use. All instanc= es will probably ask for the same token_endpoint_auth_method from all auth s= ervers they talk to, right? And each AS will tell each instance that registers with it to use a particular a= uth method. There is no way to tie together different instances across (or w= ithin) auth servers without specifying a significant amount of other machine= ry.

 

Which is not to say that it's not useful in some circumstances to tie togeth= er different instances of the same code across (or within) auth servers. Thi= s is why, with Blue Button+, we specified a specific token format for the in= itial access token that the clients use to call the registration endpoint the first time,  as well as a di= scovery protocol against a centralized server that handles pre-registration.= All of this machinery is, in my opinion, a stupendous overkill for the gene= ral case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and mak= e its own spec that extends the Dyn Reg spec in a fully compatible way. Furt= hermore, even in Blue Button+ we specify that all auth servers MUST also acc= ept open registration, without an initial access token, where the client simply shows up and says "hey, he= re are my parameters." The auth server has no way to know in this case any k= ind of out-of-band negotiation for different things. In BB+ we are writing v= ery specific policy guidelines about how to present the UX and things to the end user for all of these dif= ferent cases. But again, all of this is specific to the BB+ use case, and I d= on't see value in dragging it in to the registration spec on its own. I beli= eve it would be far too limiting.

 

See my previous comments on= differentiating client instances being out of scope without rechartering to= do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer tok= en issued to the party registering the client, enabling it to subsequently r= etrieve information about the client registration and to potentially update t= he registration information for that registered client.  Again, I=E2=80=99ll work with Justin to make sure t= hat this is as clear as possible in the specification.

=

 

Finally, there seems to be an inconsistent style appr= oach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?

 

That's an individual submission, not a working group d= raft. Nobody has, until now, even mentioned the use of ETags here. UMA (wher= e the resource registration draft comes from) uses ETags, hence their inclus= ion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new= mechanism this late.

 

Yes. Thomas' draft is not a WG document. But that doe= sn't mean he doesn't have a point. It's worth discussing. 

 

One could argue that the point of an ETag is that it i= s useful for change detection when there are multiple writers to a particula= r resource.  In the design of dynamic registration endpoint, there shou= ld only be one writer -- the client. This is an important observation.

 

There are other mechanisms that handle this -- namely= , the registration access token and the client_id. Many instances include th= e client_id in some form in the client configuration endpoint's URL for sani= ty checking, as described in =C2=A74.1. 

 

If everyone agrees, I'm in agreement. But it will lik= ely mean changes for the resource reg draft if adopted.

 

ETags seem like an unnecess= ary addition (and potential complication) to the specification.  It=E2=80= =99s already working fine as-is.

 

Specific items:

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

"token_endpoint_auth_method"

 

There is some confusion as to whether this applies to= server or client authentication.  Suggest renaming parameter to "token= _endpoint_client_auth_method"

 

This is the first I've heard of this particular confu= sion. I'm fine with either name but at this stage I don't want to make synta= x changes without very, very compelling reasons to do so.

 

The question was raised to me by some new developers.= It seems obvious to us as experienced OAuth persons, but to new developers i= t seems unclear.  Also, now that you are introducing registration authe= ntication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible. &= nbsp;That said, I wouldn't mind shorter names (maybe not quite as short as t= he JOSE stuff ;-)

 

Fair enough, but again, I only want to do syntax chan= ges if the rest of the WG *really* wants to.

 

I agree with Justin here.&n= bsp; I=E2=80=99m fine clarifying the description of this parameter to resolv= e the potential ambiguities that you cite, Phil.  I=E2=80=99m not OK re= vising the syntax without a compelling reason to do so.

 

* Currently, the API only supports a single value ins= tead of an array.  If the purpose is to allow the client to know what a= uth methods it supports, this should be an array indicated what methods the c= lient supports - or it should not be used.

 

I would rather like this to be an array, personally, a= nd brought it up with the OpenID Connect working group about six months ago.= But there it was decided that a single value was simpler and sufficient for= the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I b= rought up this very issue in the WG here but didn't receive any traction on i= t, so single it remains.

 

I can get behind multiple values. In this case, it ch= anges the meaning of the parameter. Instead of the client forcing the server= to use a particular method, the client is informing the server about what m= ethods it can perform. This allows the server to assign the appropriate method based on its own policy.


Also note that this field, like all others in =C2=A72= , represents two things: the client telling the server "I want to use this v= alue for this field", and the server telling the client "this is the value y= ou have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator wh= o has the last word anyway. But at least this dictator is nice enough to tel= l you what their decision was instead of just decapitating you.

 

This is the heart of my objection. This fuzziness is i= s going to lead to interop issues.

 

There is no fuzziness that I can see here. It's paral= lelism between what goes in to the endpoint and what comes out of it. The se= mantics for the request and the response are different, and differentiable b= y the fact that one is a request and the other is a response. 

 

The inter-op issue I would like to point out is that t= he spec does not currently specify if particular input values are singular o= r multiple.  If an implementer assumes singular and clients assume mult= iple, we have issues.

 

The multiple/single discuss= ion above gets to the heart of what I *do* believe is a deficiency in= the specification, as it=E2=80=99s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Author= ization Server functionality is out of scope for this specification.  I= strongly believe that we need to add a clear statement to this effect in th= e introduction to the specification.

 

The purpose of the Dynamic C= lient Registration specification is for the client to register with the Auth= orization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* t= he purpose of this specification for it to be used by clients in any manner t= o discover features of the Authorization Server.  That should be explic= itly out of scope.

 

Currently, clients are inst= ructed by RFC 6749 to discover information about Authorization Servers they i= nteract with by consulting the =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections= 3.1 and 3.2).  They can also learn information about Authorization Ser= vers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-c= onnect-discovery-1_0.html) and UMA Discovery (TBD).

 

I suspect that at some poin= t, someone in the OAuth working group will propose developing a generic OAut= h discovery mechanism, which will lead to a rechartering to include this work in the working group=E2=80=99s set of deliverables.&nb= sp; I would support doing this work and the necessary rechartering to do so.=

 

That being said, I strongly= oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic C= lient Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group. = ; Discovery is for potential clients to learn properties of the AS before re= gistration.  Registration is for potential clients to inform the AS of i= ts properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration s= ends information about the Client to the AS.  That=E2=80=99s a clean se= paration.  We should strongly resist muddying the two functions.=

 

OAuth 2.0 is a success beca= use it didn=E2=80=99t try to boil the ocean.  It specified how to do on= e thing well in a simple, web-friendly manner.  We should do the same =E2=80=93 focusing on specifying interoperable dynamic client registration,= while making it clear that this is distinct from discovery about Authorizat= ion Server properties, and making it clear that discovery is out of scope fo= r this work.

 

I apologize at this point o= n behalf of myself and the other spec editors for not being 100% clear that d= iscovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I=E2=80=99m sure that= many of the current questions and confusions would not have arisen.  I= think we=E2=80=99d assumed that this was obvious, but from the current disc= ussions, it=E2=80=99s apparent that it=E2=80=99s not obvious.  I will p= ersonally commit to clarifying the specification at this point to eliminate this pote= ntial point of confusion.

 

Getting back to the specifi= cs, the only useful purpose of a multi-valued =E2=80=9Ctoken_endpoint= _client_auth_method=E2=80=9D member would be to enable the client to discover information about the auth= entication methods supported by the AS after the registration had been perfo= rmed.  But that is a discovery function, and so should be part of the d= iscovery work =E2=80=93 not this specification.  We should resist shoehorning in bits of discovery into this specification.&= nbsp; It *is* a worthwhile topic, but deserves full consideration by t= he working group in its own right.  Therefore, this member must remain s= ingle-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authent= ication method it will use.  Anything else would be scope creep, and re= sult in an unnecessarily complicated specification and unnecessarily complic= ated clients.

 

* There is no authn method for "client_secret_saml" o= r "private_key_saml".

 

Nobody has really asked that these two be included or= specified. The extension mechanism (using an absolute URI) would allow some= one else to define these. Is the definition in the SAML Assertion draft suff= icient for their use?

 

I think this is coming from the fact that there is a J= WT bearer draft and a SAML bearer draft.  The truth is you are defining= an authentication that isn't even defined.

 

There are no profiles referenced or defined for "c= lient_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer dr= afts referenced cover these types of flows. They only cover bearer flows. &n= bsp;"client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does n= ot fully define these either.

 

The JWT assertion draft does say how to use a JWT for= client authentication, and the DynReg text differentiates between a client s= igning said JWT with its own secret symmetrically vs. a client using its own= private key, asymmetrically.

 

Actually my interpretation is the JWT draft assumes t= he JWT Bearer is a bearer token.  The assumption is that if a client ha= s the assertion it has the right to present it.  IOW. The JWT Bearer Dr= aft is most definitively not a JWT HoK Draft.  :-)

 

Regardless, you are introducing a new profile which i= s undefined.

 

I think I see the point that you're making now, let m= e try to re-state it:

 

While the basics of "how to present a JWT as a client= credential" is defined here: http://tools.ietf.org/id/dra= ft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signatu= re secret source, the audience claim, and other things that the AS would nee= d to check and validate. Right? The dynamic registration draft can define th= ose cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarit= y).

 

I'd be OK with adding the SAML bit, going into greate= r detail on the JWT bits, or dropping the JWT bits, if the WG wants to do an= y of those actions. My objection is that the JWT stuff is already in use and= functioning and it'd be a shame to leave it out.

 

I guess then the mistake the JWT Bearer and SAML Bear= er drafts authors made is they assumed everyone had the same definition of b= earer token.  To me a bearer token opaque to the client. It therefore c= annot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur betw= een the client and the token issuer, but when the client wields the token, i= t is handling an opaque string.

 

The concept of client_secret_jwt suggests an HoK prof= ile.  Therefore of course the bearer drafts are a little underspecified= when it comes to HoK profiles.

 

So for example, you need a draft like the MAC draft f= or this. 

 

I'm having trouble overall here. It seems the authn t= ypes suggest ONLY strong authentication for clients, yet during the registra= tion process the current draft isn't able to correlate multiple instances of= the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have stro= ng client auth?

 

There is no authentication method defined for "client= _bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the= bearer specs say this is acceptable,  the dynamic registration spec sh= ould accept these.

 

I don't understand this bit -- where are these define= d in RFC6750? I don't even know what client_bearer_ref would refer to.<= /o:p>

 

6750 says you can use a bearer assertion (e.g. obtain= ed from an IDP) and wield it as an authentication assertion.  The clien= t is NOT creating or modifying the assertion. The client is simply passing o= ne it previously obtained.

 

What you are describing is not bearer. It is holder o= f key. Very very different. 


A possible suggestion is to remove client_secret_jwt a= nd private_key_jwt and define those as register extensions since these profi= les are not defined.

 

That's possible, but they are in active use already.&= nbsp;

 

That may be true. But then you need to write another d= raft so the rest of us can implement it in an interoperable way.  Me I p= refer not to guess what you are doing.

 

This much I agree with.

 

Justin, John, and I discuss= ed this issue and agree with your suggestion, Phil.  Since they are not= completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enab= ling specification that do fully specify these and other token endpoint auth= entication methods, including potential methods using SAML assertions, to re= gister them in the registry, rather than trying to bake them into the Dynamic Client Registration specif= ication.

 

About "tos_uri" and "policy_uri"

 

The distinction between tos_uri and policy_uri is unc= lear.  Can we clarify or combine them?

 

Terms of service and policy are two different documen= ts. One is something that a user accepts (generally describing what the user= will do), one is a statement of what the service provider (in this case, th= e client) will do. More importantly, we used to have only one, and several people asked for them to be split.

 

Several developers were confused by this. In particul= ar they couldn't figure out which was used for what.  Just passing alon= g the feedback.

 

OK, the distinction that I see is that the TOS is con= tractual, the Policy is a statement. Re-reading the definitions in there rig= ht now, that can be made much clearer. (It even looks like some OIDC text le= aked into the definition of policy_uri and that hadn't been caught yet.)

 

I support clarifying the la= nguage on these definitions, and will work with Justin to do so.=

 

Also, aren't these really URIs or are they meant to b= e URLs?

 

There was already discussion about this on the list: T= he IETF is apparently trying to deprecate URL in favor of URI in new specs. S= o in practice they'll nearly always be URLs, but since all URLs are URIs we'= re not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is= a plus.

 

Arg. Nice.  Then the text should say the value p= assed must resolve to a valid web page, document, whatever.

 

That's fair, and it's something that the AS can even c= heck if it wants to.

 

Agreed on this clarificatio= n.

 

About "jwks_uri"

 

A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09=  is needed. 

 

Yes, you're correct, I'll add that.

 

Should be URL instead of URI?

 

See above. :)

 

Agreed on adding this refer= ence.

 

Section 2.1

 

In the table urn:ietf:p= arams:oauth:grant-type:jwt-bearer

is missing.

 

It's there in the copy of -10 I'm reading off of i= etf.org right now =E2=80= =A6 ?

'

Sorry I meant: = urn:ietf= :params:oauth:grant-type:saml-bearer

 

Ah, that makes more sense. If the WG wants to add in S= AML support to parallel the JWT support, I'd be OK with that.

=

 

=E2=80=9CAs such, a server supporting these fields SH= OULD take steps to ensure that a client cannot register itself into an i= nconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 statu= s code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?

 

I'd be fine with defining a more explicit error state= in this case. I think it would help interop for the servers that want to en= force grant-type and response-type restrictions, but servers that can't or d= on't care about restricting grants types and whatnot don't have to do anything special.

 

I *think* that this g= oes away with the deletion of client_secret_jwt and private_key_jwt in favor= of the registry=E2=80=A6  I=E2=80=99ll do a consistency check and veri= fy that when the spec is updated accordingly.

 

Section 2.2=

 

May want to add:

 

When =E2=80=9C#=E2=80=9D language tag is missing= , (e.g. =E2=80=9C#en=E2=80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, i= nstead of =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use in= terpret the language used based on server configuration or heurist= ics.

 

That seems inconsistent with what we already have:

 

If any human-readable field is sent without a languag= e tag, parties using it MUST NOT make any assumptions about the language, ch= aracter set, or script of the string value, and the string value MUST be use= d as-is wherever it is presented in a user interface.

 

Which is to say, treat it as a raw byte-value-string a= nd don't try to get fancy.

 

I will discuss with our developers. I'm not sure the a= s-is works.  

 

Is it the intent that when the client has localized "= client_name" for example, it should pass all language variations in a JSON a= rray?

 

Or, should part of the registration be to indicate wh= ich interface language the client wishes to use?  Then it only passes a= single value for that registration?

 

 

No, the client should pass parameters as multiple sep= arate values. Connect has this in its example:

 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":<=
/o:p>
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=
=E3=83=88=E5=90=8D",

Should we add that to at least one of the examples in= DynReg? (The language tags are a late addition, so the examples don't refle= ct it.)

 

An example would definitely help.

If the client passes only a single unadorned field, t= he AS can't make any assumption about what language it is. Think of this as t= he internationalized value of the field while the language tags are the loca= lized versions of the field. This is why we recommend that the bare-value always be sent by the client, so th= at in the lack of anything more specific, the AS can at least do *something*= with it.

 

Passing in a "default" language field (like default_l= ocale or the like) is only going to lead to pain for implementors of both cl= ients and servers, and it's going to hurt the interoperability of the human-= readable fields. 

 

I think what I meant is since you are allowing each c= lient to register different things, AND the client likely already knows the u= ser's preferred language, why wouldn't the client just pass text values in o= ne language and another parameter indicating preferred language in the case of any service generated text.

 

Is the reason you are passing multiple localizations i= s so that you can use the preferred language of the resource owner rather th= en the client user? I wonder if that is correct.  If the language prefe= rences are in fact different, what would the user of the client app expect?

 

----> any multi-lingual people have any opinions h= ere?

 

Without specific proposed t= ext changes to review, it=E2=80=99s hard to know what to think about this co= mment.  Unless a specific proposed text change is sent to the list with clear rationale for why it=E2=80=99s better than what=E2=80=99s t= here now and reviewed by the working group, I don=E2=80=99t believe we shoul= d change the specification in response to this comment.

 

Section 3

 

Existing text:

=E2=80=9CIn order to support open registration and facilitate wider int= eroperability, the Client Registration Endpoint SHOULD allow initi= al registration requests with no authentication.  These r= equests MAY be rate-limited or otherwise limited to prevent a denial-of= -service attack on the Client Registration Endpoint.=E2=80=9D

I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY= =E2=80=9D.   In most cloud services, the first client is regi= stered by a human user. Then, other clients can be further used to auto= mate other client registration.  So, the first request w= ould typically come with an authenticated user identity. 

 

I think the weight of "SHOULD" is appropriate here, b= ecause I believe that turning off open registration at the AS (which is what= this is talking about) really ought to be the exception rather than the rul= e. 

 

I think you are reading it wrong -- a double-negative= issue. The end of the sentence is "no authentication".  You are implyi= ng that NO Authentication us what should normally be done. I think you inten= d anonymous authentication to be the exception rather than the rule don't you?

 

No, I think that anonymous authentication should be t= he rule. Open registration should be default. 

 

I disagree.  Again,  the spec seems contrad= ictory. It suggests strong client auth methods and at the same time anonymou= s registration.  Yes you gain uniqueness, but that's about it.


On the flip side, the earlier paragraph:

=E2=80=9CThe Client Registration Endpoint MAY accept an initial au= thorization credential in the form of an OAuth 2.0 [RFC6749] access tok= en in order to limit registration to only previously authorized pa= rties. The method by which this access token is obtained by the registr= ant is generally out-of-band and is out of scope of this specification.=E2=80=9D=

I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D to =E2= =80=9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity someh= ow. In some cases, it can be a pure authenticated user assertion token.=

 

Again, disagree, for the same reasoning as above.

 

Same reasoning. 


I agree with Justin here.&n= bsp; The default should be that open registrations are enabled.  The ex= ception case is that specific permissions are required to perform dynamic client registration.


About section 4.3:

 

If the client does not exist on this server, the server MUST r=
espond
   with HTTP 401 Unauthorized, and the Registration A=
ccess Token used to
   make this request SHOULD be immediately revoked.<=
/span>

 

If the Client does not exist on this server, sho= uldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client re= gistration?  This is not clear.  What is the lifecycle around regi= stration access token? Only hint is in the Client Information Response in se= ction 5.1.

 

The language about the 401 here (and in other nearby s= ections) is specifically so that you treat a missing client and a bad regist= ration access token the same way. You see, returning a 404 here actuall= y indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the c= lient that the registration access token was attached to doesn't exist anymo= re. The registration access token in meant to be tied to a client's instance= (or registration), so it's actually more sensible to act as though the registration access token isn't valid an= ymore. In at least some implementations (specifically ours at MITRE that's b= uilt on SECOAUTH in Java), you'd never be able to reach the 404 state due to= consistency checking with the inbound token.

 

Since the intent of the registration access token is t= hat it's bound to a single instance, its lifecycle is generally tied to the l= ifecycle begins at the issuance of a new client_id with that instance. That t= oken might be revoked and a new one issued on Read and Update requests to the Client Configuration Endp= oint (and the client needs to be prepared for that -- same as the client_sec= ret), and it will be revoked when the client is deleted either with a Delete= call to the Client Configuration Endpoint or something happening out-of-band to kill the client. <= /o:p>

 

Should we add more explanatory text to the definition= in the terminology section? Elsewhere? I'm very open to concrete suggestion= s with this, since I don't think it's as clear as we'd like.

 

I think we should look at it.


For security reasons, it=E2= =80=99s generally not good to distinguish between =E2=80=9Cnot found=E2=80=9D= and =E2=80=9Cunauthorized=E2=80=9D errors in responses, as that can provide= the attacker an oracle to probe whether a particular entity exists  I don=E2=80=99t th= ink a change is called for here.


About section 5.1:

Is registration_access_token unique?  Or is it s= hared by multiple instances?   If shared, then registration_access_toke= n can't be revoked on delete of client.

 

The registration_access_tok= en is unique to a registered client, in the RFC 6749 sense of =E2=80=9Cclien= t=E2=80=9D.  Again, if we want to do work on =E2=80=9Cclient instances=E2= =80=9D, we need to recharter and take this distinct work item up explicitly.


Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_expire= s_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2=80= =9D

 

While I do like the suggestion of changing these to c= lient_secret_expires_at and client_id_issued_at, and I think these are more c= lear and readable,




I don't want to change the syntax during last call un= less there is a clear need and a clear consensus for doing so.

 

That's why we are having last call. To confirm consen= sus on the draft. 

 

Same reasoning as earlier. You now have multiple toke= ns (registration access and client) in play. The spec needs to be clear whic= h one it is talking about.

 

I'm fine with the suggested change but I would like m= ore feedback from other people before moving forward with it. There's a lot o= f value in "just pick a name and ship it" as well though, and I don't want t= o devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getti= ng into a long debate on names.)

 

Again, this was a problem raised by people new to the= specification. They found it confusing. I tend to agree. We're not talking a= bout what colour to paint the shed. We're talking about whether the bike she= d is a house.  :-) 

 

I'm not too fussed about whether you call it "cl_sec_= expiry" or "client_secret_expires_at". 


If the definitions of =E2=80= =9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2=80=9D are unclear, we should= clarify them.  If you believe that this is the case Phil, can you supp= ly proposed alternative definition text that is clearer?  That being said, I believe that at t= his point we should stick with the existing protocol element names unless ov= erwhelming working group sentiment emerges to change them.  They are al= ready working fine as-is in production deployments.

 

Section 7

 

When a client_secret expires is it the intent that cl= ients do an update or refresh to get a new client secret?

 

Yes, the client is supposed to either call the read o= r update methods on the client configuration endpoint to get its new secret.= As discussed above, I'm not sure that's as clear as it needs to be, and I w= elcome suggestions on how to clarify this.

 

Either is a reasonable beha= vior on the behalf of clients, depending upon context.  I support addin= g text to clarify this.

 

Again, thanks for the very thorough read through. Hav= e you implemented any of the spec yet, either as-is or with any of your sugg= ested changes?

 

Yes. Much of the feedback is coming from our developm= ent community. 

 

Ah, very cool. Developer experience is the most valua= ble feedback, in my opinion. If you can't actually build the blasted thing, w= hat good is it? :)

 

Glad to hear that you=E2=80= =99re working with developers building the spec.  Please thank them for= the feedback.

 

 -- Justin

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;    Best wishes,

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

 

= --Apple-Mail-2C29C8C8-8520-46F2-81C9-76837F99DA41-- From ve7jtb@ve7jtb.com Fri May 17 23:56:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3E21F8FA5 for ; Fri, 17 May 2013 23:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-ycKQIznmtj for ; Fri, 17 May 2013 23:56:25 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C436921F8F69 for ; Fri, 17 May 2013 23:56:24 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q57so3851689wes.37 for ; Fri, 17 May 2013 23:56:23 -0700 (PDT) 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=A4mgXV6vLDX7gQWW+0DUP3IeOFuISwVZ9wdOWt/lYCY=; b=mvSHtIOQ56K19A2Jr84fnRS3kSK2rYSDgWt3DOBaf81+HJZd4zoEiH7UZsqjg5EJbh LiJQK+qVVhYIETdZiggOPhpFOlMcUIkG6Vv8qzVly+SON1G3YpIJlOhbCtDX9F6v+tJ/ sS5ITHM6k6bB+4+oOUB9jqCPXafFMiRpp9TqM//Kyk10QUoF7zQdSU1QXGvHPjjb+PVb 1aGrVKwIajni/XmLUWLNhj32MpNrxcMniHbb8ux/grG26PzyEd1YemUKa21eQR3MfOsK DdzUS4MOJNhMjh3Vrw4XREExTIoKPhtDBksljymaGP3owXsatVRx17Se2OdWoB3KwSKy UBJA== X-Received: by 10.194.249.164 with SMTP id yv4mr4110249wjc.40.1368860183674; Fri, 17 May 2013 23:56:23 -0700 (PDT) Received: from [10.121.233.103] ([195.50.165.102]) by mx.google.com with ESMTPSA id fu14sm892714wic.8.2013.05.17.23.56.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 23:56:22 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CB6834D3-76DA-427D-B296-65626C981117"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> Date: Sat, 18 May 2013 08:56:05 +0200 Message-Id: <6BB36AB9-F2D3-4C40-AD7A-C6B4A979FAFF@ve7jtb.com> References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmQojItFjt8tb4pyAuJpz50VR8JMo5V15OCSHt7hhYaaagbV9cIrxpoxyv1dRwxy+Kl0F8U Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2013 06:56:26 -0000 --Apple-Mail=_CB6834D3-76DA-427D-B296-65626C981117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom what I have seen deployed, there are four common flows for = registration. 1 2 developer uses a tool to register a client ID and place that in the = client code for deployment of a native App that is distributed via an = app store for a 3rd party API. The developer may later need to make = changes to the registration as they develop the client and add = functionality without changing the client_id which would effectively = invalidate all user consent as consent is by client_id. 2 A client such as a web server (Think SAML SP) has a user turn up and = identify themselves via a email address that be de-refrenced by say web = finger to find a service for the API the client knows about and wants = permission to access. The client learns the registration endpoint and = registers itself for a client_id at the endpoint and can then do OAuth 2 = autherization with the AS for the user. 3 A client such as a web server wants to connect to a new AS. They try = 2 but get an error for dynamic registration indicating they need a = credential to register. A admin is notified and goes to some AS portal = for developers and register an account perhaps validating a email and = phone number for contact as well as agreeing to the AS's terms of = service. They then receive an access token for the registration = endpoint that they cut and paste into there app to do the actual = registration. =20 4 A client such as a web server wants to connect to a new AS. They try = 2 but get an error for dynamic registration indicating they need a = credential to register. A admin is notified and goes to some AS portal = for developers and register an account perhaps validating a email and = phone number for contact as well as agreeing to the AS's terms of = service. The developer must then enter all there redirect URI keys and = other configuration info manually into a form. Then gets another form = or email with a key and client_id that they use to configure the app. = If the client secret expires they must use there developer account to = login and get a new client secret. This is what we are trying to = automate with dynamic client registration. 5 In a version of 3 the developer may be registering a client class with = certain constraints that override the dynamic registration of the class. = They then get back the "Registration Access Token" and put that in a = native app to be distributed. The native app may then create its own = keypair unique to that instance and proceed to register itself and get a = per instance client_id (but bound to the class at the AS) this would = allow a native app to be confidential( Some might see that as a good = thing). The native app then uses the new "Registration Access Token" = it is granted to manage its settings. The original API developer based on there developer credentials that = generated the original or class "Registration Access Token" could manage = the class including revoking it. This higher level class management = design is allowed by the current spec but needs another spec to flesh it = out. This is perhaps part of the 5% you are looking for. The "Registration Access Token" is for a different resource than what = ever the actual API is. It is also not a client secret password and = may have much higher entropy as it is a token and not subject to = limitations of http basic implementations. The initial "Registration = Access Token" manages a class (might only be one entity in the class) it = is an access token so can have scopes. A possibility for 5 would be = something like crate, update and read. In 5 the token would only have = create. The second "Registration Access Token" that is instance = specific would have more rights but only for its instance client_id. = In the design there are two "Registration Access Token" that are = separate form client credentials at the token endpoint because they are = possibly used by different entities for operations on different subjects = in the registration API. It is possible that in an extension we could = allow for the developer portal to provide access tokens with perhaps a = delete scope for the class rather than the instance if that is perhaps = one of the things you are looking for. =20 I think the higher level management of classes of clients deserves it's = own profile. We need to ensure we are not blocking it with what we are = doing in dynamic registration. John B. On 2013-05-18, at 1:29 AM, Phil Hunt wrote: > John, >=20 > Thanks for jumping in. >=20 > 1. I do buy the implied argument that some client credential types do = expire (eg. bearer assertions). Therefore the expiry issue has to be = dealt with. I would prefer to handle this by allowing an exception = whereby expired assertions could be used to re-register (only). This = shouldn't be a big security issue since we're talking about an expired = client refreshing with its issuer rather then a third party trusting an = expired token.=20 >=20 > I just don't think adding another token, the registration access = token, that in turn (by your argument) should expire, actually helps. = It just adds another layer to the problem and increases complexity. It = solves nothing. >=20 > 2. You seem to be describing a different usage than Justin is. The = way he explains the draft, there is no developer cycle at all. He's = saying every client gets a registration token and a client token. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-17, at 10:40 AM, John Bradley wrote: >=20 >> 1 No reasonable security profile is going to let you use the same = symmetric password over long time periods. It will be brute forced = given enough time. =20 >> The rotation time will depend on entropy and the rate an attacker can = submit attempts. I would expect profiles to look at SP-800-63 for = guidance as essentially a password for the client. >>=20 >> 2 the registration interface is likely used by a developer who = probably doesn't want the client instances (say native clients) to be = able to update the configuration directly. using the client secret = credential for updates would break the separation. Registration my be = done by the client itself or by a developer as a separate process. >>=20 >> John B. >>=20 >> On 2013-05-17, at 7:27 PM, Phil Hunt wrote: >>=20 >>> Justin, >>>=20 >>> Your reason was you copied connect. Ok. I was looking for a = technical reason. A security reason. >>>=20 >>> BTW. Mike Jones says expiry wasn't the reason. =20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-17, at 9:01 AM, Justin Richer wrote: >>>=20 >>>> The separation between these two is necessary: Not all clients have = client_secret, and you want the lifecycle/management of the registration = to be protected. This is what the registration access token was made = for. In older versions of Connect's registration, the client_secret was = forced on all clients in order to provide this, but then you had public = clients with a client_secret that they couldn't use to get tokens, and = it was a bad disconnect. >>>>=20 >>>> The requirement for client secrets to expire or otherwise be = rotated by the server came from several implementors in the Connect WG. = There's an easy way to indicate that they don't expire, and a fairly = straightforward way for them to be rotated (client does a GET on its = client configuration endpoint url, with its registration access token as = auth). >>>>=20 >>>> -- Justin >>>>=20 >>>> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>>>> All, >>>>>=20 >>>>> In the dynamic registration draft, a new token type is defined = called the "registration access token". Its use is intended to = facilitate clients being able to update their registration and obtain = new client credentials over time. The client credential is issued on = completion of the initial registration request by a particular client = instance. >>>>>=20 >>>>> It appears the need for the registration access token arises from = the implied assertion that client credentials should expire. >>>>> --> Is anyone expiring client credentials? >>>>>=20 >>>>> To date, we haven't had much discussion about client credential = expiry. It leads me to the following questions: >>>>>=20 >>>>> 1. Is there technical value with client credential/token expiry? = Keep in mind that client credential is only used with the token endpoint = over TLS connection. It is NOT used to access resources directly. >>>>>=20 >>>>> 2. If yes, on what basis should client credential/token expire? >>>>> a. Time? >>>>> b. A change to the client software (e.g. version update)? >>>>> c. Some other reason? >>>>>=20 >>>>> 3. Is it worth the complication to create a new token type = (registration access token) just to allow clients to obtain new client = tokens? Keep in mind that client tokens are only usable with the AS = token endpoint. Why not instead use a client token for dyn reg and = token endpoint with the rule that once a client token has expired (if = they expire), an expired token may still be used at the registration = end-point. >>>>>=20 >>>>> 4. Are there other reasons for the registration token? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_CB6834D3-76DA-427D-B296-65626C981117 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE4MDY1NjEwWjAjBgkqhkiG9w0BCQQxFgQU9X4xugrM vUYxNUJ/IuZyZOsr8UUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEArrWXa91fBQhHZ/Bq95Ul6qmFcN7gvPbWvb4h6scM /EtBDQey1cY2dQOKQjpZjSaqCde1xMGbK1FmnFlCbLJ9D7fqDOBqgsxznj0Oawfh3KwDsr7xQpF4 UZSgduxFkBihv+5Uh58tR1ifINZbrF21MRcOF7QCipYCrsycB0ZQalElzNr2h+qj5ufNysmxUv+x 7aYIxQ6Hf2Ajxa4W21GOod6IFmp63sChaU2vcUQh3yHg3WfjeqzeUzkjUokYqb/a9kYyOTtkiLv+ BPfesvYU5ahM8WXpLQJ5yL9LorPAC+NUSyxxPXJnA8jKGmL4BFZYy73uUHL1uaMK3YJtbvHKYQAA AAAAAA== --Apple-Mail=_CB6834D3-76DA-427D-B296-65626C981117-- From ve7jtb@ve7jtb.com Sat May 18 00:07:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2221F93EB for ; Sat, 18 May 2013 00:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-YxkyMBFOoz for ; Sat, 18 May 2013 00:07:45 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id A9CBB21F93B1 for ; Sat, 18 May 2013 00:07:44 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so4022915wgg.9 for ; Sat, 18 May 2013 00:07:43 -0700 (PDT) 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=HSvOXGxvKoF1SVjOYCKdYWCHrdz/7dKfvTngljdWXJ4=; b=EYZsPg7TG0RxDZ7yWKRUwJqShTgWO9Ter7y+FhInZBMDGgXknqk7DlP9+acHVH40OF k7HPDvCy1TNZewqRgeQbhLbEoo1xVD91Uwua7VZtfJ/dzbcxNUjAvKyn40RtWvTqodIW WgM1lJrP/3TZ5pBbRbPY1hTmnU08pXxUqNCcb5VXXt8zo2w530KQ16gOUKhAql+2MuI7 GfdsfRQsC/yY7Hj3ZAsik8ByTOIgx5mZiZ2XWuLcrY2IPLBLCWSWCDlgh6SNPoLXBM8a Wkjb7DlKFy/WF5tHtZdegdjgNDOov1Cj7lTxYo9xqEEiRf975Gh5OOZkXaQ7/PAx5ZVY xjLw== X-Received: by 10.194.86.37 with SMTP id m5mr4157614wjz.37.1368860863566; Sat, 18 May 2013 00:07:43 -0700 (PDT) Received: from [10.121.233.103] ([195.50.165.102]) by mx.google.com with ESMTPSA id h8sm935308wiz.9.2013.05.18.00.06.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 May 2013 00:07:42 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_002B8E34-42AF-4FA2-90C7-669C6F77B53F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> Date: Sat, 18 May 2013 09:06:50 +0200 Message-Id: References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQknjq7K7uFW8b52sj8kIOVLrssXmQrkSED3E6wN/4Pqx3hSZZ/yt3k3x+itoFTaQTukXxHw Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2013 07:07:46 -0000 --Apple-Mail=_002B8E34-42AF-4FA2-90C7-669C6F77B53F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom what I have seen deployed, there are four common flows for = registration. 1 2 developer uses a tool to register a client ID and place that in the = client code for deployment of a native App that is distributed via an = app store for a 3rd party API. The developer may later need to make = changes to the registration as they develop the client and add = functionality without changing the client_id which would effectively = invalidate all user consent as consent is by client_id. 2 A client such as a web server (Think SAML SP) has a user turn up and = identify themselves via a email address that be de-refrenced by say web = finger to find a service for the API the client knows about and wants = permission to access. The client learns the registration endpoint and = registers itself for a client_id at the endpoint and can then do OAuth 2 = autherization with the AS for the user. 3 A client such as a web server wants to connect to a new AS. They try = 2 but get an error for dynamic registration indicating they need a = credential to register. A admin is notified and goes to some AS portal = for developers and register an account perhaps validating a email and = phone number for contact as well as agreeing to the AS's terms of = service. They then receive an access token for the registration = endpoint that they cut and paste into there app to do the actual = registration. =20 4 A client such as a web server wants to connect to a new AS. They try = 2 but get an error for dynamic registration indicating they need a = credential to register. A admin is notified and goes to some AS portal = for developers and register an account perhaps validating a email and = phone number for contact as well as agreeing to the AS's terms of = service. The developer must then enter all there redirect URI keys and = other configuration info manually into a form. Then gets another form or = email with a key and client_id that they use to configure the app. If = the client secret expires they must use there developer account to login = and get a new client secret. This is what we are trying to automate = with dynamic client registration. Uncommon but needed: In a version of 3 the developer may be registering = a client class with certain constraints that override the dynamic = registration of the class. They then get back the "Registration Access = Token" and put that in a native app to be distributed. The native app = may then create its own keypair unique to that instance and proceed to = register itself and get a per instance client_id (but bound to the class = at the AS) this would allow a native app to be confidential( Some might = see that as a good thing). The native app then uses the new = "Registration Access Token" it is granted to manage its settings. The original API developer based on there developer credentials that = generated the original or class "Registration Access Token" could manage = the class including revoking it. This higher level class management = design is allowed by the current spec but needs another spec to flesh it = out. This is perhaps part of the 5% you are looking for. The "Registration Access Token" is for a different resource than what = ever the actual API is. It is also not a client secret password and = may have much higher entropy as it is a token and not subject to = limitations of http basic implementations. The initial "Registration = Access Token" manages a class (might only be one entity in the class) it = is an access token so can have scopes. A possibility for 5 would be = something like crate, update and read. In 5 the token would only have = create. The second "Registration Access Token" that is instance = specific would have more rights but only for its instance client_id. = In the design there are two "Registration Access Token" that are = separate form client credentials at the token endpoint because they are = possibly used by different entities for operations on different subjects = in the registration API. It is possible that in an extension we could = allow for the developer portal to provide access tokens with perhaps a = delete scope for the class rather than the instance if that is perhaps = one of the things you are looking for. =20 I think the higher level management of classes of clients deserves it's = own profile. We need to ensure we are not blocking it with what we are = doing in dynamic registration. John B. On 2013-05-18, at 1:29 AM, Phil Hunt wrote: > John, >=20 > Thanks for jumping in. >=20 > 1. I do buy the implied argument that some client credential types do = expire (eg. bearer assertions). Therefore the expiry issue has to be = dealt with. I would prefer to handle this by allowing an exception = whereby expired assertions could be used to re-register (only). This = shouldn't be a big security issue since we're talking about an expired = client refreshing with its issuer rather then a third party trusting an = expired token.=20 >=20 > I just don't think adding another token, the registration access = token, that in turn (by your argument) should expire, actually helps. = It just adds another layer to the problem and increases complexity. It = solves nothing. >=20 > 2. You seem to be describing a different usage than Justin is. The = way he explains the draft, there is no developer cycle at all. He's = saying every client gets a registration token and a client token. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-17, at 10:40 AM, John Bradley wrote: >=20 >> 1 No reasonable security profile is going to let you use the same = symmetric password over long time periods. It will be brute forced = given enough time. =20 >> The rotation time will depend on entropy and the rate an attacker can = submit attempts. I would expect profiles to look at SP-800-63 for = guidance as essentially a password for the client. >>=20 >> 2 the registration interface is likely used by a developer who = probably doesn't want the client instances (say native clients) to be = able to update the configuration directly. using the client secret = credential for updates would break the separation. Registration my be = done by the client itself or by a developer as a separate process. >>=20 >> John B. >>=20 >> On 2013-05-17, at 7:27 PM, Phil Hunt wrote: >>=20 >>> Justin, >>>=20 >>> Your reason was you copied connect. Ok. I was looking for a = technical reason. A security reason. >>>=20 >>> BTW. Mike Jones says expiry wasn't the reason. =20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-05-17, at 9:01 AM, Justin Richer wrote: >>>=20 >>>> The separation between these two is necessary: Not all clients have = client_secret, and you want the lifecycle/management of the registration = to be protected. This is what the registration access token was made = for. In older versions of Connect's registration, the client_secret was = forced on all clients in order to provide this, but then you had public = clients with a client_secret that they couldn't use to get tokens, and = it was a bad disconnect. >>>>=20 >>>> The requirement for client secrets to expire or otherwise be = rotated by the server came from several implementors in the Connect WG. = There's an easy way to indicate that they don't expire, and a fairly = straightforward way for them to be rotated (client does a GET on its = client configuration endpoint url, with its registration access token as = auth). >>>>=20 >>>> -- Justin >>>>=20 >>>> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>>>> All, >>>>>=20 >>>>> In the dynamic registration draft, a new token type is defined = called the "registration access token". Its use is intended to = facilitate clients being able to update their registration and obtain = new client credentials over time. The client credential is issued on = completion of the initial registration request by a particular client = instance. >>>>>=20 >>>>> It appears the need for the registration access token arises from = the implied assertion that client credentials should expire. >>>>> --> Is anyone expiring client credentials? >>>>>=20 >>>>> To date, we haven't had much discussion about client credential = expiry. It leads me to the following questions: >>>>>=20 >>>>> 1. Is there technical value with client credential/token expiry? = Keep in mind that client credential is only used with the token endpoint = over TLS connection. It is NOT used to access resources directly. >>>>>=20 >>>>> 2. If yes, on what basis should client credential/token expire? >>>>> a. Time? >>>>> b. A change to the client software (e.g. version update)? >>>>> c. Some other reason? >>>>>=20 >>>>> 3. Is it worth the complication to create a new token type = (registration access token) just to allow clients to obtain new client = tokens? Keep in mind that client tokens are only usable with the AS = token endpoint. Why not instead use a client token for dyn reg and = token endpoint with the rule that once a client token has expired (if = they expire), an expired token may still be used at the registration = end-point. >>>>>=20 >>>>> 4. Are there other reasons for the registration token? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_002B8E34-42AF-4FA2-90C7-669C6F77B53F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE4MDcwNjUxWjAjBgkqhkiG9w0BCQQxFgQUJQWVIWgQ W/2nflu3XtfV//GyQT0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAClKJe8abljgP0/tgwYXLMlJH63AbuyQx0SaWJqd6 SnnEMpMazws8ucLAoUNUwLDR0bSBVOz21xSA4tm/TzpBymZCzhGiHdlqOcKlhCUqDPelISpZhPee 4kOqVU9kP5v4ly54wFWDudRrVZcm3UfS+ieYuBGP40hJ9cO4QXcWVouTHSS9wuDAJPk4jkALK2pn rl9y0O5zJa6LcqOfTRoueIh1+0ExS2prbCb9Ygc7I/xxe7ZuJV2dBGczB6VawZuRzkDNJMA8Boxc 6YX1qpndXn/OT4o9AYYIo6bPTjN5lX5cTOGhfCwBTxIwVvoMG8YND2vJHCnV1m6izeYSLRwS8gAA AAAAAA== --Apple-Mail=_002B8E34-42AF-4FA2-90C7-669C6F77B53F-- From phil.hunt@oracle.com Sat May 18 06:40:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6855E21F925B for ; Sat, 18 May 2013 06:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVsUND9VG3l9 for ; Sat, 18 May 2013 06:40:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id ABDE021F91BC for ; Sat, 18 May 2013 06:40:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4IDeZC0023640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 May 2013 13:40:36 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4IDeZUh017615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 18 May 2013 13:40:35 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4IDeZnc001546; Sat, 18 May 2013 13:40:35 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 May 2013 06:40:34 -0700 References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> <6BB36AB9-F2D3-4C40-AD7A-C6B4A979FAFF@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <6BB36AB9-F2D3-4C40-AD7A-C6B4A979FAFF@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Sat, 18 May 2013 06:40:31 -0700 To: John Bradley X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2013 13:40:43 -0000 John Thanks. This is *very* helpful. I will consider for next week.=20 Phil On 2013-05-17, at 23:56, John Bradley wrote: > =46rom what I have seen deployed, there are four common flows for registra= tion. >=20 > 1 2 developer uses a tool to register a client ID and place that in the cl= ient code for deployment of a native App that is distributed via an app stor= e for a 3rd party API. The developer may later need to make changes to the= registration as they develop the client and add functionality without chang= ing the client_id which would effectively invalidate all user consent as con= sent is by client_id. >=20 > 2 A client such as a web server (Think SAML SP) has a user turn up and ide= ntify themselves via a email address that be de-refrenced by say web finger t= o find a service for the API the client knows about and wants permission to a= ccess. The client learns the registration endpoint and registers itself for= a client_id at the endpoint and can then do OAuth 2 autherization with the A= S for the user. >=20 > 3 A client such as a web server wants to connect to a new AS. They try 2 b= ut get an error for dynamic registration indicating they need a credential t= o register. A admin is notified and goes to some AS portal for developers a= nd register an account perhaps validating a email and phone number for conta= ct as well as agreeing to the AS's terms of service. They then receive an a= ccess token for the registration endpoint that they cut and paste into there= app to do the actual registration. =20 >=20 > 4 A client such as a web server wants to connect to a new AS. They try 2 b= ut get an error for dynamic registration indicating they need a credential t= o register. A admin is notified and goes to some AS portal for developers a= nd register an account perhaps validating a email and phone number for conta= ct as well as agreeing to the AS's terms of service. The developer must the= n enter all there redirect URI keys and other configuration info manually in= to a form. Then gets another form or email with a key and client_id that th= ey use to configure the app. If the client secret expires they must use the= re developer account to login and get a new client secret. This is what we= are trying to automate with dynamic client registration. >=20 > 5 In a version of 3 the developer may be registering a client class with c= ertain constraints that override the dynamic registration of the class. The= y then get back the "Registration Access Token" and put that in a native app= to be distributed. The native app may then create its own keypair unique t= o that instance and proceed to register itself and get a per instance client= _id (but bound to the class at the AS) this would allow a native app to be c= onfidential( Some might see that as a good thing). The native app then use= s the new "Registration Access Token" it is granted to manage its settings. > The original API developer based on there developer credentials that gener= ated the original or class "Registration Access Token" could manage the clas= s including revoking it. This higher level class management design is allo= wed by the current spec but needs another spec to flesh it out. This is per= haps part of the 5% you are looking for. >=20 > The "Registration Access Token" is for a different resource than what ever= the actual API is. It is also not a client secret password and may have m= uch higher entropy as it is a token and not subject to limitations of http b= asic implementations. The initial "Registration Access Token" manages a c= lass (might only be one entity in the class) it is an access token so can ha= ve scopes. A possibility for 5 would be something like crate, update and re= ad. In 5 the token would only have create. The second "Registration Access= Token" that is instance specific would have more rights but only for its in= stance client_id. In the design there are two "Registration Access Token"= that are separate form client credentials at the token endpoint because th= ey are possibly used by different entities for operations on different subje= cts in the registration API. It is possible that in an extension we could= allow for the developer portal to provide access tokens with perhaps a dele= te scope for the class rather than the instance if that is perhaps one of th= e things you are looking for. =20 >=20 > I think the higher level management of classes of clients deserves it's ow= n profile. We need to ensure we are not blocking it with what we are doing= in dynamic registration. >=20 > John B. >=20 >=20 >=20 > On 2013-05-18, at 1:29 AM, Phil Hunt wrote: >=20 >> John, >>=20 >> Thanks for jumping in. >>=20 >> 1. I do buy the implied argument that some client credential types do ex= pire (eg. bearer assertions). Therefore the expiry issue has to be dealt wit= h. I would prefer to handle this by allowing an exception whereby expired a= ssertions could be used to re-register (only). This shouldn't be a big secur= ity issue since we're talking about an expired client refreshing with its is= suer rather then a third party trusting an expired token.=20 >>=20 >> I just don't think adding another token, the registration access token, t= hat in turn (by your argument) should expire, actually helps. It just adds a= nother layer to the problem and increases complexity. It solves nothing. >>=20 >> 2. You seem to be describing a different usage than Justin is. The way h= e explains the draft, there is no developer cycle at all. He's saying every= client gets a registration token and a client token. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-17, at 10:40 AM, John Bradley wrote: >>=20 >>> 1 No reasonable security profile is going to let you use the same symmet= ric password over long time periods. It will be brute forced given enough t= ime. =20 >>> The rotation time will depend on entropy and the rate an attacker can su= bmit attempts. I would expect profiles to look at SP-800-63 for guidance a= s essentially a password for the client. >>>=20 >>> 2 the registration interface is likely used by a developer who probably d= oesn't want the client instances (say native clients) to be able to update t= he configuration directly. using the client secret credential for updates w= ould break the separation. Registration my be done by the client itself or= by a developer as a separate process. >>>=20 >>> John B. >>>=20 >>> On 2013-05-17, at 7:27 PM, Phil Hunt wrote: >>>=20 >>>> Justin, >>>>=20 >>>> Your reason was you copied connect. Ok. I was looking for a technical r= eason. A security reason. >>>>=20 >>>> BTW. Mike Jones says expiry wasn't the reason. =20 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-17, at 9:01 AM, Justin Richer wrote: >>>>=20 >>>>> The separation between these two is necessary: Not all clients have cl= ient_secret, and you want the lifecycle/management of the registration to be= protected. This is what the registration access token was made for. In olde= r versions of Connect's registration, the client_secret was forced on all cl= ients in order to provide this, but then you had public clients with a clien= t_secret that they couldn't use to get tokens, and it was a bad disconnect. >>>>>=20 >>>>> The requirement for client secrets to expire or otherwise be rotated b= y the server came from several implementors in the Connect WG. There's an ea= sy way to indicate that they don't expire, and a fairly straightforward way f= or them to be rotated (client does a GET on its client configuration endpoin= t url, with its registration access token as auth). >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>>>>> All, >>>>>>=20 >>>>>> In the dynamic registration draft, a new token type is defined called= the "registration access token". Its use is intended to facilitate clients b= eing able to update their registration and obtain new client credentials ove= r time. The client credential is issued on completion of the initial regist= ration request by a particular client instance. >>>>>>=20 >>>>>> It appears the need for the registration access token arises from the= implied assertion that client credentials should expire. >>>>>> --> Is anyone expiring client credentials? >>>>>>=20 >>>>>> To date, we haven't had much discussion about client credential expir= y. It leads me to the following questions: >>>>>>=20 >>>>>> 1. Is there technical value with client credential/token expiry? Ke= ep in mind that client credential is only used with the token endpoint over T= LS connection. It is NOT used to access resources directly. >>>>>>=20 >>>>>> 2. If yes, on what basis should client credential/token expire? >>>>>> a. Time? >>>>>> b. A change to the client software (e.g. version update)? >>>>>> c. Some other reason? >>>>>>=20 >>>>>> 3. Is it worth the complication to create a new token type (registrat= ion access token) just to allow clients to obtain new client tokens? Keep i= n mind that client tokens are only usable with the AS token endpoint. Why n= ot instead use a client token for dyn reg and token endpoint with the rule t= hat once a client token has expired (if they expire), an expired token may s= till be used at the registration end-point. >>>>>>=20 >>>>>> 4. Are there other reasons for the registration token? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From internet-drafts@ietf.org Sun May 19 09:59:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC521F87E0; Sun, 19 May 2013 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZXOTElAJTBl; Sun, 19 May 2013 09:59:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2062921F882A; Sun, 19 May 2013 09:59:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130519165957.1815.79440.idtracker@ietfa.amsl.com> Date: Sun, 19 May 2013 09:59:57 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-08.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: Sun, 19 May 2013 16:59:58 -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 Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-08.txt Pages : 10 Date : 2013-05-19 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun May 19 10:04:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC2C21F8DD5; Sun, 19 May 2013 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvzHA4chTTMs; Sun, 19 May 2013 10:04:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7E21F8D70; Sun, 19 May 2013 10:04:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130519170413.8755.15810.idtracker@ietfa.amsl.com> Date: Sun, 19 May 2013 10:04:13 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-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: Sun, 19 May 2013 17:04:15 -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 2.0 Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-09.txt Pages : 10 Date : 2013-05-19 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sun May 19 10:08:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482F21F8E06 for ; Sun, 19 May 2013 10:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1AKmpIdU4+k for ; Sun, 19 May 2013 10:08:07 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id D326621F8EA6 for ; Sun, 19 May 2013 10:07:58 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Ue75R-0002Kp-7s for oauth@ietf.org; Sun, 19 May 2013 19:07:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 19 May 2013 19:07:57 +0200 From: Torsten Lodderstedt To: In-Reply-To: <20130519170413.8755.15810.idtracker@ietfa.amsl.com> References: <20130519170413.8755.15810.idtracker@ietfa.amsl.com> Message-ID: <0d3cddff70416885cef176fbb5fe7aef@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.8.1 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-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: Sun, 19 May 2013 17:08:11 -0000 Hi all, this revision covers all minor issues from IETF LC. regards, Torsten. Am 19.05.2013 19:04, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > Title : OAuth 2.0 Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-09.txt > Pages : 10 > Date : 2013-05-19 > > Abstract: > This document proposes an additional endpoint for OAuth > authorization > servers, which allows clients to notify the authorization server > that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security > credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization grant. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-09 > > > 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 jricher@mitre.org Mon May 20 08:02:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6001A21F9354 for ; Mon, 20 May 2013 08:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E77Dff3n10uV for ; Mon, 20 May 2013 08:02:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73221F9355 for ; Mon, 20 May 2013 08:02:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DF0F1F03CD; Mon, 20 May 2013 11:02:43 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1D8A61F0666; Mon, 20 May 2013 11:02:43 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:02:42 -0400 Message-ID: <519A3AF6.7030302@mitre.org> Date: Mon, 20 May 2013 11:02:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <80E6C4AC-5402-43E3-A6A2-0A98595F7203@oracle.com> <4E1F6AAD24975D4BA5B168042967394367734D79@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367734D79@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------030208060002080301080103" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:02:50 -0000 --------------030208060002080301080103 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Since the various mail clients that people use have been wreaking havoc with the threaded nesting of this discussion, I'm prepending my newest comments with [JR] below. -- Justin On 05/17/2013 08:01 PM, Mike Jones wrote: > > My replies are in green and marked [mbj]. > > -- Mike > > *From:*Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Friday, May 17, 2013 2:24 PM > *To:* Mike Jones > *Cc:* Richer, Justin P.; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 > > I have started a separate thread on having dyn reg correlate client > software. > > My other comments are embedded marked with [PH]. > > Phil > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > On 2013-05-17, at 1:08 PM, Mike Jones wrote: > > > > Thanks for the detailed feedback, Phil. Sorry for the delayed > response – I was pretty fully engaged at the European Identity > Conference (whereOAuth 2.0 won the award for best new standard > J). My feedback on the points raised > is inline in green… > > (Perhaps if any of you reply to this thread, you could also choose a > distinctcolorfor your inline replies, so that it will be easily > evident who said what. As it is, just the back-and-forth between Phil > and Justin is already very difficult to follow. Thanks.) > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org]*On > Behalf Of*Phil Hunt > *Sent:*Thursday, May 16, 2013 12:54 PM > *To:*Richer, Justin P. > *Cc:*oauth@ietf.org WG > *Subject:*Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 > > Justin, > > Thanks for the discussion. More comments below... > > BTW. I'm happy to contribute text. Just want to get to some rough > agreement first. For example, I think we need to have a away to > recognize two pieces of software as being the same (even if > self-asserted). Once defined, I can put together some intro text, etc. > > Phil > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > > On May 15, 2013, at 10:30 PM, Phil Hunt > > > wrote: > > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > > Phil, many thanks for the extremely thorough review! It is very useful > indeed. > > My comments and responses to each point are inline. > > On May 15, 2013, at 4:30 PM, Phil Hunt > wrote: > > It seems unfortunate that I have not gotten a chance to get into this > level of detail much earlier. But then, I guess that's what LC review > is for! My apologies for not getting many of these concerns to the WG > much earlier. > > */Overall /* > > ----------- > > I think dynamic registration is a critical part of the OAuth framework > now that we are starting to consider how individual client > applications should operate when there is one or more deployments of a > particular resource API. We've moved from the simple use case of a > single API provider like Facebook or Flickr and moved on to standards > based, open source based, and commercial based deployments where there > are multiple service endpoints and many clients to manage. > > The dynamic registration spec is actually dealing with a couple of > issues that I would like to see made more clear in early part of the spec: > > 1. How is a new client application recognized for the first time when > deployed against a particular SP endpoint? Should clients actually > assert an application_id UUID that never changes and possibly a > version id that does change with versions? > > In the general case, why is any recognition required? If you're doing > things as part of a larger protocol ecosystem, like Blue Button+ or a > particular OpenID Connect provider, then you can define semantics for > tying together classes of clients (see below for more discussion on > this very point). But in general, a client is just going to show up as > a new instance to the AS and get issued a new, unique client_id, and > that's that. > > I think we have to define more clearly what an "instance" is. For me, > there are applications and there are instances of that application. > It is useful to understand that a client application represents a set > of code that should behave in a consistent way. It seems to me the > first time a new application shows up is very different from the > subsequent instances that register. For example, after the first > registration, subsequent instances don't need special review or > approval to the same degree. > > But without other mechanisms to tie things together, there's no way > for an authorization server to know if any client instance is tied to > any other client instance. Therefore, from the perspective of an AS, > the first instance of an application (i.e., particular configuration > of a set of code) to register is no different to subsequent instances > of that same application. How were you envisioning an AS knowing the > difference between the first and subsequent instances of an > application, specifically? If there's an "application_id" like you > mention above, I think it raises more questions than it resolves: Who > issues the application_id, some server or the application itself? Is > it validated at all? Should it be considered secret? What happens when > someone simply steals an application_id? Does an AS have to do > anything to check with any other AS to see if the application_id has > already been used elsewhere? > > I do agree that a discussion of "instance vs. application" would be > helpful in clearing this up, I'll make a note to add text to that > effect. (We had to do something similar for BB+) > > I think it is simple enough to at least add a self generated UUID for > the application ID. Though I would allow for cases where the > application ID is assigned when the client developer and the APIs > owner do a formal assignment of application IDs. > > In a sense this is just a lower tech way of doing it than what you > described as the initial client credential in Blue Button+ where you > encoded extra claims into the initial app credential. > > What the UUID does is link multiple instances of a client app together > as the same "thing" that should have similar heuristics/behaviours. > This is very useful if you want to be able to revoke access to a set > of clients identified by application id (or a version of that app). > > While I’m sympathetic to the OAuth working group eventually doing work > on differentiating between instances of an OAuth client, I’ll note > that in RFC 6749 or RFC 6750 there is no such thing as a client > instance. There are only clients, which are identified by client_id > values. If we want to do work on client instances, we should > recharter to add this new work as a working group deliverable. We > should not try to shoehorn bits and pieces of it into the Dynamic > Registration spec, any more than we should have tried to shoehorn it > into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients > as defined in RFC 6749. It’s not the right place to extend what an > OAuth client is in new ways. > > [PH] See new thread I have begun. > > 2. How are client credentials managed. Are we assuming client > credentials have a limited lifetime or rotation policy? > > The intent was that client_secret could be rotated, as > indicated by the expires_at member of the response. If a > client's secret expires, it calls the read operation on the > Client Configuration Endpoint (§4.2) to get its new > client_secret. If this is unclear in the current text (which I > suspect it may be after multiple refactorings), then I welcome > suggestions and specific text as to how to make that clear. > > Something like this should be in the draft. > > Should this be up in the introductory text, somewhere else, or > have its own section? > > I'm starting to think credential management is a key part of the > draft. It may be worth introducing a specific section outling the > registration life-cycle, registration access token usage, and client > token usage and bootstrapping. > > I think that adding a discussion on this would be fine, as it could > help developers understand the workflow of registering, using, and > updating registered clients. > > How does a client authenticate the first time and subsequent times > to the registration service? > > This is a separate question all together, as it does not involve > the client_secret or client_id at all. Rather, the first time the > client shows up to the registration service, it may either: > > - Not authenticate at all (this is the true public, open > registration, and it is recommended that servers do this) > > - Authenticate using an OAuth 2.0 token (which ATM means a bearer > token). How the client gets that bearer token and what the bearer > token means to the AS beyond "this client is authorized to > register" is out of scope for the spec, by design. > > Subsequent times that the same registered client (by which we mean > the same instance of a client with a particular client_id) shows > up at the registration endpoint (actually, the Client > Configuration Endpoint), it uses its Registration Access Token > that it was issued on initial registration. This is an OAuth 2.0 > Bearer token that is unique to the client instance. > > Something like this should be in the draft. > > OK, the definition of the registration access token can be expanded, > but I think that the rest of it is already in there in §3. I'd welcome > suggestions on which bits of this could be made clearer. > > See the discussion on what the registration_access_token is in the > thread “Client Credential Expiry and new Registration Access Token - > draft-ietf-oauth-dyn-reg-10”. I will work with Justin to apply these > clarifications to the specification. This may go into the proposed > credential management overview section discussed above. > > 3. How is versioning of clients managed? Should each new > version of a client require a change in client registration > including possibly changing client_id and authentication > credential? I don't have a strong feeling, but it is something > that implementors should consider. > > This is up to the AS, really, and I don't think that any global > policy would ever fly here. Especially if you consider that the > entire notion of "version" is more fluid these days than it ever > has been. I wouldn't mind adding a discussion in the security > considerations if it merits mentioning though, so that we can help > both client developers and server developers institute reasonably > good policy. > > I guess the issue is that when a client upgrades it may have access to > the old credentials. What is the intent then of registration. Since > you have an update are clients expected to update /re-register or not? > I'm not sure this is a security consideration but more part of the > whole change management function dynamic registration supports. > > If your upgraded version of the client still has access to its old > credentials, why wouldn't it just use those? I don't see a reason for > forcing a re-registration. Nor do I see any way that an AS would even > be able to tell that a client had been upgraded. An upgraded client > always has the *option* of re-registering itself and getting a new > client_id. > > I think the concern here is that rotation of client credential is not > something discussed before. Before we put it in the spec we should > consider the reasons for doing it and what problems it solves. > > I think this may be just a case of letting people exchange credentials > for whatever reason they feel is appropriate. The version upgrade > thing suggests that when a client is upgraded it should go to the > registration server to "re-register". Depending on the policy of the > server, it may (or may not) receive a new client_id and/or new > credential. > > One of the best benefits I can think of is if you discover a version > of a client has a problem, being able to select a group of clients by > software and version is important. Thus if client_id doesn't trace to > a particular software and version, that makes it hard to do. I think > you talked about this as an issue for Blue Button+ > > Again, RFC 6749 defines no client instances or groups of clients, > therefore I believe that it’s inappropriate to do so here. We don’t > need to boil the ocean. If a new charter item is approved to do work > on client instances and protocol elements to use and express them, > that’s the time for the working group to consider that possibility – > not as part of Dynamic Client Registration. > > [PH] We disagree strongly here. I think it is well within charter and > in fact if such a new charter item were developed we would be quickly > moving to replace dyn reg version 2. > > [mbj] Per my comments on the new thread you started, we wouldn’t be > replacing the existing dynamic registration spec – we’d be creating a > new OAuth Client Instance Management spec, once piece of which would > be defining the 5% extensions needed to use it for that use case. > (And also per my comments on that thread, I’m sure that the > registration bits wouldn’t be all that would be in that spec – they’d > probably only be a small part of it.) > [JR] And if this new work were to start up, I think that the BB+ protocol for managing client classes and instances would be a good place to start, or at least learn from what we're doing in there. As Mike points out, the registration is actually a very small part of what's needed, and BB+ doesn't actually define any new registration parameters. There is a whole other layer of service discovery and vetting of client parameters that happens in BB+, though, that don't make sense to cram into OAuth Dyn Reg. As I've stated in a previous message, a simple client-generated UUID *cannot* be sufficient for tying multiple clients together, the race conditions between multiple auth servers alone make it completely unusable. Which is to say, it's a more complex problem than it seems on its surface, and it deserves to get a good amount of attention and be actually engineered and solved appropriately. > 4. What is the registration access token? Why is is used? What is > its life-cycle? When is it issued, when is it changed? When is it > deleted? > > See the response above above and the definition in §1.2: > > Registration Access Token: An OAuth 2.0 Bearer Token issued by > the Authorization Server through the Client Registration > Endpoint which is used by the Client to authenticate itself > during read, update, and delete operations. This token is > associated with a particular Client. > > If this can be clarified, I welcome text suggestions. > > The latter part of 1.2 didn't seem like terminology but rather > architecture or part of the introduction that describes what the spec > does. The third point doesn't seem to fit with the other two except to > say that the dynamic registration endpoints use their own access > tokens called registration access tokens. > > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > > o Registration Access Token: An OAuth 2.0 Bearer Token issued by the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > > This section is meant to just introduce the new terms that are then > explained in greater detail throughout the rest of the document. Yes, > it's a bit architecture, but only in the sense that you need to define > the terms that make up your architecture. How would you suggest that > it change? > > Probably this is more a matter of style. But, what happened for me is > I naturally skipped the terminology section, as I wasn't expecting > protocol components to be there. "terminology" is something I think > people tend to use as a dictionary rather than as protocol component > description. Maybe the chairs can advise? > > If we distinguish between first time registration of a particular > client software package, it is possible that somethings like > authentication method can be negotiate in or out-of-band at that > time. Subsequent registrations should only have parameters for > items that could change per deployment (like tos_uri). I think > token_endpoint_auth_method is one thing that should not be > negotiated per instance. > > When subsequent instances register, I have to ask the > question, for example when would things like > "token_endpoint_auth_method" be negotiated or be different for > the same client software? Should not all instances use the > same authentication method. > > I'm confused by this -- as far as the dynamic registration spec is > concerned, all instances are separate from each other. All > parameters change per instance. And instance, you should keep in > mind, is defined as any one copy of the client code connecting to > any new authorization server. That pairing creates the client_id, > and therefore the instance, and therefore the registration access > token, and therefore the registration itself at a conceptual > level. So there is no way other than per-instance for a client to > ask for a particular token_endpoint_auth_method. Where else would > the AS find out about it? > > We still disagree on this. It is my assertion that clients should > NEVER ask for a particular token auth method. Since it is the AS that > is authenticating the client, then it is the AS's right to set the > authentication policy. The role of dynamic reg endpoint is to inform > the client what it must do. My assumption is that during the first > time a piece of software is registered (the first instance), there > could be some OOB discussion by an administrator to approve the > particular authentication type for the AS in question. > > I haven't heard a reason justifying this parameter other then "it is > needed". Why? > > The role of the dynamic registration protocol is twofold: half of that > is the server informing the client what it must do. But the other half > is the client informing the server what it *can* do, or what it > *wants* to do. > > And again, there's no way to distinguish a first instance from a > subsequent instance unless you're doing something in addition. Nothing > is stopping the same application from registering a new instance of > itself for every single user or every single token that it wants to > get access for. That's complicated and wasteful and not a great idea, > sure, but there's no useful way to prevent that kind of behavior if > you also want open registration of clients. > > I think we've discussed how recognizing subsequent instances is easily > done. > > As I mentioned in the other thread, if a developer chooses to limit > the capabilities of the client it must do so by looking to the > developer or standard behind the API. Otherwise they are taking the > chance. There's no way a developer can query all the potential > deployers to ask what authn types will you use. As I said, the net > effect in the absence of an API standard dictating what should be > supported, the developer will have to implement all methods. > > My point here is that none of this is helped by the client app saying > what it supports. A developer who takes the route of limiting > implementation takes the chance that the server will not accept. So > why negotiate within registration? > > And there's no way other than per-instance for the server to tell > the client which token_endpoint_auth_method to use. All instances > will probably ask for the same token_endpoint_auth_method from all > auth servers they talk to, right? And each AS will tell each > instance that registers with it to use a particular auth method. > There is no way to tie together different instances across (or > within) auth servers without specifying a significant amount of > other machinery. > > Which is not to say that it's not useful in some circumstances to > tie together different instances of the same code across (or > within) auth servers. This is why, with Blue Button+, we specified > a specific token format for the initial access token that the > clients use to call the registration endpoint the first time, as > well as a discovery protocol against a centralized server that > handles pre-registration. All of this machinery is, in my opinion, > a stupendous overkill for the general case, though if some folks > find use for it outside of BB+ then it'd be a good thing to > abstract out and make its own spec that extends the Dyn Reg spec > in a fully compatible way. Furthermore, even in Blue Button+ we > specify that all auth servers MUST also accept open registration, > without an initial access token, where the client simply shows up > and says "hey, here are my parameters." The auth server has no way > to know in this case any kind of out-of-band negotiation for > different things. In BB+ we are writing very specific policy > guidelines about how to present the UX and things to the end user > for all of these different cases. But again, all of this is > specific to the BB+ use case, and I don't see value in dragging it > in to the registration spec on its own. I believe it would be far > too limiting. > > See my previous comments on differentiating client instances being > out of scope without rechartering to do this new work and on what > the registration_access_token is. In short, the > registration_access_token is an RFC 6750 bearer token issued to > the party registering the client, enabling it to subsequently > retrieve information about the client registration and to > potentially update the registration information for that > registered client. Again, I’ll work with Justin to make sure that > this is as clear as possible in the specification. > > Finally, there seems to be an inconsistent style approach with > draft-hardjono-oauth-resource-reg > which > uses ETags. Should this draft do so as well? > > That's an individual submission, not a working group draft. Nobody > has, until now, even mentioned the use of ETags here. UMA (where > the resource registration draft comes from) uses ETags, hence > their inclusion there. I personally don't see their utility here, > though, and I wouldn't want to include a wholly new mechanism this > late. > > Yes. Thomas' draft is not a WG document. But that doesn't mean he > doesn't have a point. It's worth discussing. > > One could argue that the point of an ETag is that it is useful for > change detection when there are multiple writers to a particular > resource. In the design of dynamic registration endpoint, there > should only be one writer -- the client. This is an important observation. > > There are other mechanisms that handle this -- namely, the > registration access token and the client_id. Many instances include > the client_id in some form in the client configuration endpoint's URL > for sanity checking, as described in §4.1. > > If everyone agrees, I'm in agreement. But it will likely mean changes > for the resource reg draft if adopted. > > ETags seem like an unnecessary addition (and potential complication) > to the specification. It’s already working fine as-is. > > */Specific items:/* > > --------------------- > > *"token_endpoint_auth_method"* > > There is some confusion as to whether this applies to server > or client authentication. Suggest renaming parameter to > "token_endpoint_client_auth_method" > > This is the first I've heard of this particular confusion. I'm > fine with either name but at this stage I don't want to make > syntax changes without very, very compelling reasons to do so. > > The question was raised to me by some new developers. It seems > obvious to us as experienced OAuth persons, but to new developers > it seems unclear. Also, now that you are introducing registration > authentication, the whole thing gets very confusing. So it is > useful disambiguate all the parameters where possible. That said, > I wouldn't mind shorter names (maybe not quite as short as the > JOSE stuff ;-) > > Fair enough, but again, I only want to do syntax changes if the > rest of the WG *really* wants to. > > I agree with Justin here. I’m fine clarifying the description of > this parameter to resolve the potential ambiguities that you cite, > Phil. I’m not OK revising the syntax without a compelling reason > to do so. > > [PH] I don't think we're changing any syntax here. Just clarifying the > name. This seems important now that there are 3 types of tokens being > managed (registration, client, access). > > I would much prefer just dumping the registration access token rather > then renaming parameters that would otherwise be unclear. > > [mbj] Changing a name is changing the syntax. > [JR] Agreed w/Mike, and this applies to all of the suggested name changes: token_endpoint_client_auth_method, client_id_issued_at, client_secret_expires_at. It's not that I disagree with the new names (the latter two are actually markedly better), it's that I don't want to change syntax without a chorus of developers here on the list saying that the new syntax would be better for *them*. Editorial changes, like expanding the explanatory text for these parameters, are another matter and can be made without breaking running code. That said, I *really* want to hear from people who are building and deploying this right now to see if the suggested syntax changes would be good, bad, or neutral to them. I think I should perhaps start another thread on just that topic, since this important point might be getting lost in this wall of text. > As for dumping the registration access token, given that the > registration access token is used by the code author to access one > resource and the client_id is used by the code to access a different > resource, and that the security characteristics of the two kinds of > access are very different, I believe it would be a security and > usability disaster to try to blend them together. > [JR] This is a completely separate issue, and as Mike points out, the client_id, client_secret, and registration_access_token serve completely different purposes. If those purposes are unclear, we can explain them. Deleting any of these or merging them is a terrible idea. > * Currently, the API only supports a single value instead of an > array. If the purpose is to allow the client to know what auth > methods it supports, this should be an array indicated what > methods the client supports - or it should not be used. > > I would rather like this to be an array, personally, and brought > it up with the OpenID Connect working group about six months ago. > But there it was decided that a single value was simpler and > sufficient for the purpose. The IETF draft has inherited this > decision. I *believe* (though am not 100% positive) that I brought > up this very issue in the WG here but didn't receive any traction > on it, so single it remains. > > I can get behind multiple values. In this case, it changes the meaning > of the parameter. Instead of the client forcing the server to use a > particular method, the client is informing the server about what > methods it can perform. This allows the server to assign the > appropriate method based on its own policy. > > > Also note that this field, like all others in §2, represents two > things: the client telling the server "I want to use this value for > this field", and the server telling the client "this is the value you > have for this field". It's not exactly a negotiation, more like making > a polite request to an absolute dictator who has the last word anyway. > But at least this dictator is nice enough to tell you what their > decision was instead of just decapitating you. > > This is the heart of my objection. This fuzziness is is going to lead > to interop issues. > > There is no fuzziness that I can see here. It's parallelism between > what goes in to the endpoint and what comes out of it. The semantics > for the request and the response are different, and differentiable by > the fact that one is a request and the other is a response. > > The inter-op issue I would like to point out is that the spec does not > currently specify if particular input values are singular or multiple. > If an implementer assumes singular and clients assume multiple, we > have issues. > > The multiple/single discussion above gets to the heart of what I > **do** believe is a deficiency in the specification, as it’s currently > written. The authors, myself included, have failed to make it 100% > clear that discovery of Authorization Server functionality is out of > scope for this specification. I strongly believe that we need to add > a clear statement to this effect in the introduction to the specification. > > The purpose of the Dynamic Client Registration specification is for > the client to register with the Authorization Server and to inform it > of properties of the client that the AS may want/need to be aware of. > It **is not** the purpose of this specification for it to be used by > clients in any manner to discover features of the Authorization > Server. That should be explicitly out of scope. > > [PH] Agreed. > > Currently, clients are instructed by RFC 6749 to discover information > about Authorization Servers they interact with by consulting the > “service documentation” (RFC 6749, Sections 3.1 and 3.2). They can > also learn information about Authorization Servers in specific > contexts through discovery protocols such as OpenID Connect Discovery > (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA > Discovery (TBD). > > I suspect that at some point, someone in the OAuth working group will > propose developing a generic OAuth discovery mechanism, which will > lead to a rechartering to include this work in the working group’s set > of deliverables. I would support doing this work and the necessary > rechartering to do so. > > [PH] So, given the above, the client shouldn't be dictating token > type. The AS should simply assign the credential and inform the client > what it must use. > [JR] How can a public client tell the AS that it doesn't want a client_secret, and can't reasonably protect it? How can a client that wants to do some kind of holder-of-key > [mbj] You seem to be (intentionally?) ignoring John Bradley’s point > that it’s the client that knows which of the security profiles > supported by the AS that it needs to use – not the AS. Therefore, for > security reasons, it must be the client that picks the method from > among those supported by the AS – not the other way around. The AS has > no way to know which methods are appropriate for which clients, but > the clients do. > > We agree, no discovery. But I also want to eliminate negotiation that > doesn't actually help anything. > > [mbj] I’m not describing negotiation above. I’m describing the party > with the knowledge to make the appropriate choice being able to make > that choice. > > That being said, I strongly oppose trying to shoehorn piecemeal > aspects of discovery into the Dynamic Client Registration > specification. It is distinct functionality and deserves first-class > and separable treatment by the working group. Discovery is for > potential clients to learn properties of the AS before registration. > Registration is for potential clients to inform the AS of its > properties, creating a registered client. Discovery sends information > about the AS to the Client. Registration sends information about the > Client to the AS. That’s a clean separation. We should strongly > resist muddying the two functions. > > OAuth 2.0 is a success because it didn’t try to boil the ocean. It > specified how to do one thing well in a simple, web-friendly manner. > We should do the same – focusing on specifying interoperable dynamic > client registration, while making it clear that this is distinct from > discovery about Authorization Server properties, and making it clear > that discovery is out of scope for this work. > > I apologize at this point on behalf of myself and the other spec > editors for not being 100% clear that discovery functionality is > explicitly out of scope for Dynamic Client Registration. If we had > done so, I’m sure that many of the current questions and confusions > would not have arisen. I think we’d assumed that this was obvious, > but from the current discussions, it’s apparent that it’s not > obvious. I will personally commit to clarifying the specification at > this point to eliminate this potential point of confusion. > > Getting back to the specifics, the only useful purpose of a > multi-valued “token_endpoint_client_auth_method” member would be to > enable the client to discover information about the authentication > methods supported by the AS after the registration had been > performed. But that is a discovery function, and so should be part of > the discovery work – not this specification. We should resist > shoehorning in bits of discovery into this specification. It **is** a > worthwhile topic, but deserves full consideration by the working group > in its own right. Therefore, this member must remain single-valued, > and be clearly specified as the method by which a client informs the > AS which token endpoint authentication method it will use. Anything > else would be scope creep, and result in an unnecessarily complicated > specification and unnecessarily complicated clients. > > [PH] Agreed. Let's remove the parameter.in the request. It should only > be in the response. > > [mbj] Removing the parameter would make it impossible for the client, > which knows which security profile it needs to use, to declare to the > AS which method, from among the methods supported by the AS, that it > needs to use. The client MUST be the one doing the choosing. > [JR] Again, see above note about public clients. The server knows nothing about the client before it shows up, including what the client believes it can protect. Registration on this parameter is the client saying "I can do this", and the server's response is "you may do this". Both are distinct and necessary. > * There is no authn method for "client_secret_saml" or > "private_key_saml". > > Nobody has really asked that these two be included or specified. > The extension mechanism (using an absolute URI) would allow > someone else to define these. Is the definition in the SAML > Assertion draft sufficient for their use? > > I think this is coming from the fact that there is a JWT bearer draft > and a SAML bearer draft. The truth is you are defining an > authentication that isn't even defined. > > /There are no profiles referenced or defined for > "client_secret_jwt" or "private_key_jwt". Neither of the JWT > or SAML Bearer drafts referenced cover these types of flows. > They only cover bearer flows. "client_secret_jwt" and > "private_key_jwt" seem to have some meaning within OpenID > Connect, but I note that OIDC does not fully define these either./ > > The JWT assertion draft does say how to use a JWT for client > authentication, and the DynReg text differentiates between a > client signing said JWT with its own secret symmetrically vs. > a client using its own private key, asymmetrically. > > Actually my interpretation is the JWT draft assumes the JWT Bearer > is a bearer token. The assumption is that if a client has the > assertion it has the right to present it. IOW. The JWT Bearer > Draft is most definitively not a JWT HoK Draft. :-) > > Regardless, you are introducing a new profile which is undefined. > > I think I see the point that you're making now, let me try to re-state it: > > While the basics of "how to present a JWT as a client credential" is > defined here: > http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, > it's not completely specified in that it doesn't fully restrict the > signature secret source, the audience claim, and other things that the > AS would need to check and validate. Right? The dynamic registration > draft can define those cases in greater detail if needed (though I > think it does so sufficiently as-is, I welcome more clarity). > > I'd be OK with adding the SAML bit, going into greater detail on the > JWT bits, or dropping the JWT bits, if the WG wants to do any of those > actions. My objection is that the JWT stuff is already in use and > functioning and it'd be a shame to leave it out. > > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors > made is they assumed everyone had the same definition of bearer token. > To me a bearer token opaque to the client. It therefore cannot do any > signature work with regards to the token itself. Now, that's not to > say a proof didn't occur between the client and the token issuer, but > when the client wields the token, it is handling an opaque string. > > The concept of client_secret_jwt suggests an HoK profile. Therefore > of course the bearer drafts are a little underspecified when it comes > to HoK profiles. > > So for example, you need a draft like the MAC draft for this. > > I'm having trouble overall here. It seems the authn types suggest ONLY > strong authentication for clients, yet during the registration process > the current draft isn't able to correlate multiple instances of the > same software (even in a self-asserted way). If you haven't > authenticated the software at all, why have strong client auth? > > There is no authentication method defined for > "client_bearer_saml" or "client_bearer_jwt" or > "client_bearer_ref". Since the bearer specs say this is > acceptable, the dynamic registration spec should accept > these. > > I don't understand this bit -- where are these defined in > RFC6750? I don't even know what client_bearer_ref would > refer to. > > 6750 says you can use a bearer assertion (e.g. obtained from > an IDP) and wield it as an authentication assertion. The > client is NOT creating or modifying the assertion. The client > is simply passing one it previously obtained. > > What you are describing is not bearer. It is holder of key. > Very very different. > > > A possible suggestion is to remove client_secret_jwt and > private_key_jwt and define those as register extensions since > these profiles are not defined. > > That's possible, but they are in active use already. > > That may be true. But then you need to write another draft so > the rest of us can implement it in an interoperable way. Me I > prefer not to guess what you are doing. > > This much I agree with. > > Justin, John, and I discussed this issue and agree with your > suggestion, Phil. Since they are not completely specified, we will > remove the client_secret_jwt and private_key_jwt methods from the > specification and add a registry, enabling specification that do > fully specify these and other token endpoint authentication > methods, including potential methods using SAML assertions, to > register them in the registry, rather than trying to bake them > into the Dynamic Client Registration specification. > > *About "tos_uri" and "policy_uri"* > > The distinction between tos_uri and policy_uri is unclear. > Can we clarify or combine them? > > Terms of service and policy are two different documents. One > is something that a user accepts (generally describing what > the user will do), one is a statement of what the service > provider (in this case, the client) will do. More importantly, > we used to have only one, and several people asked for them to > be split. > > Several developers were confused by this. In particular they > couldn't figure out which was used for what. Just passing along > the feedback. > > OK, the distinction that I see is that the TOS is contractual, the > Policy is a statement. Re-reading the definitions in there right > now, that can be made much clearer. (It even looks like some OIDC > text leaked into the definition of policy_uri and that hadn't been > caught yet.) > > I support clarifying the language on these definitions, and will > work with Justin to do so. > > Also, aren't these really URIs or are they meant to be URLs? > > There was already discussion about this on the list: The IETF > is apparently trying to deprecate URL in favor of URI in new > specs. So in practice they'll nearly always be URLs, but since > all URLs are URIs we're not technically incorrect in following > the new policy. And it makes the IESG less mad at us, which is > a plus. > > Arg. Nice. Then the text should say the value passed must resolve > to a valid web page, document, whatever. > > That's fair, and it's something that the AS can even check if it > wants to. > > Agreed on this clarification. > > *About "jwks_uri"* > > A normative reference for > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is > needed. > > Yes, you're correct, I'll add that. > > Should be URL instead of URI? > > See above. :) > > Agreed on adding this reference. > > *Section 2.1* > > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > > is missing. > > It's there in the copy of -10 I'm reading off ofietf.org > right now … ? > > ' > > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > > Ah, that makes more sense. If the WG wants to add in SAML support > to parallel the JWT support, I'd be OK with that. > > “As such, a server supporting these fields SHOULD take > steps to ensure that a client cannot register itself into an > inconsistent state.” > > We may want to define more detailed HTTP error response. E.g. > 400 status code + defined error code (“invalid_client_metadata”)? > > I'd be fine with defining a more explicit error state in this > case. I think it would help interop for the servers that want > to enforce grant-type and response-type restrictions, but > servers that can't or don't care about restricting grants > types and whatnot don't have to do anything special. > > I **think** that this goes away with the deletion of > client_secret_jwt and private_key_jwt in favor of the > registry… I’ll do a consistency check and verify that when > the spec is updated accordingly. > > [PH] Agreed. > > *Section 2.2* > > May want to add: > > When “#” language tag is missing, (e.g. “#en” is missing in > “client_name”, instead of “client_name#en”) the OAuth server > may use interpret the language used based on server > configuration or heuristics. > > That seems inconsistent with what we already have: > > If any human-readable field is sent without a language > tag, parties using it MUST NOT make any assumptions about > the language, character set, or script of the string > value, and the string value MUST be used as-is wherever it > is presented in a user interface. > > Which is to say, treat it as a raw byte-value-string and don't > try to get fancy. > > I will discuss with our developers. I'm not sure the as-is works. > > Is it the intent that when the client has localized "client_name" > for example, it should pass all language variations in a JSON array? > > Or, should part of the registration be to indicate which interface > language the client wishes to use? Then it only passes a single > value for that registration? > > No, the client should pass parameters as multiple separate values. > Connect has this in its example: > > "client_name": "My Example", > > "client_name#ja-Jpan-JP": > > "クライアント名", > > Should we add that to at least one of the examples in DynReg? (The > language tags are a late addition, so the examples don't reflect it.) > > An example would definitely help. > > If the client passes only a single unadorned field, the AS can't > make any assumption about what language it is. Think of this as > the internationalized value of the field while the language tags > are the localized versions of the field. This is why we recommend > that the bare-value always be sent by the client, so that in the > lack of anything more specific, the AS can at least do *something* > with it. > > Passing in a "default" language field (like default_locale or the > like) is only going to lead to pain for implementors of both > clients and servers, and it's going to hurt the interoperability > of the human-readable fields. > > I think what I meant is since you are allowing each client to register > different things, AND the client likely already knows the user's > preferred language, why wouldn't the client just pass text values in > one language and another parameter indicating preferred language in > the case of any service generated text. > > Is the reason you are passing multiple localizations is so that you > can use the preferred language of the resource owner rather then the > client user? I wonder if that is correct. If the language preferences > are in fact different, what would the user of the client app expect? > > ----> any multi-lingual people have any opinions here? > > Without specific proposed text changes to review, it’s hard to > know what to think about this comment. Unless a specific proposed > text change is sent to the list with clear rationale for why it’s > better than what’s there now and reviewed by the working group, I > don’t believe we should change the specification in response to > this comment. > > [PH] I agree. I plan to follow up and see if I can't get more > clarification on requirements from my side. > > *Section 3* > > Existing text: > > “In order to support open registration and facilitate > wider interoperability, the Client Registration > Endpoint SHOULD allow initial registration requests with > no authentication. These requests MAY be rate-limited or > otherwise limited to prevent a denial-of-service attack on > the Client Registration Endpoint.” > > I would suggest to change the first “SHOULD” to “MAY”. In > most cloud services, the first client is registered by a human > user. Then, other clients can be further used to > automate other client registration. So, the first request > would typically come with an authenticated user identity. > > I think the weight of "SHOULD" is appropriate here, because I > believe that turning off open registration at the AS (which is > what this is talking about) really ought to be the exception > rather than the rule. > > I think you are reading it wrong -- a double-negative issue. The > end of the sentence is "no authentication". You are implying that > NO Authentication us what should normally be done. I think you > intend anonymous authentication to be the exception rather than > the rule don't you? > > No, I think that anonymous authentication should be the rule. Open > registration should be default. > > I disagree. Again, the spec seems contradictory. It suggests strong > client auth methods and at the same time anonymous registration. Yes > you gain uniqueness, but that's about it. > > > On the flip side, the earlier paragraph: > > “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.” > > I tend to think it would be better to change this “MAY” to “SHOULD”. > > That access token would carry a human user authenticated identity > somehow. In some cases, it can be a pure authenticated user > assertion token. > > Again, disagree, for the same reasoning as above. > > Same reasoning. > > > I agree with Justin here. The default should be that open > registrations are enabled. The exception case is that specific > permissions are required to perform dynamic client registration. > > [PH] I'm not sure I understand your last sentence. It seems to > contradict your position. If you need specific permissions, then > surely you can't be anonymous??? > > [mbj] More clearly put, it should be an exception for the party > wanting to register a client to have to obtain special permissions up > front to register the client. In the normal case, the party wanting > to register a client should require no special up-front permissions. > [JR] To reiterate, the text is correct as it stands. Unauthenticated registration should be the norm. Authenticated registration is the exception. This is intentional. > > *About section 4.3:* > > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used to > make this request SHOULD be immediately revoked. > > If the Client does not exist on this server, shouldn't it return a > "404 Not Found"? > > If revoking the registration access token, is it bound to a single > client registration? This is not clear. What is the lifecycle around > registration access token? Only hint is in the Client Information > Response in section 5.1. > > The language about the 401 here (and in other nearby sections) is > specifically so that you treat a missing client and a bad registration > access token the same way. You see, returning a 404 here actually > indicates things were in an inconsistent state. Namely, that the > registration access token was still valid but the client that the > registration access token was attached to doesn't exist anymore. The > registration access token in meant to be tied to a client's instance > (or registration), so it's actually more sensible to act as though the > registration access token isn't valid anymore. In at least some > implementations (specifically ours at MITRE that's built on SECOAUTH > in Java), you'd never be able to reach the 404 state due to > consistency checking with the inbound token. > > Since the intent of the registration access token is that it's bound > to a single instance, its lifecycle is generally tied to the lifecycle > begins at the issuance of a new client_id with that instance. That > token might be revoked and a new one issued on Read and Update > requests to the Client Configuration Endpoint (and the client needs to > be prepared for that -- same as the client_secret), and it will be > revoked when the client is deleted either with a Delete call to the > Client Configuration Endpoint or something happening out-of-band to > kill the client. > > Should we add more explanatory text to the definition in the > terminology section? Elsewhere? I'm very open to concrete suggestions > with this, since I don't think it's as clear as we'd like. > > I think we should look at it. > > > For security reasons, it’s generally not good to distinguish between > “not found” and “unauthorized” errors in responses, as that can > provide the attacker an oracle to probe whether a particular entity > exists I don’t think a change is called for here. > > [PH] I agree in principle. This issue is bound up too in what the > life-cycle of the registration and the access token and client tokens. > We need to describe those first before this becomes clear. For > example, if the client is still authenticated, but its registration is > gone, it should be not found. But I agree this doesn't make sense, > because the "implied" action was that the deletion of a registration > invalidates all associated credentials. ---> meaning the client should > never be able to authenticate with the registration endpoint anyway. > > [mbj] By the way, you writing that “the client should never be able to > authenticate with the registration endpoint anyway” makes the case for > why the permissions on the client’s registration endpoint are > different than those granted to the client – hence the need for the > registration_access_token. > > > *About section 5.1:* > > Is registration_access_token unique? Or is it shared by multiple > instances? If shared, then registration_access_token can't be > revoked on delete of client. > > The registration_access_token is unique to a registered client, in the > RFC 6749 sense of “client”. Again, if we want to do work on “client > instances”, we need to recharter and take this distinct work item up > explicitly. > > [PH] Disagree. I think it is well within charter and in fact a > foundational requirement. > > [mbj] I interpret your comment above as part of your desire for the > working group to define OAuth Client Instance Management > functionality. Again, that’s bigger than just registration. > [JR] Agree with Mike -- this is way bigger than just a registration parameter. > > Suggest rename “expires_at” to “client_secret_expires_at”, > > Suggest to rename “issued_at” to “id_issued_at” > > While I do like the suggestion of changing these to > client_secret_expires_at and client_id_issued_at, and I think > these are more clear and readable, > > > > > I don't want to change the syntax during last call unless there is > a clear need and a clear consensus for doing so. > > That's why we are having last call. To confirm consensus on the > draft. > > Same reasoning as earlier. You now have multiple tokens > (registration access and client) in play. The spec needs to be > clear which one it is talking about. > > I'm fine with the suggested change but I would like more feedback > from other people before moving forward with it. There's a lot of > value in "just pick a name and ship it" as well though, and I > don't want to devolve into bike shedding. (I'm not accusing you of > bike shedding quite yet, btw, just afraid of getting into a long > debate on names.) > > Again, this was a problem raised by people new to the > specification. They found it confusing. I tend to agree. We're not > talking about what colour to paint the shed. We're talking about > whether the bike shed is a house. :-) > > I'm not too fussed about whether you call it "cl_sec_expiry" or > "client_secret_expires_at". > > > If the definitions of “expires_at” or “issued_at” are unclear, we > should clarify them. If you believe that this is the case Phil, > can you supply proposed alternative definition text that is > clearer? That being said, I believe that at this point we should > stick with the existing protocol element names unless overwhelming > working group sentiment emerges to change them. They are already > working fine as-is in production deployments. > > [PH] I'm just reporting the confusion people have had with ambiguity. > [JR] As above, I am very hesitant to change syntax without a lot of direct feedback from developers as to how it would affect them. Wearing my own developer hat, I'm willing to make the change. But I can't speak for the rest of the community, so I'm going to start a new thread. > *Section 7* > > When a client_secret expires is it the intent that clients do > an update or refresh to get a new client secret? > > Yes, the client is supposed to either call the read or update > methods on the client configuration endpoint to get its new > secret. As discussed above, I'm not sure that's as clear as it > needs to be, and I welcome suggestions on how to clarify this. > > Either is a reasonable behavior on the behalf of clients, > depending upon context. I support adding text to clarify this. > > Again, thanks for the very thorough read through. Have you > implemented any of the spec yet, either as-is or with any of > your suggested changes? > > Yes. Much of the feedback is coming from our development community. > > Ah, very cool. Developer experience is the most valuable feedback, > in my opinion. If you can't actually build the blasted thing, what > good is it? :) > > Glad to hear that you’re working with developers building the > spec. Please thank them for the feedback. > > -- Justin > > Best wishes, > > -- Mike > > [PH] Thankss. > --------------030208060002080301080103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Since the various mail clients that people use have been wreaking havoc with the threaded nesting of this discussion, I'm prepending my newest comments with [JR] below.

 -- Justin

On 05/17/2013 08:01 PM, Mike Jones wrote:

My replies are in green and marked [mbj].

 

                                                            -- Mike

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 17, 2013 2:24 PM
To: Mike Jones
Cc: Richer, Justin P.; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

 

I have started a separate thread on having dyn reg correlate client software.

 

My other comments are embedded marked with [PH].  

 

 



 

On 2013-05-17, at 1:08 PM, Mike Jones wrote:



Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…

 

(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

 

Justin,

 

Thanks for the discussion. More comments below...

 

BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.

 

 

On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:

 

On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>

 wrote:

 

On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:

 

Phil, many thanks for the extremely thorough review! It is very useful indeed. 

 

My comments and responses to each point are inline. 

 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.

 

Overall  

-----------

I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.

 

The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:

 

1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?

 

In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 

 

I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.

 

But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?

 

I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)

 

I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.

 

In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.

 

What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).

 

While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.

 

[PH] See new thread I have begun.

 

2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?

 

The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 

Something like this should be in the draft.

 

Should this be up in the introductory text, somewhere else, or have its own section?

 

I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.

 

I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.

 

How does a client authenticate the first time and subsequent times to the registration service?

 

This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:

  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)

 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.

 

Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.

 

Something like this should be in the draft.

 

OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.

 

See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.

 

3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.

 

This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.

 

I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.

 

If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 

I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.

 

I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  

 

One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+

 

Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.

 

[PH] We disagree strongly here.  I think it is well within charter and in fact if such a new charter item were developed we would be quickly moving to replace dyn reg version 2.

[mbj] Per my comments on the new thread you started, we wouldn’t be replacing the existing dynamic registration spec – we’d be creating a new OAuth Client Instance Management spec, once piece of which would be defining the 5% extensions needed to use it for that use case.  (And also per my comments on that thread, I’m sure that the registration bits wouldn’t be all that would be in that spec – they’d probably only be a small part of it.)


[JR] And if this new work were to start up, I think that the BB+ protocol for managing client classes and instances would be a good place to start, or at least learn from what we're doing in there. As Mike points out, the registration is actually a very small part of what's needed, and BB+ doesn't actually define any new registration parameters. There is a whole other layer of service discovery and vetting of client parameters that happens in BB+, though, that don't make sense to cram into OAuth Dyn Reg. As I've stated in a previous message, a simple client-generated UUID *cannot* be sufficient for tying multiple clients together, the race conditions between multiple auth servers alone make it completely unusable. Which is to say, it's a more complex problem than it seems on its surface, and it deserves to get a good amount of attention and be actually engineered and solved appropriately.

 

4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?

 

See the response above above and the definition in §1.2: 

 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.

 

If this can be clarified, I welcome text suggestions.

 

The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.

 

Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.
 
   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.

 

This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?

 

Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?

 

If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.

 

When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.

 

I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?

 

We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.

 

I haven't heard a reason justifying this parameter other then "it is needed".  Why?

 

The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 

 

And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 

 

I think we've discussed how recognizing subsequent instances is easily done.

 

As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.

 

My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?

 

And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.

 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 

See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.

 

Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?

 

That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.

 

Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 

 

One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.

 

There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 

 

If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.

 

ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.

 

Specific items:

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

"token_endpoint_auth_method"

 

There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"

 

This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.

 

The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)

 

Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.

 

I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.

 

[PH] I don't think we're changing any syntax here. Just clarifying the name. This seems important now that there are 3 types of tokens being managed (registration, client, access).  

 

I would much prefer just dumping the registration access token rather then renaming parameters that would otherwise be unclear.

[mbj] Changing a name is changing the syntax. 


[JR] Agreed w/Mike, and this applies to all of the suggested name changes: token_endpoint_client_auth_method, client_id_issued_at, client_secret_expires_at. It's not that I disagree with the new names (the latter two are actually markedly better), it's that I don't want to change syntax without a chorus of developers here on the list saying that the new syntax would be better for *them*. Editorial changes, like expanding the explanatory text for these parameters, are another matter and can be made without breaking running code.

That said, I *really* want to hear from people who are building and deploying this right now to see if the suggested syntax changes would be good, bad, or neutral to them. I think I should perhaps start another thread on just that topic, since this important point might be getting lost in this wall of text.

As for dumping the registration access token, given that the registration access token is used by the code author to access one resource and the client_id is used by the code to access a different resource, and that the security characteristics of the two kinds of access are very different, I believe it would be a security and usability disaster to try to blend them together.


[JR] This is a completely separate issue, and as Mike points out, the client_id, client_secret, and registration_access_token serve completely different purposes. If those purposes are unclear, we can explain them. Deleting any of these or merging them is a terrible idea.

 

* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.

 

I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.

 

I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.


Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.

 

This is the heart of my objection. This fuzziness is is going to lead to interop issues.

 

There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 

 

The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.

 

The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.

 

The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.

 

[PH] Agreed.

 

Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).

 

I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.

[PH] So, given the above, the client shouldn't be dictating token type. The AS should simply assign the credential and inform the client what it must use.

[JR] How can a public client tell the AS that it doesn't want a client_secret, and can't reasonably protect it? How can a client that wants to do some kind of holder-of-key

 

[mbj] You seem to be (intentionally?) ignoring John Bradley’s point that it’s the client that knows which of the security profiles supported by the AS that it needs to use – not the AS.  Therefore, for security reasons, it must be the client that picks the method from among those supported by the AS – not the other way around.  The AS has no way to know which methods are appropriate for which clients, but the clients do.

 

We agree, no discovery.  But I also want to eliminate negotiation that doesn't actually help anything.

[mbj] I’m not describing negotiation above.  I’m describing the party with the knowledge to make the appropriate choice being able to make that choice.

 

That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.

 

OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.

 

I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.

 

Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.

 

[PH] Agreed. Let's remove the parameter.in the request. It should only be in the response.

 [mbj] Removing the parameter would make it impossible for the client, which knows which security profile it needs to use, to declare to the AS which method, from among the methods supported by the AS, that it needs to use.  The client MUST be the one doing the choosing.

[JR] Again, see above note about public clients. The server knows nothing about the client before it shows up, including what the client believes it can protect. Registration on this parameter is the client saying "I can do this", and the server's response is "you may do this". Both are distinct and necessary.

 

* There is no authn method for "client_secret_saml" or "private_key_saml".

 

Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?

 

I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.

 

There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.

 

The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.

 

Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)

 

Regardless, you are introducing a new profile which is undefined.

 

I think I see the point that you're making now, let me try to re-state it:

 

While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).

 

I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.

 

I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.

 

The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.

 

So for example, you need a draft like the MAC draft for this. 

 

I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?

 

There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.

 

I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.

 

6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.

 

What you are describing is not bearer. It is holder of key. Very very different. 


A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.

 

That's possible, but they are in active use already. 

 

That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.

 

This much I agree with.

 

Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.

 

About "tos_uri" and "policy_uri"

 

The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?

 

Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.

 

Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.

 

OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)

 

I support clarifying the language on these definitions, and will work with Justin to do so.

 

Also, aren't these really URIs or are they meant to be URLs?

 

There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.

 

Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.

 

That's fair, and it's something that the AS can even check if it wants to.

 

Agreed on this clarification.

 

About "jwks_uri"

 

A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 

 

Yes, you're correct, I'll add that.

 

Should be URL instead of URI?

 

See above. :)

 

Agreed on adding this reference.

 

Section 2.1

 

In the table urn:ietf:params:oauth:grant-type:jwt-bearer

is missing.

 

It's there in the copy of -10 I'm reading off of ietf.org right now … ?

'

Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer

 

Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.

 

“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?

 

I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.

 

I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.

[PH] Agreed.

 

Section 2.2

 

May want to add:

 

When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.

 

That seems inconsistent with what we already have:

 

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.

 

Which is to say, treat it as a raw byte-value-string and don't try to get fancy.

 

I will discuss with our developers. I'm not sure the as-is works.  

 

Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?

 

Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?

 

 

No, the client should pass parameters as multiple separate values. Connect has this in its example:

 

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",

Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)

 

An example would definitely help.

If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.

 

Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 

 

I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.

 

Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?

 

----> any multi-lingual people have any opinions here?

 

Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.

 

[PH] I agree. I plan to follow up and see if I can't get more clarification on requirements from my side. 

 

Section 3

 

Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 

 

I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 

 

I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?

 

No, I think that anonymous authentication should be the rule. Open registration should be default. 

 

I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.


On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.

 

Again, disagree, for the same reasoning as above.

 

Same reasoning. 


I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

 

[PH] I'm not sure I understand your last sentence. It seems to contradict your position. If you need specific permissions, then surely you can't be anonymous???

[mbj] More clearly put, it should be an exception for the party wanting to register a client to have to obtain special permissions up front to register the client.  In the normal case, the party wanting to register a client should require no special up-front permissions.


[JR] To reiterate, the text is correct as it stands. Unauthenticated registration should be the norm. Authenticated registration is the exception. This is intentional.


About section 4.3:

 

If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

 

If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.

 

The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.

 

Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 

 

Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.

 

I think we should look at it.


For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

 

[PH] I agree in principle. This issue is bound up too in what the life-cycle of the registration and the access token and client tokens. We need to describe those first before this becomes clear.  For example, if the client is still authenticated, but its registration is gone, it should be not found.  But I agree this doesn't make sense, because the "implied" action was that the deletion of a registration invalidates all associated credentials. ---> meaning the client should never be able to authenticate with the registration endpoint anyway.

[mbj] By the way, you writing that “the client should never be able to authenticate with the registration endpoint anyway” makes the case for why the permissions on the client’s registration endpoint are different than those granted to the client – hence the need for the registration_access_token.


About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.

 

The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

 

[PH] Disagree. I think it is well within charter and in fact a foundational requirement.

 

[mbj] I interpret your comment above as part of your desire for the working group to define OAuth Client Instance Management functionality.  Again, that’s bigger than just registration.

[JR] Agree with Mike -- this is way bigger than just a registration parameter.


Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”

 

While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,




I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.

 

That's why we are having last call. To confirm consensus on the draft. 

 

Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.

 

I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)

 

Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 

 

I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 


If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.

 

[PH] I'm just reporting the confusion people have had with ambiguity.


[JR] As above, I am very hesitant to change syntax without a lot of direct feedback from developers as to how it would affect them. Wearing my own developer hat, I'm willing to make the change. But I can't speak for the rest of the community, so I'm going to start a new thread.

 

 

 

Section 7

 

When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?

 

Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.

 

Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.

 

Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?

 

Yes. Much of the feedback is coming from our development community. 

 

Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)

 

Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.

 

 -- Justin

 

                                                            Best wishes,

                                                            -- Mike

 

[PH] Thankss.

 


--------------030208060002080301080103-- From jricher@mitre.org Mon May 20 08:09:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5C21F89FF for ; Mon, 20 May 2013 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf0SxEtIfxZl for ; Mon, 20 May 2013 08:09:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5A5D21F88D8 for ; Mon, 20 May 2013 08:09:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 16CCD1F046E for ; Mon, 20 May 2013 11:09:43 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E6AAA1F0666 for ; Mon, 20 May 2013 11:09:42 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:09:42 -0400 Message-ID: <519A3C9A.8060305@mitre.org> Date: Mon, 20 May 2013 11:09:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------060602010402030306040004" X-Originating-IP: [129.83.31.56] Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:09:53 -0000 --------------060602010402030306040004 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, *especially from developers* who have deployed this draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now. Naming things is hard. -- Justin --------------060602010402030306040004 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin
--------------060602010402030306040004-- From phil.hunt@oracle.com Mon May 20 08:21:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0582621F9362 for ; Mon, 20 May 2013 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5gyWvlZuRGK for ; Mon, 20 May 2013 08:21:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA0421F930A for ; Mon, 20 May 2013 08:21:16 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KFLD89029583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 15:21:14 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KFLEpt012380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 15:21:15 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KFLESp012367; Mon, 20 May 2013 15:21:14 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 08:21:14 -0700 References: <519A3C9A.8060305@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519A3C9A.8060305@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-FB6F6AC3-8036-47B7-9780-ACB4D4134425 Content-Transfer-Encoding: 7bit Message-Id: <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Mon, 20 May 2013 08:21:10 -0700 To: Justin Richer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:21:22 -0000 --Apple-Mail-FB6F6AC3-8036-47B7-9780-ACB4D4134425 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Keep in mind there may be other changes coming.=20 The issue is that new developers can't figure out what token is being referr= ed to.=20 Phil On 2013-05-20, at 8:09, Justin Richer wrote: > Phil Hunt's review of the Dynamic Registration specification has raised a c= ouple of issues that I felt were getting buried by the larger discussion (wh= ich I still strongly encourage others to jump in to). Namely, Phil has sugge= sted a couple of syntax changes to the names of several parameters.=20 >=20 >=20 > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >=20 >=20 > I'd like to get a feeling, especially from developers who have deployed th= is draft spec, what we ought to do for each of these: >=20 > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify >=20 > In all cases, clarifying text will be added to the parameter *definitions*= so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned, since we s= houldn't change syntax without very good reason to do so. That said, if it's= going to be better for developers with the new parameter names, I am open t= o fixing them now. >=20 > Naming things is hard. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FB6F6AC3-8036-47B7-9780-ACB4D4134425 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Keep in mind there may be other changes coming. 

The issue is that new developers can't figure out what token is being referred to. 

Phil

On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-FB6F6AC3-8036-47B7-9780-ACB4D4134425-- From jricher@mitre.org Mon May 20 08:35:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2E21F934B for ; Mon, 20 May 2013 08:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAC4Jq1wQ2fZ for ; Mon, 20 May 2013 08:35:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0308C21F90F1 for ; Mon, 20 May 2013 08:35:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5E5681F06D5; Mon, 20 May 2013 11:35:45 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 228F31F0663; Mon, 20 May 2013 11:35:45 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:35:44 -0400 Message-ID: <519A42B4.2020803@mitre.org> Date: Mon, 20 May 2013 11:35:16 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040900050803070301040605" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:35:47 -0000 --------------040900050803070301040605 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit On 05/17/2013 05:27 PM, Phil Hunt wrote: > Mike, > > Rather then embed comments in an extended thread, I'd like to open up > a specific discussion on the objective of dyn reg. > > I see limited to no value in having clients completely anonymously > registering and receiving tokens without any ability to correlate > applications between applications. I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that. From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server. A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically: - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id. - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id. Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine. > > Associating client_id's with known client applications to allow admins > to know who is running what version of clients seems to be the most > fundamental part of the reason for dynamic reg. How can you revoke > access to particular client app types? As Justin already talked about > in his Blue Button+ scenario, there are often life and death > situations where particular sets of clients need to be revoked. While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process. > > Or put another way. I believe this will be a critical operational > requirement going forwards. If the spec is published as is, it will be > quickly invalidated by one that does at least partially address the > problem. That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here: http://blue-button.github.io/blue-button-plus-pull/ Just because you make something better doesn't mean you throw necessarily away everything you've done to date. > > We're ahead of schedule, lets talk through the requirement. I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle. > > As I mentioned in my comments to the other thread. Let's say we agree > not do this now. Well, then the new draft that does solve it would > likely be 95% overlap. Thus I see this issue as within charter and > should be solved now rather then waiting for a V2 dyn reg in the next > charter. Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not. -- Justin > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-17, at 1:08 PM, Mike Jones wrote: > >> Thanks for the detailed feedback, Phil. Sorry for the delayed >> response -- I was pretty fully engaged at the European Identity >> Conference (whereOAuth 2.0 won the award for best new standard >> J). My feedback on the points raised >> is inline in green... >> (Perhaps if any of you reply to this thread, you could also choose a >> distinctcolorfor your inline replies, so that it will be easily >> evident who said what. As it is, just the back-and-forth between >> Phil and Justin is already very difficult to follow. Thanks.) >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org]*On >> Behalf Of*Phil Hunt >> *Sent:*Thursday, May 16, 2013 12:54 PM >> *To:*Richer, Justin P. >> *Cc:*oauth@ietf.org WG >> *Subject:*Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 >> Justin, >> Thanks for the discussion. More comments below... >> BTW. I'm happy to contribute text. Just want to get to some rough >> agreement first. For example, I think we need to have a away to >> recognize two pieces of software as being the same (even if >> self-asserted). Once defined, I can put together some intro text, etc. >> Phil >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >> On May 15, 2013, at 10:30 PM, Phil Hunt > > >> wrote: >> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >> Phil, many thanks for the extremely thorough review! It is very >> useful indeed. >> My comments and responses to each point are inline. >> On May 15, 2013, at 4:30 PM, Phil Hunt > > wrote: >> It seems unfortunate that I have not gotten a chance to get into this >> level of detail much earlier. But then, I guess that's what LC review >> is for! My apologies for not getting many of these concerns to the WG >> much earlier. >> */Overall /* >> ----------- >> I think dynamic registration is a critical part of the OAuth >> framework now that we are starting to consider how individual client >> applications should operate when there is one or more deployments of >> a particular resource API. We've moved from the simple use case of a >> single API provider like Facebook or Flickr and moved on to standards >> based, open source based, and commercial based deployments where >> there are multiple service endpoints and many clients to manage. >> The dynamic registration spec is actually dealing with a couple of >> issues that I would like to see made more clear in early part of the >> spec: >> 1. How is a new client application recognized for the first time >> when deployed against a particular SP endpoint? Should clients >> actually assert an application_id UUID that never changes and >> possibly a version id that does change with versions? >> In the general case, why is any recognition required? If you're doing >> things as part of a larger protocol ecosystem, like Blue Button+ or a >> particular OpenID Connect provider, then you can define semantics for >> tying together classes of clients (see below for more discussion on >> this very point). But in general, a client is just going to show up >> as a new instance to the AS and get issued a new, unique client_id, >> and that's that. >> I think we have to define more clearly what an "instance" is. For me, >> there are applications and there are instances of that application. >> It is useful to understand that a client application represents a >> set of code that should behave in a consistent way. It seems to me >> the first time a new application shows up is very different from the >> subsequent instances that register. For example, after the first >> registration, subsequent instances don't need special review or >> approval to the same degree. >> But without other mechanisms to tie things together, there's no way >> for an authorization server to know if any client instance is tied to >> any other client instance. Therefore, from the perspective of an AS, >> the first instance of an application (i.e., particular configuration >> of a set of code) to register is no different to subsequent instances >> of that same application. How were you envisioning an AS knowing the >> difference between the first and subsequent instances of an >> application, specifically? If there's an "application_id" like you >> mention above, I think it raises more questions than it resolves: Who >> issues the application_id, some server or the application itself? Is >> it validated at all? Should it be considered secret? What happens >> when someone simply steals an application_id? Does an AS have to do >> anything to check with any other AS to see if the application_id has >> already been used elsewhere? >> I do agree that a discussion of "instance vs. application" would be >> helpful in clearing this up, I'll make a note to add text to that >> effect. (We had to do something similar for BB+) >> I think it is simple enough to at least add a self generated UUID for >> the application ID. Though I would allow for cases where the >> application ID is assigned when the client developer and the APIs >> owner do a formal assignment of application IDs. >> In a sense this is just a lower tech way of doing it than what you >> described as the initial client credential in Blue Button+ where you >> encoded extra claims into the initial app credential. >> What the UUID does is link multiple instances of a client app >> together as the same "thing" that should have similar >> heuristics/behaviours. This is very useful if you want to be able to >> revoke access to a set of clients identified by application id (or a >> version of that app). >> While I'm sympathetic to the OAuth working group eventually doing >> work on differentiating between instances of an OAuth client, I'll >> note that in RFC 6749 or RFC 6750 there is no such thing as a client >> instance. There are only clients, which are identified by client_id >> values. If we want to do work on client instances, we should >> recharter to add this new work as a working group deliverable. We >> should not try to shoehorn bits and pieces of it into the Dynamic >> Registration spec, any more than we should have tried to shoehorn it >> into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients >> as defined in RFC 6749. It's not the right place to extend what an >> OAuth client is in new ways. >> >> 2. How are client credentials managed. Are we assuming >> client credentials have a limited lifetime or rotation policy? >> The intent was that client_secret could be rotated, as >> indicated by the expires_at member of the response. If a >> client's secret expires, it calls the read operation on the >> Client Configuration Endpoint (4.2) to get its new >> client_secret. If this is unclear in the current text (which >> I suspect it may be after multiple refactorings), then I >> welcome suggestions and specific text as to how to make that >> clear. >> >> Something like this should be in the draft. >> Should this be up in the introductory text, somewhere else, or >> have its own section? >> >> I'm starting to think credential management is a key part of the >> draft. It may be worth introducing a specific section outling the >> registration life-cycle, registration access token usage, and client >> token usage and bootstrapping. >> I think that adding a discussion on this would be fine, as it could >> help developers understand the workflow of registering, using, and >> updating registered clients. >> >> How does a client authenticate the first time and subsequent >> times to the registration service? >> This is a separate question all together, as it does not involve >> the client_secret or client_id at all. Rather, the first time the >> client shows up to the registration service, it may either: >> - Not authenticate at all (this is the true public, open >> registration, and it is recommended that servers do this) >> - Authenticate using an OAuth 2.0 token (which ATM means a >> bearer token). How the client gets that bearer token and what the >> bearer token means to the AS beyond "this client is authorized to >> register" is out of scope for the spec, by design. >> Subsequent times that the same registered client (by which we >> mean the same instance of a client with a particular client_id) >> shows up at the registration endpoint (actually, the Client >> Configuration Endpoint), it uses its Registration Access Token >> that it was issued on initial registration. This is an OAuth 2.0 >> Bearer token that is unique to the client instance. >> >> Something like this should be in the draft. >> OK, the definition of the registration access token can be expanded, >> but I think that the rest of it is already in there in 3. I'd >> welcome suggestions on which bits of this could be made clearer. >> See the discussion on what the registration_access_token is in the >> thread "Client Credential Expiry and new Registration Access Token - >> draft-ietf-oauth-dyn-reg-10". I will work with Justin to apply these >> clarifications to the specification. This may go into the proposed >> credential management overview section discussed above. >> >> 3. How is versioning of clients managed? Should each new >> version of a client require a change in client registration >> including possibly changing client_id and authentication >> credential? I don't have a strong feeling, but it is >> something that implementors should consider. >> >> This is up to the AS, really, and I don't think that any global >> policy would ever fly here. Especially if you consider that the >> entire notion of "version" is more fluid these days than it ever >> has been. I wouldn't mind adding a discussion in the security >> considerations if it merits mentioning though, so that we can >> help both client developers and server developers institute >> reasonably good policy. >> >> I guess the issue is that when a client upgrades it may have access >> to the old credentials. What is the intent then of registration. >> Since you have an update are clients expected to update /re-register >> or not? I'm not sure this is a security consideration but more part >> of the whole change management function dynamic registration supports. >> If your upgraded version of the client still has access to its old >> credentials, why wouldn't it just use those? I don't see a reason for >> forcing a re-registration. Nor do I see any way that an AS would even >> be able to tell that a client had been upgraded. An upgraded client >> always has the *option* of re-registering itself and getting a new >> client_id. >> I think the concern here is that rotation of client credential is not >> something discussed before. Before we put it in the spec we should >> consider the reasons for doing it and what problems it solves. >> I think this may be just a case of letting people exchange >> credentials for whatever reason they feel is appropriate. The >> version upgrade thing suggests that when a client is upgraded it >> should go to the registration server to "re-register". Depending on >> the policy of the server, it may (or may not) receive a new client_id >> and/or new credential. >> One of the best benefits I can think of is if you discover a version >> of a client has a problem, being able to select a group of clients by >> software and version is important. Thus if client_id doesn't trace to >> a particular software and version, that makes it hard to do. I >> think you talked about this as an issue for Blue Button+ >> Again, RFC 6749 defines no client instances or groups of clients, >> therefore I believe that it's inappropriate to do so here. We don't >> need to boil the ocean. If a new charter item is approved to do work >> on client instances and protocol elements to use and express them, >> that's the time for the working group to consider that possibility -- >> not as part of Dynamic Client Registration. >> >> 4. What is the registration access token? Why is is used? What >> is its life-cycle? When is it issued, when is it changed? When >> is it deleted? >> See the response above above and the definition in 1.2: >> >> Registration Access Token: An OAuth 2.0 Bearer Token issued >> by the Authorization Server through the Client Registration >> Endpoint which is used by the Client to authenticate itself >> during read, update, and delete operations. This token is >> associated with a particular Client. >> >> If this can be clarified, I welcome text suggestions. >> >> The latter part of 1.2 didn't seem like terminology but rather >> architecture or part of the introduction that describes what the spec >> does. The third point doesn't seem to fit with the other two except >> to say that the dynamic registration endpoints use their own access >> tokens called registration access tokens. >> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >> a Client can request new registration. The means of the Client >> obtaining the URL for this endpoint are out of scope for this >> specification. >> >> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >> which a specific Client can manage its registration information, >> provided by the Authorization Server to the Client. This URL for >> this endpoint is communicated to the client by the Authorization >> Server in the Client Information Response. >> >> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the >> Authorization Server through the Client Registration Endpoint >> which is used by the Client to authenticate itself during read, >> update, and delete operations. This token is associated with a >> particular Client. >> This section is meant to just introduce the new terms that are then >> explained in greater detail throughout the rest of the document. Yes, >> it's a bit architecture, but only in the sense that you need to >> define the terms that make up your architecture. How would you >> suggest that it change? >> Probably this is more a matter of style. But, what happened for me >> is I naturally skipped the terminology section, as I wasn't expecting >> protocol components to be there. "terminology" is something I think >> people tend to use as a dictionary rather than as protocol component >> description. Maybe the chairs can advise? >> >> If we distinguish between first time registration of a particular >> client software package, it is possible that somethings like >> authentication method can be negotiate in or out-of-band at that >> time. Subsequent registrations should only have parameters for >> items that could change per deployment (like tos_uri). I think >> token_endpoint_auth_method is one thing that should not be >> negotiated per instance. >> >> When subsequent instances register, I have to ask the >> question, for example when would things like >> "token_endpoint_auth_method" be negotiated or be different >> for the same client software? Should not all instances use >> the same authentication method. >> >> I'm confused by this -- as far as the dynamic registration spec >> is concerned, all instances are separate from each other. All >> parameters change per instance. And instance, you should keep in >> mind, is defined as any one copy of the client code connecting to >> any new authorization server. That pairing creates the client_id, >> and therefore the instance, and therefore the registration access >> token, and therefore the registration itself at a conceptual >> level. So there is no way other than per-instance for a client to >> ask for a particular token_endpoint_auth_method. Where else would >> the AS find out about it? >> >> We still disagree on this. It is my assertion that clients should >> NEVER ask for a particular token auth method. Since it is the AS that >> is authenticating the client, then it is the AS's right to set the >> authentication policy. The role of dynamic reg endpoint is to inform >> the client what it must do. My assumption is that during the first >> time a piece of software is registered (the first instance), there >> could be some OOB discussion by an administrator to approve the >> particular authentication type for the AS in question. >> I haven't heard a reason justifying this parameter other then "it is >> needed". Why? >> The role of the dynamic registration protocol is twofold: half of >> that is the server informing the client what it must do. But the >> other half is the client informing the server what it *can* do, or >> what it *wants* to do. >> And again, there's no way to distinguish a first instance from a >> subsequent instance unless you're doing something in addition. >> Nothing is stopping the same application from registering a new >> instance of itself for every single user or every single token that >> it wants to get access for. That's complicated and wasteful and not a >> great idea, sure, but there's no useful way to prevent that kind of >> behavior if you also want open registration of clients. >> I think we've discussed how recognizing subsequent instances is >> easily done. >> As I mentioned in the other thread, if a developer chooses to limit >> the capabilities of the client it must do so by looking to the >> developer or standard behind the API. Otherwise they are taking the >> chance. There's no way a developer can query all the potential >> deployers to ask what authn types will you use. As I said, the net >> effect in the absence of an API standard dictating what should be >> supported, the developer will have to implement all methods. >> My point here is that none of this is helped by the client app saying >> what it supports. A developer who takes the route of limiting >> implementation takes the chance that the server will not accept. So >> why negotiate within registration? >> >> And there's no way other than per-instance for the server to tell >> the client which token_endpoint_auth_method to use. All instances >> will probably ask for the same token_endpoint_auth_method from >> all auth servers they talk to, right? And each AS will tell each >> instance that registers with it to use a particular auth method. >> There is no way to tie together different instances across (or >> within) auth servers without specifying a significant amount of >> other machinery. >> >> Which is not to say that it's not useful in some circumstances to >> tie together different instances of the same code across (or >> within) auth servers. This is why, with Blue Button+, we >> specified a specific token format for the initial access token >> that the clients use to call the registration endpoint the first >> time, as well as a discovery protocol against a centralized >> server that handles pre-registration. All of this machinery is, >> in my opinion, a stupendous overkill for the general case, though >> if some folks find use for it outside of BB+ then it'd be a good >> thing to abstract out and make its own spec that extends the Dyn >> Reg spec in a fully compatible way. Furthermore, even in Blue >> Button+ we specify that all auth servers MUST also accept open >> registration, without an initial access token, where the client >> simply shows up and says "hey, here are my parameters." The auth >> server has no way to know in this case any kind of out-of-band >> negotiation for different things. In BB+ we are writing very >> specific policy guidelines about how to present the UX and things >> to the end user for all of these different cases. But again, all >> of this is specific to the BB+ use case, and I don't see value in >> dragging it in to the registration spec on its own. I believe it >> would be far too limiting. >> >> See my previous comments on differentiating client instances >> being out of scope without rechartering to do this new work and >> on what the registration_access_token is. In short, the >> registration_access_token is an RFC 6750 bearer token issued to >> the party registering the client, enabling it to subsequently >> retrieve information about the client registration and to >> potentially update the registration information for that >> registered client. Again, I'll work with Justin to make sure that >> this is as clear as possible in the specification. >> >> Finally, there seems to be an inconsistent style approach with >> draft-hardjono-oauth-resource-reg >> which >> uses ETags. Should this draft do so as well? >> That's an individual submission, not a working group draft. >> Nobody has, until now, even mentioned the use of ETags here. UMA >> (where the resource registration draft comes from) uses ETags, >> hence their inclusion there. I personally don't see their utility >> here, though, and I wouldn't want to include a wholly new >> mechanism this late. >> >> Yes. Thomas' draft is not a WG document. But that doesn't mean he >> doesn't have a point. It's worth discussing. >> One could argue that the point of an ETag is that it is useful for >> change detection when there are multiple writers to a particular >> resource. In the design of dynamic registration endpoint, there >> should only be one writer -- the client. This is an important >> observation. >> There are other mechanisms that handle this -- namely, the >> registration access token and the client_id. Many instances include >> the client_id in some form in the client configuration endpoint's URL >> for sanity checking, as described in 4.1. >> If everyone agrees, I'm in agreement. But it will likely mean changes >> for the resource reg draft if adopted. >> ETags seem like an unnecessary addition (and potential complication) >> to the specification. It's already working fine as-is. >> >> */Specific items:/* >> --------------------- >> *"token_endpoint_auth_method"* >> There is some confusion as to whether this applies to server or >> client authentication. Suggest renaming parameter to >> "token_endpoint_client_auth_method" >> This is the first I've heard of this particular confusion. I'm >> fine with either name but at this stage I don't want to make >> syntax changes without very, very compelling reasons to do so. >> >> The question was raised to me by some new developers. It seems >> obvious to us as experienced OAuth persons, but to new developers it >> seems unclear. Also, now that you are introducing registration >> authentication, the whole thing gets very confusing. So it is useful >> disambiguate all the parameters where possible. That said, I >> wouldn't mind shorter names (maybe not quite as short as the JOSE >> stuff ;-) >> Fair enough, but again, I only want to do syntax changes if the rest >> of the WG *really* wants to. >> I agree with Justin here. I'm fine clarifying the description of this >> parameter to resolve the potential ambiguities that you cite, Phil. >> I'm not OK revising the syntax without a compelling reason to do so. >> >> * Currently, the API only supports a single value instead of an >> array. If the purpose is to allow the client to know what auth >> methods it supports, this should be an array indicated what >> methods the client supports - or it should not be used. >> I would rather like this to be an array, personally, and brought >> it up with the OpenID Connect working group about six months ago. >> But there it was decided that a single value was simpler and >> sufficient for the purpose. The IETF draft has inherited this >> decision. I *believe* (though am not 100% positive) that I >> brought up this very issue in the WG here but didn't receive any >> traction on it, so single it remains. >> >> I can get behind multiple values. In this case, it changes the >> meaning of the parameter. Instead of the client forcing the server to >> use a particular method, the client is informing the server about >> what methods it can perform. This allows the server to assign the >> appropriate method based on its own policy. >> >> Also note that this field, like all others in 2, represents two >> things: the client telling the server "I want to use this value for >> this field", and the server telling the client "this is the value you >> have for this field". It's not exactly a negotiation, more like >> making a polite request to an absolute dictator who has the last word >> anyway. But at least this dictator is nice enough to tell you what >> their decision was instead of just decapitating you. >> This is the heart of my objection. This fuzziness is is going to lead >> to interop issues. >> There is no fuzziness that I can see here. It's parallelism between >> what goes in to the endpoint and what comes out of it. The semantics >> for the request and the response are different, and differentiable by >> the fact that one is a request and the other is a response. >> The inter-op issue I would like to point out is that the spec does >> not currently specify if particular input values are singular or >> multiple. If an implementer assumes singular and clients assume >> multiple, we have issues. >> The multiple/single discussion above gets to the heart of what I >> **do** believe is a deficiency in the specification, as it's >> currently written. The authors, myself included, have failed to make >> it 100% clear that discovery of Authorization Server functionality is >> out of scope for this specification. I strongly believe that we need >> to add a clear statement to this effect in the introduction to the >> specification. >> The purpose of the Dynamic Client Registration specification is for >> the client to register with the Authorization Server and to inform it >> of properties of the client that the AS may want/need to be aware >> of. It **is not** the purpose of this specification for it to be >> used by clients in any manner to discover features of the >> Authorization Server. That should be explicitly out of scope. >> Currently, clients are instructed by RFC 6749 to discover information >> about Authorization Servers they interact with by consulting the >> "service documentation" (RFC 6749, Sections 3.1 and 3.2). They can >> also learn information about Authorization Servers in specific >> contexts through discovery protocols such as OpenID Connect Discovery >> (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA >> Discovery (TBD). >> I suspect that at some point, someone in the OAuth working group will >> propose developing a generic OAuth discovery mechanism, which will >> lead to a rechartering to include this work in the working group's >> set of deliverables. I would support doing this work and the >> necessary rechartering to do so. >> That being said, I strongly oppose trying to shoehorn piecemeal >> aspects of discovery into the Dynamic Client Registration >> specification. It is distinct functionality and deserves first-class >> and separable treatment by the working group. Discovery is for >> potential clients to learn properties of the AS before registration. >> Registration is for potential clients to inform the AS of its >> properties, creating a registered client. Discovery sends >> information about the AS to the Client. Registration sends >> information about the Client to the AS. That's a clean separation. >> We should strongly resist muddying the two functions. >> OAuth 2.0 is a success because it didn't try to boil the ocean. It >> specified how to do one thing well in a simple, web-friendly manner. >> We should do the same -- focusing on specifying interoperable dynamic >> client registration, while making it clear that this is distinct from >> discovery about Authorization Server properties, and making it clear >> that discovery is out of scope for this work. >> I apologize at this point on behalf of myself and the other spec >> editors for not being 100% clear that discovery functionality is >> explicitly out of scope for Dynamic Client Registration. If we had >> done so, I'm sure that many of the current questions and confusions >> would not have arisen. I think we'd assumed that this was obvious, >> but from the current discussions, it's apparent that it's not >> obvious. I will personally commit to clarifying the specification at >> this point to eliminate this potential point of confusion. >> Getting back to the specifics, the only useful purpose of a >> multi-valued "token_endpoint_client_auth_method" member would be to >> enable the client to discover information about the authentication >> methods supported by the AS after the registration had been >> performed. But that is a discovery function, and so should be part of >> the discovery work -- not this specification. We should resist >> shoehorning in bits of discovery into this specification. It **is** >> a worthwhile topic, but deserves full consideration by the working >> group in its own right. Therefore, this member must remain >> single-valued, and be clearly specified as the method by which a >> client informs the AS which token endpoint authentication method it >> will use. Anything else would be scope creep, and result in an >> unnecessarily complicated specification and unnecessarily complicated >> clients. >> >> * There is no authn method for "client_secret_saml" or >> "private_key_saml". >> Nobody has really asked that these two be included or specified. >> The extension mechanism (using an absolute URI) would allow >> someone else to define these. Is the definition in the SAML >> Assertion draft sufficient for their use? >> >> I think this is coming from the fact that there is a JWT bearer draft >> and a SAML bearer draft. The truth is you are defining an >> authentication that isn't even defined. >> >> /There are no profiles referenced or defined for >> "client_secret_jwt" or "private_key_jwt". Neither of the JWT >> or SAML Bearer drafts referenced cover these types of flows. >> They only cover bearer flows. "client_secret_jwt" and >> "private_key_jwt" seem to have some meaning within OpenID >> Connect, but I note that OIDC does not fully define these >> either./ >> The JWT assertion draft does say how to use a JWT for client >> authentication, and the DynReg text differentiates between a >> client signing said JWT with its own secret symmetrically vs. >> a client using its own private key, asymmetrically. >> >> Actually my interpretation is the JWT draft assumes the JWT >> Bearer is a bearer token. The assumption is that if a client has >> the assertion it has the right to present it. IOW. The JWT >> Bearer Draft is most definitively not a JWT HoK Draft. :-) >> Regardless, you are introducing a new profile which is undefined. >> >> I think I see the point that you're making now, let me try to >> re-state it: >> While the basics of "how to present a JWT as a client credential" is >> defined here: >> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, >> it's not completely specified in that it doesn't fully restrict the >> signature secret source, the audience claim, and other things that >> the AS would need to check and validate. Right? The dynamic >> registration draft can define those cases in greater detail if needed >> (though I think it does so sufficiently as-is, I welcome more clarity). >> I'd be OK with adding the SAML bit, going into greater detail on the >> JWT bits, or dropping the JWT bits, if the WG wants to do any of >> those actions. My objection is that the JWT stuff is already in use >> and functioning and it'd be a shame to leave it out. >> I guess then the mistake the JWT Bearer and SAML Bearer drafts >> authors made is they assumed everyone had the same definition of >> bearer token. To me a bearer token opaque to the client. It >> therefore cannot do any signature work with regards to the token >> itself. Now, that's not to say a proof didn't occur between the >> client and the token issuer, but when the client wields the token, it >> is handling an opaque string. >> The concept of client_secret_jwt suggests an HoK profile. Therefore >> of course the bearer drafts are a little underspecified when it comes >> to HoK profiles. >> So for example, you need a draft like the MAC draft for this. >> I'm having trouble overall here. It seems the authn types suggest >> ONLY strong authentication for clients, yet during the registration >> process the current draft isn't able to correlate multiple instances >> of the same software (even in a self-asserted way). If you haven't >> authenticated the software at all, why have strong client auth? >> >> There is no authentication method defined for >> "client_bearer_saml" or "client_bearer_jwt" or >> "client_bearer_ref". Since the bearer specs say this is >> acceptable, the dynamic registration spec should accept >> these. >> I don't understand this bit -- where are these defined in >> RFC6750? I don't even know what client_bearer_ref would >> refer to. >> >> 6750 says you can use a bearer assertion (e.g. obtained from >> an IDP) and wield it as an authentication assertion. The >> client is NOT creating or modifying the assertion. The client >> is simply passing one it previously obtained. >> What you are describing is not bearer. It is holder of key. >> Very very different. >> >> A possible suggestion is to remove client_secret_jwt and >> private_key_jwt and define those as register extensions since >> these profiles are not defined. >> That's possible, but they are in active use already. >> That may be true. But then you need to write another draft so >> the rest of us can implement it in an interoperable way. Me >> I prefer not to guess what you are doing. >> >> This much I agree with. >> Justin, John, and I discussed this issue and agree with your >> suggestion, Phil. Since they are not completely specified, we >> will remove the client_secret_jwt and private_key_jwt methods >> from the specification and add a registry, enabling specification >> that do fully specify these and other token endpoint >> authentication methods, including potential methods using SAML >> assertions, to register them in the registry, rather than trying >> to bake them into the Dynamic Client Registration specification. >> >> *About "tos_uri" and "policy_uri"* >> The distinction between tos_uri and policy_uri is unclear. >> Can we clarify or combine them? >> Terms of service and policy are two different documents. One >> is something that a user accepts (generally describing what >> the user will do), one is a statement of what the service >> provider (in this case, the client) will do. More >> importantly, we used to have only one, and several people >> asked for them to be split. >> >> Several developers were confused by this. In particular they >> couldn't figure out which was used for what. Just passing along >> the feedback. >> OK, the distinction that I see is that the TOS is contractual, >> the Policy is a statement. Re-reading the definitions in there >> right now, that can be made much clearer. (It even looks like >> some OIDC text leaked into the definition of policy_uri and that >> hadn't been caught yet.) >> I support clarifying the language on these definitions, and will >> work with Justin to do so. >> >> Also, aren't these really URIs or are they meant to be URLs? >> There was already discussion about this on the list: The IETF >> is apparently trying to deprecate URL in favor of URI in new >> specs. So in practice they'll nearly always be URLs, but >> since all URLs are URIs we're not technically incorrect in >> following the new policy. And it makes the IESG less mad at >> us, which is a plus. >> >> Arg. Nice. Then the text should say the value passed must >> resolve to a valid web page, document, whatever. >> That's fair, and it's something that the AS can even check if it >> wants to. >> Agreed on this clarification. >> >> *About "jwks_uri"* >> A normative reference for >> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is >> needed. >> Yes, you're correct, I'll add that. >> Should be URL instead of URI? >> See above. :) >> Agreed on adding this reference. >> *Section 2.1* >> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >> is missing. >> It's there in the copy of -10 I'm reading off ofietf.org >> right now ... ? >> >> ' >> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >> Ah, that makes more sense. If the WG wants to add in SAML support >> to parallel the JWT support, I'd be OK with that. >> >> "As such, a server supporting these fields SHOULD take >> steps to ensure that a client cannot register itself into an >> inconsistent state." >> >> We may want to define more detailed HTTP error response. E.g. >> 400 status code + defined error code ("invalid_client_metadata")? >> I'd be fine with defining a more explicit error state in this >> case. I think it would help interop for the servers that want >> to enforce grant-type and response-type restrictions, but >> servers that can't or don't care about restricting grants >> types and whatnot don't have to do anything special. >> I **think** that this goes away with the deletion of >> client_secret_jwt and private_key_jwt in favor of the >> registry... I'll do a consistency check and verify that when >> the spec is updated accordingly. >> *Section 2.2* >> May want to add: >> When "#" language tag is missing, (e.g. "#en" is missing in >> "client_name", instead of "client_name#en") the OAuth server >> may use interpret the language used based on server >> configuration or heuristics. >> That seems inconsistent with what we already have: >> >> If any human-readable field is sent without a language >> tag, parties using it MUST NOT make any assumptions about >> the language, character set, or script of the string >> value, and the string value MUST be used as-is wherever >> it is presented in a user interface. >> >> Which is to say, treat it as a raw byte-value-string and >> don't try to get fancy. >> >> I will discuss with our developers. I'm not sure the as-is works. >> Is it the intent that when the client has localized "client_name" >> for example, it should pass all language variations in a JSON array? >> Or, should part of the registration be to indicate which >> interface language the client wishes to use? Then it only passes >> a single value for that registration? >> No, the client should pass parameters as multiple separate >> values. Connect has this in its example: >> >> "client_name": "My Example", >> >> "client_name#ja-Jpan-JP": >> >> "???????", >> >> Should we add that to at least one of the examples in DynReg? >> (The language tags are a late addition, so the examples don't >> reflect it.) >> >> An example would definitely help. >> >> If the client passes only a single unadorned field, the AS can't >> make any assumption about what language it is. Think of this as >> the internationalized value of the field while the language tags >> are the localized versions of the field. This is why we recommend >> that the bare-value always be sent by the client, so that in the >> lack of anything more specific, the AS can at least do >> *something* with it. >> Passing in a "default" language field (like default_locale or the >> like) is only going to lead to pain for implementors of both >> clients and servers, and it's going to hurt the interoperability >> of the human-readable fields. >> >> I think what I meant is since you are allowing each client to >> register different things, AND the client likely already knows the >> user's preferred language, why wouldn't the client just pass text >> values in one language and another parameter indicating preferred >> language in the case of any service generated text. >> Is the reason you are passing multiple localizations is so that you >> can use the preferred language of the resource owner rather then the >> client user? I wonder if that is correct. If the language >> preferences are in fact different, what would the user of the client >> app expect? >> ----> any multi-lingual people have any opinions here? >> >> Without specific proposed text changes to review, it's hard to >> know what to think about this comment. Unless a specific >> proposed text change is sent to the list with clear rationale for >> why it's better than what's there now and reviewed by the working >> group, I don't believe we should change the specification in >> response to this comment. >> >> *Section 3* >> Existing text: >> >> "In order to support open registration and facilitate >> wider interoperability, the Client Registration >> Endpoint SHOULD allow initial registration requests with >> no authentication. These requests MAY be rate-limited or >> otherwise limited to prevent a denial-of-service attack on >> the Client Registration Endpoint." >> >> I would suggest to change the first "SHOULD" to "MAY". In >> most cloud services, the first client is registered by a >> human user. Then, other clients can be further used to >> automate other client registration. So, the first request >> would typically come with an authenticated user identity. >> I think the weight of "SHOULD" is appropriate here, because I >> believe that turning off open registration at the AS (which >> is what this is talking about) really ought to be the >> exception rather than the rule. >> >> I think you are reading it wrong -- a double-negative issue. The >> end of the sentence is "no authentication". You are implying >> that NO Authentication us what should normally be done. I think >> you intend anonymous authentication to be the exception rather >> than the rule don't you? >> No, I think that anonymous authentication should be the rule. >> Open registration should be default. >> >> I disagree. Again, the spec seems contradictory. It suggests strong >> client auth methods and at the same time anonymous registration. Yes >> you gain uniqueness, but that's about it. >> >> >> On the flip side, the earlier paragraph: >> >> "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." >> >> I tend to think it would be better to change this "MAY" to "SHOULD". >> >> That access token would carry a human user authenticated identity >> somehow. In some cases, it can be a pure authenticated user >> assertion token. >> Again, disagree, for the same reasoning as above. >> >> Same reasoning. >> >> I agree with Justin here. The default should be that open >> registrations are enabled. The exception case is that specific >> permissions are required to perform dynamic client registration. >> >> *About section 4.3:* >> If the client does not exist on this server, the server MUST respond >> with HTTP 401 Unauthorized, and the Registration Access Token used to >> make this request SHOULD be immediately revoked. >> If the Client does not exist on this server, shouldn't it return a >> "404 Not Found"? >> >> If revoking the registration access token, is it bound to a single >> client registration? This is not clear. What is the lifecycle >> around registration access token? Only hint is in the Client >> Information Response in section 5.1. >> The language about the 401 here (and in other nearby sections) is >> specifically so that you treat a missing client and a bad >> registration access token the same way. You see, returning a 404 here >> actually indicates things were in an inconsistent state. Namely, that >> the registration access token was still valid but the client that the >> registration access token was attached to doesn't exist anymore. The >> registration access token in meant to be tied to a client's instance >> (or registration), so it's actually more sensible to act as though >> the registration access token isn't valid anymore. In at least some >> implementations (specifically ours at MITRE that's built on SECOAUTH >> in Java), you'd never be able to reach the 404 state due to >> consistency checking with the inbound token. >> Since the intent of the registration access token is that it's bound >> to a single instance, its lifecycle is generally tied to the >> lifecycle begins at the issuance of a new client_id with that >> instance. That token might be revoked and a new one issued on Read >> and Update requests to the Client Configuration Endpoint (and the >> client needs to be prepared for that -- same as the client_secret), >> and it will be revoked when the client is deleted either with a >> Delete call to the Client Configuration Endpoint or something >> happening out-of-band to kill the client. >> Should we add more explanatory text to the definition in the >> terminology section? Elsewhere? I'm very open to concrete suggestions >> with this, since I don't think it's as clear as we'd like. >> I think we should look at it. >> >> For security reasons, it's generally not good to distinguish between >> "not found" and "unauthorized" errors in responses, as that can >> provide the attacker an oracle to probe whether a particular entity >> exists I don't think a change is called for here. >> >> *About section 5.1:* >> Is registration_access_token unique? Or is it shared by multiple >> instances? If shared, then registration_access_token can't be >> revoked on delete of client. >> The registration_access_token is unique to a registered client, in >> the RFC 6749 sense of "client". Again, if we want to do work on >> "client instances", we need to recharter and take this distinct work >> item up explicitly. >> >> Suggest rename "expires_at" to "client_secret_expires_at", >> >> Suggest to rename "issued_at" to "id_issued_at" >> While I do like the suggestion of changing these to >> client_secret_expires_at and client_id_issued_at, and I think these >> are more clear and readable, >> >> >> I don't want to change the syntax during last call unless there is a >> clear need and a clear consensus for doing so. >> That's why we are having last call. To confirm consensus on the draft. >> Same reasoning as earlier. You now have multiple tokens (registration >> access and client) in play. The spec needs to be clear which one it >> is talking about. >> I'm fine with the suggested change but I would like more feedback >> from other people before moving forward with it. There's a lot of >> value in "just pick a name and ship it" as well though, and I don't >> want to devolve into bike shedding. (I'm not accusing you of bike >> shedding quite yet, btw, just afraid of getting into a long debate on >> names.) >> Again, this was a problem raised by people new to the specification. >> They found it confusing. I tend to agree. We're not talking about >> what colour to paint the shed. We're talking about whether the bike >> shed is a house. :-) >> I'm not too fussed about whether you call it "cl_sec_expiry" or >> "client_secret_expires_at". >> >> If the definitions of "expires_at" or "issued_at" are unclear, we >> should clarify them. If you believe that this is the case Phil, can >> you supply proposed alternative definition text that is clearer? >> That being said, I believe that at this point we should stick with >> the existing protocol element names unless overwhelming working group >> sentiment emerges to change them. They are already working fine >> as-is in production deployments. >> >> *Section 7* >> When a client_secret expires is it the intent that clients do an >> update or refresh to get a new client secret? >> Yes, the client is supposed to either call the read or update >> methods on the client configuration endpoint to get its new >> secret. As discussed above, I'm not sure that's as clear as it >> needs to be, and I welcome suggestions on how to clarify this. >> Either is a reasonable behavior on the behalf of clients, >> depending upon context. I support adding text to clarify this. >> Again, thanks for the very thorough read through. Have you >> implemented any of the spec yet, either as-is or with any of your >> suggested changes? >> >> Yes. Much of the feedback is coming from our development community. >> Ah, very cool. Developer experience is the most valuable feedback, in >> my opinion. If you can't actually build the blasted thing, what good >> is it? :) >> Glad to hear that you're working with developers building the spec. >> Please thank them for the feedback. >> -- Justin >> Best wishes, >> -- Mike >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040900050803070301040605 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.

From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server. A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:

  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.


As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…
 
(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.
 
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the registration service?
 
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.
 
3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.
 
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?
 
See the response above above and the definition in §1.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.
 
   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.
 
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.
 
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
* There is no authn method for "client_secret_saml" or "private_key_saml".
 
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.
 
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:
 
While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.
 
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant-type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect has this in its example:
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.
 
Section 3
 
Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.
 
The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. 
 
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
 
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.
 
 -- Justin
 
                                                            Best wishes,
                                                            -- Mike




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

--------------040900050803070301040605-- From jricher@mitre.org Mon May 20 08:45:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1171521F92F4 for ; Mon, 20 May 2013 08:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q70bHNdlHASr for ; Mon, 20 May 2013 08:45:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8D24421F92E3 for ; Mon, 20 May 2013 08:45:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D813C1F06D8; Mon, 20 May 2013 11:45:50 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AEE0E1F0664; Mon, 20 May 2013 11:45:50 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:45:50 -0400 Message-ID: <519A4512.9080905@mitre.org> Date: Mon, 20 May 2013 11:45:22 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> In-Reply-To: <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:45:58 -0000 On 05/17/2013 07:29 PM, Phil Hunt wrote: > He's saying every client gets a registration token and a client token. > What's a "client token", exactly? There are three potential places for OAuth tokens in and around dynamic registration, and none of them are called "client token". 1) The registration access token, which binds a "client" (or "instance of a client", if you will) to a set of registration information at a specific authorization server. The client uses this to call its Client Information Endpoint to do updates, refreshes, and potentially delete itself. This token is *only* good at this Client Information Endpoint, and nowhere else. This token is specific to the registration it represents. 2) The (optional) initial token used to authenticate to the Client Registration Endpoint. This is *not* the registration access token, and it is *not* used to access the Client Information Endpoint. How the client or developer get this token is out of scope. How the registration server validates this token is out of scope. The structure and contents of this token are out of scope. 3) The access/refresh tokens that a registered client eventually gets from the Token Endpoint and uses with protected resources. These tokens aren't used at the Client Registration Endpoint or at the Client Information Endpoint. There are also a couple of related concepts that aren't tokens at all: 4) The client_id, which is issued to a "client" (or "client instance") by the authorization server. This must be unique at the auth server for each client instance. The client uses this client_id at the Authorization Endpoint and the Token Endpoint in normal OAuth flows. 5) The client_secret, which is issued to a "client" (or "client instance") by the auth server, for confidential clients (ie: clients that can protect their client_secret). This is used by the client to authenticate to the Token Endpoint and nowhere else. Which of these do you mean by a "client token"? -- Justin From jricher@mitre.org Mon May 20 08:50:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8B21F926E for ; Mon, 20 May 2013 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y5G3mNs1gsm for ; Mon, 20 May 2013 08:49:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B875221F8E93 for ; Mon, 20 May 2013 08:49:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 618191F0664; Mon, 20 May 2013 11:49:56 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 52C0F1F0542; Mon, 20 May 2013 11:49:56 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:49:56 -0400 Message-ID: <519A4607.1030900@mitre.org> Date: Mon, 20 May 2013 11:49:27 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> In-Reply-To: <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> Content-Type: multipart/alternative; boundary="------------030403070904060104060608" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:50:02 -0000 --------------030403070904060104060608 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage. -- Justin On 05/20/2013 11:21 AM, Phil Hunt wrote: > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out what token is being > referred to. > > Phil > > On 2013-05-20, at 8:09, Justin Richer > wrote: > >> Phil Hunt's review of the Dynamic Registration specification has >> raised a couple of issues that I felt were getting buried by the >> larger discussion (which I still strongly encourage others to jump in >> to). Namely, Phil has suggested a couple of syntax changes to the >> names of several parameters. >> >> >> 1) expires_at -> client_secret_expires_at >> 2) issued_at -> client_id_issued_at >> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >> >> >> I'd like to get a feeling, *especially from developers* who have >> deployed this draft spec, what we ought to do for each of these: >> >> A) Keep the parameter names as-is >> B) Adopt the new names as above >> C) Adopt a new name that I will specify >> >> In all cases, clarifying text will be added to the parameter >> *definitions* so that it's more clear to people reading the spec what >> each piece does. Speaking as the editor: "A" is the default as far as >> I'm concerned, since we shouldn't change syntax without very good >> reason to do so. That said, if it's going to be better for developers >> with the new parameter names, I am open to fixing them now. >> >> Naming things is hard. >> >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------030403070904060104060608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming. 

The issue is that new developers can't figure out what token is being referred to. 

Phil

On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

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

--------------030403070904060104060608-- From donald.coffin@reminetworks.com Mon May 20 08:59:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831B421F92E3 for ; Mon, 20 May 2013 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz5lWoZwDolJ for ; Mon, 20 May 2013 08:58:55 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id D900021F920B for ; Mon, 20 May 2013 08:58:54 -0700 (PDT) Received: (qmail 11840 invoked by uid 0); 20 May 2013 15:58:33 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy13.unifiedlayer.com with SMTP; 20 May 2013 15:58:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=UfmdJyujvI+CUNYBSaKQbWSlPMes9/o9ULU6JkHROkA=; b=tHpAKWhU1zZDwKYYJsLiSEmUhk75UQAYSqMeymK/rb1BQ+gDHcH5vOnTiEQuSrzPdoKIrE7toIE2iuj2lrRB9/ikU9Wkn/aMEwt9wWlgtQOuWuExdb1abKV5osgswSCF; Received: from [68.4.207.246] (port=1201 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UeSTp-0007C4-Az; Mon, 20 May 2013 09:58:33 -0600 From: "Donald F Coffin" To: "'Justin Richer'" , References: <519A3C9A.8060305@mitre.org> In-Reply-To: <519A3C9A.8060305@mitre.org> Date: Mon, 20 May 2013 08:58:23 -0700 Message-ID: <005801ce5572$dba269d0$92e73d70$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01CE5538.2F451870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE6nq+xED23CN2RhNJBxWly11UkM5o1p01Q Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 15:59:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0059_01CE5538.2F451870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Justin, We are still working on the requirement document for integrating OAuth 2.0 into the NAESB ESPI standard. To date, no one who has implemented the current "Download My Data" or "Connect My Data" features of the ESPI standard would be affected, since they have not implemented OAuth 2.0. I would vote for "B" as I believe it clarifies intention of the field, but am also satisfied if "A" is the final result. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mitre.org] Sent: Monday, May 20, 2013 8:09 AM To: oauth@ietf.org Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now. Naming things is hard. -- Justin ------=_NextPart_000_0059_01CE5538.2F451870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Justin,

 

We are still = working on the requirement document for integrating OAuth 2.0 into the = NAESB ESPI standard.  To date, no one who has implemented the = current “Download My Data” or “Connect My Data” = features of the ESPI standard would be affected, since they have not = implemented OAuth 2.0.  I would vote for “B” as I = believe it clarifies intention of the field, but am also satisfied if = “A” is the final result.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 =

REMI = Networks

22751 El = Prado Suite 6216

Rancho = Santa Margarita, CA  92688-3836

 =

Phone: = ;     (949) 636-8571

Email: = ;      donald.coffin@reminetworks= .com

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, = May 20, 2013 8:09 AM
To: oauth@ietf.org
Subject: = [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

Phil Hunt's = review of the Dynamic Registration specification has raised a couple of = issues that I felt were getting buried by the larger discussion (which I = still strongly encourage others to jump in to). Namely, Phil has = suggested a couple of syntax changes to the names of several parameters. =


1) expires_at -> client_secret_expires_at
2) issued_at = -> client_id_issued_at
3) token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a feeling, = especially from developers who have deployed this draft spec, = what we ought to do for each of these:

 A) Keep the = parameter names as-is
 B) Adopt the new names as = above
 C) Adopt a new name that I will specify

In all = cases, clarifying text will be added to the parameter *definitions* so = that it's more clear to people reading the spec what each piece does. = Speaking as the editor: "A" is the default as far as I'm = concerned, since we shouldn't change syntax without very good reason to = do so. That said, if it's going to be better for developers with the new = parameter names, I am open to fixing them now.

Naming things is = hard.

 -- Justin

------=_NextPart_000_0059_01CE5538.2F451870-- From phil.hunt@oracle.com Mon May 20 09:36:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78E621F93DE for ; Mon, 20 May 2013 09:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opRXWF1fvR9g for ; Mon, 20 May 2013 09:36:47 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7421F93B7 for ; Mon, 20 May 2013 09:36:47 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KGaiEn023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 16:36:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGajsa023204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 16:36:45 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGaiLg005128; Mon, 20 May 2013 16:36:44 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 09:36:44 -0700 References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> <519A4512.9080905@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519A4512.9080905@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Mon, 20 May 2013 09:36:42 -0700 To: Justin Richer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:36:54 -0000 Phil On 2013-05-20, at 8:45, Justin Richer wrote: >=20 > On 05/17/2013 07:29 PM, Phil Hunt wrote: >> He's saying every client gets a registration token and a client token. > What's a "client token", exactly? There are three potential places for OAu= th tokens in and around dynamic registration, and none of them are called "c= lient token". i meant client credential. Client token is obviously a type of client c= red.=20 >=20 > 1) The registration access token, which binds a "client" (or "instance of a= client", if you will) to a set of registration information at a specific au= thorization server. The client uses this to call its Client Information Endp= oint to do updates, refreshes, and potentially delete itself. This token is *= only* good at this Client Information Endpoint, and nowhere else. This token= is specific to the registration it represents. This is not apparent at all. No more than binding the registration to t= he client credential since the implication is one reg -> one client cred and= one reg token.=20 John Bradley has brought up seemingly other scenarios that would not bind bu= t rather associates a dev or an admin to a reg. i may be wrong. I have not h= ad time to consider his explanations yet.=20 What seems clear is that there is confusion as to the purpose and role for t= his token and what the use cases are for registration.=20 My plan is to review and suggest clarifying text and changes if necessary th= is week.=20 >=20 > 2) The (optional) initial token used to authenticate to the Client Registr= ation Endpoint. This is *not* the registration access token, and it is *not*= used to access the Client Information Endpoint. How the client or developer= get this token is out of scope. How the registration server validates this t= oken is out of scope. The structure and contents of this token are out of sc= ope. >=20 > 3) The access/refresh tokens that a registered client eventually gets from= the Token Endpoint and uses with protected resources. These tokens aren't u= sed at the Client Registration Endpoint or at the Client Information Endpoin= t. >=20 > There are also a couple of related concepts that aren't tokens at all: >=20 > 4) The client_id, which is issued to a "client" (or "client instance") by t= he authorization server. This must be unique at the auth server for each cli= ent instance. The client uses this client_id at the Authorization Endpoint a= nd the Token Endpoint in normal OAuth flows. >=20 > 5) The client_secret, which is issued to a "client" (or "client instance")= by the auth server, for confidential clients (ie: clients that can protect t= heir client_secret). This is used by the client to authenticate to the Token= Endpoint and nowhere else. >=20 >=20 > Which of these do you mean by a "client token"? >=20 > -- Justin From phil.hunt@oracle.com Mon May 20 09:42:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6721F9540 for ; Mon, 20 May 2013 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.44 X-Spam-Level: X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkbQGC+q4D91 for ; Mon, 20 May 2013 09:42:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 04F0C21F961C for ; Mon, 20 May 2013 09:41:59 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KGfux1009133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 16:41:57 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGfuAr028688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 16:41:56 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGfuKE028682; Mon, 20 May 2013 16:41:56 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 09:41:55 -0700 References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519A4607.1030900@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-A1B469C5-0E82-4685-8DDD-0A6888904F34 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Mon, 20 May 2013 09:41:52 -0700 To: Justin Richer X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:42:05 -0000 --Apple-Mail-A1B469C5-0E82-4685-8DDD-0A6888904F34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This draft isn't ready for LC.=20 Phil On 2013-05-20, at 8:49, Justin Richer wrote: > But also keep in mind that this is last-call, and that we don't really wan= t to encourage avoidable drastic changes at this stage.=20 >=20 > -- Justin >=20 >=20 > On 05/20/2013 11:21 AM, Phil Hunt wrote: >> Keep in mind there may be other changes coming.=20 >>=20 >> The issue is that new developers can't figure out what token is being ref= erred to.=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 8:09, Justin Richer wrote: >>=20 >>> Phil Hunt's review of the Dynamic Registration specification has raised a= couple of issues that I felt were getting buried by the larger discussion (= which I still strongly encourage others to jump in to). Namely, Phil has sug= gested a couple of syntax changes to the names of several parameters.=20 >>>=20 >>>=20 >>> 1) expires_at -> client_secret_expires_at >>> 2) issued_at -> client_id_issued_at >>> 3) token_endpoint_auth_method -> token_endpoint_client_auth_me= thod >>>=20 >>>=20 >>> I'd like to get a feeling, especially from developers who have deployed t= his draft spec, what we ought to do for each of these: >>>=20 >>> A) Keep the parameter names as-is >>> B) Adopt the new names as above >>> C) Adopt a new name that I will specify >>>=20 >>> In all cases, clarifying text will be added to the parameter *definition= s* so that it's more clear to people reading the spec what each piece does. S= peaking as the editor: "A" is the default as far as I'm concerned, since we s= houldn't change syntax without very good reason to do so. That said, if it's= going to be better for developers with the new parameter names, I am open t= o fixing them now. >>>=20 >>> Naming things is hard. >>>=20 >>> -- Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-A1B469C5-0E82-4685-8DDD-0A6888904F34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
This draft isn't ready for LC. 

Phil

On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming. 

The issue is that new developers can't figure out what token is being referred to. 

Phil

On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

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

--Apple-Mail-A1B469C5-0E82-4685-8DDD-0A6888904F34-- From jricher@mitre.org Mon May 20 09:42:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE16621F9636 for ; Mon, 20 May 2013 09:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXzJmUjwsDBd for ; Mon, 20 May 2013 09:42:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1743521F963A for ; Mon, 20 May 2013 09:42:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AD4C61F02F4; Mon, 20 May 2013 12:42:37 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6E8421F0DE1; Mon, 20 May 2013 12:42:37 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 12:42:37 -0400 Message-ID: <519A5261.1010506@mitre.org> Date: Mon, 20 May 2013 12:42:09 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020204040207000206090500" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:42:49 -0000 --------------020204040207000206090500 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I, of course, disagree. But that's what we're trying to figure out as a working group, after all. -- Justin On 05/20/2013 12:41 PM, Phil Hunt wrote: > This draft isn't ready for LC. > > Phil > > On 2013-05-20, at 8:49, Justin Richer > wrote: > >> But also keep in mind that this is last-call, and that we don't >> really want to encourage avoidable drastic changes at this stage. >> >> -- Justin >> >> >> On 05/20/2013 11:21 AM, Phil Hunt wrote: >>> Keep in mind there may be other changes coming. >>> >>> The issue is that new developers can't figure out what token is >>> being referred to. >>> >>> Phil >>> >>> On 2013-05-20, at 8:09, Justin Richer >> > wrote: >>> >>>> Phil Hunt's review of the Dynamic Registration specification has >>>> raised a couple of issues that I felt were getting buried by the >>>> larger discussion (which I still strongly encourage others to jump >>>> in to). Namely, Phil has suggested a couple of syntax changes to >>>> the names of several parameters. >>>> >>>> >>>> 1) expires_at -> client_secret_expires_at >>>> 2) issued_at -> client_id_issued_at >>>> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >>>> >>>> >>>> I'd like to get a feeling, *especially from developers* who have >>>> deployed this draft spec, what we ought to do for each of these: >>>> >>>> A) Keep the parameter names as-is >>>> B) Adopt the new names as above >>>> C) Adopt a new name that I will specify >>>> >>>> In all cases, clarifying text will be added to the parameter >>>> *definitions* so that it's more clear to people reading the spec >>>> what each piece does. Speaking as the editor: "A" is the default as >>>> far as I'm concerned, since we shouldn't change syntax without very >>>> good reason to do so. That said, if it's going to be better for >>>> developers with the new parameter names, I am open to fixing them now. >>>> >>>> Naming things is hard. >>>> >>>> -- Justin >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> --------------020204040207000206090500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I, of course, disagree. But that's what we're trying to figure out as a working group, after all.

 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt wrote:
This draft isn't ready for LC. 

Phil

On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming. 

The issue is that new developers can't figure out what token is being referred to. 

Phil

On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

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


--------------020204040207000206090500-- From Michael.Jones@microsoft.com Mon May 20 09:49:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1921B21F93D8 for ; Mon, 20 May 2013 09:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV3GMeBDWg1S for ; Mon, 20 May 2013 09:49:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7462321F969A for ; Mon, 20 May 2013 09:49:26 -0700 (PDT) Received: from BN1BFFO11FD022.protection.gbl (10.58.52.202) by BN1AFFO11HUB002.protection.gbl (10.58.52.112) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 16:49:15 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.53.82) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 20 May 2013 16:49:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Mon, 20 May 2013 16:48:59 +0000 From: Mike Jones To: Justin Richer , Phil Hunt Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWwkkVRUbqGmb0Chrsy2ymzpkpkOMHcAgAAH54CAAA6lAIAAABWAgAAA5EA= Date: Mon, 20 May 2013 16:48:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> In-Reply-To: <519A5261.1010506@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367742D5ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(78114002)(199002)(377454002)(479174002)(24454002)(377424003)(31966008)(51856001)(56816002)(47976001)(63696002)(47736001)(74502001)(46102001)(49866001)(54356001)(65816001)(69226001)(20776003)(66066001)(512874002)(74662001)(80022001)(59766001)(54316002)(81342001)(53806001)(77982001)(76482001)(47446002)(74366001)(4396001)(50986001)(81542001)(6806003)(74706001)(71186001)(33656001)(79102001)(16236675002)(74876001)(56776001)(16406001)(55846006)(15202345002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB002; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0852EB6797 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:49:32 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367742D5ATK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRlcGxveW1lbnQgZXZpZGVuY2UgZG9lc27igJl0IHN1cHBvcnQgeW91ciBwb3NpdGlvbiwg UGhpbC4gIFRoZXJlIGFyZSBvdmVyIGEgZG96ZW4gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlv bnMgYWxyZWFkeSBkZXBsb3llZC4gIFRob3NlIGRlcGxveW1lbnRzIGRlbW9uc3RyYXRlIHRoYXQg dGhlIHNwZWMsIGFzIHdyaXR0ZW4sIGlzIGFscmVhZHkgZG9pbmcgb25lIHRoaW5nIHdlbGwg4oCT IGVuYWJsaW5nIGNsaWVudHMgKGFzIGRlZmluZWQgYnkgUkZDIDY3NDkpIHRvIHJlZ2lzdGVyIHdp dGggQXV0aG9yaXphdGlvbiBTZXJ2ZXJzLCBvYnRhaW5pbmcgY2xpZW50X2lkIGFuZCBvcHRpb25h bGx5IGNsaWVudF9zZWNyZXQgdmFsdWVzIHRoYXQgZW5hYmxlIHRob3NlIGNsaWVudHMgdG8gdXNl IHRob3NlIEF1dGhvcml6YXRpb24gU2VydmVycy4gIERvaW5nIG9uZSB0aGluZyB3ZWxsIGlzIGV4 YWN0bHkgd2hhdCB3ZSBzaG91bGQgYmUgc3RyaXZpbmcgZm9yLCBhbmQgdGhlIGV2aWRlbmNlIHNh eXMgdGhhdCB3ZeKAmXZlIGFjaGlldmVkIHRoYXQuDQoNCkl04oCZcyB0aW1lIHRvIHNoaXAgaXQh DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KU2Vu dDogTW9uZGF5LCBNYXkgMjAsIDIwMTMgOTo0MiBBTQ0KVG86IFBoaWwgSHVudA0KQ2M6IG9hdXRo QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdl cyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbg0KDQpJLCBvZiBjb3Vyc2UsIGRpc2FncmVlLiBCdXQg dGhhdCdzIHdoYXQgd2UncmUgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgYXMgYSB3b3JraW5nIGdyb3Vw LCBhZnRlciBhbGwuDQoNCiAtLSBKdXN0aW4NCk9uIDA1LzIwLzIwMTMgMTI6NDEgUE0sIFBoaWwg SHVudCB3cm90ZToNClRoaXMgZHJhZnQgaXNuJ3QgcmVhZHkgZm9yIExDLg0KDQpQaGlsDQoNCk9u IDIwMTMtMDUtMjAsIGF0IDg6NDksIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KQnV0IGFsc28ga2VlcCBpbiBtaW5kIHRo YXQgdGhpcyBpcyBsYXN0LWNhbGwsIGFuZCB0aGF0IHdlIGRvbid0IHJlYWxseSB3YW50IHRvIGVu Y291cmFnZSBhdm9pZGFibGUgZHJhc3RpYyBjaGFuZ2VzIGF0IHRoaXMgc3RhZ2UuDQoNCiAtLSBK dXN0aW4NCg0KT24gMDUvMjAvMjAxMyAxMToyMSBBTSwgUGhpbCBIdW50IHdyb3RlOg0KS2VlcCBp biBtaW5kIHRoZXJlIG1heSBiZSBvdGhlciBjaGFuZ2VzIGNvbWluZy4NCg0KVGhlIGlzc3VlIGlz IHRoYXQgbmV3IGRldmVsb3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5n IHJlZmVycmVkIHRvLg0KDQpQaGlsDQoNCk9uIDIwMTMtMDUtMjAsIGF0IDg6MDksIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3Rl Og0KUGhpbCBIdW50J3MgcmV2aWV3IG9mIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjaWZp Y2F0aW9uIGhhcyByYWlzZWQgYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSBmZWx0IHdlcmUgZ2V0 dGluZyBidXJpZWQgYnkgdGhlIGxhcmdlciBkaXNjdXNzaW9uICh3aGljaCBJIHN0aWxsIHN0cm9u Z2x5IGVuY291cmFnZSBvdGhlcnMgdG8ganVtcCBpbiB0bykuIE5hbWVseSwgUGhpbCBoYXMgc3Vn Z2VzdGVkIGEgY291cGxlIG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFs IHBhcmFtZXRlcnMuDQoNCg0KMSkgZXhwaXJlc19hdCAtPiBjbGllbnRfc2VjcmV0X2V4cGlyZXNf YXQNCjIpIGlzc3VlZF9hdCAtPiBjbGllbnRfaWRfaXNzdWVkX2F0DQozKSB0b2tlbl9lbmRwb2lu dF9hdXRoX21ldGhvZCAtPiB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QNCg0KDQpJ J2QgbGlrZSB0byBnZXQgYSBmZWVsaW5nLCBlc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVycyB3aG8g aGF2ZSBkZXBsb3llZCB0aGlzIGRyYWZ0IHNwZWMsIHdoYXQgd2Ugb3VnaHQgdG8gZG8gZm9yIGVh Y2ggb2YgdGhlc2U6DQoNCiBBKSBLZWVwIHRoZSBwYXJhbWV0ZXIgbmFtZXMgYXMtaXMNCiBCKSBB ZG9wdCB0aGUgbmV3IG5hbWVzIGFzIGFib3ZlDQogQykgQWRvcHQgYSBuZXcgbmFtZSB0aGF0IEkg d2lsbCBzcGVjaWZ5DQoNCkluIGFsbCBjYXNlcywgY2xhcmlmeWluZyB0ZXh0IHdpbGwgYmUgYWRk ZWQgdG8gdGhlIHBhcmFtZXRlciAqZGVmaW5pdGlvbnMqIHNvIHRoYXQgaXQncyBtb3JlIGNsZWFy IHRvIHBlb3BsZSByZWFkaW5nIHRoZSBzcGVjIHdoYXQgZWFjaCBwaWVjZSBkb2VzLiBTcGVha2lu ZyBhcyB0aGUgZWRpdG9yOiAiQSIgaXMgdGhlIGRlZmF1bHQgYXMgZmFyIGFzIEknbSBjb25jZXJu ZWQsIHNpbmNlIHdlIHNob3VsZG4ndCBjaGFuZ2Ugc3ludGF4IHdpdGhvdXQgdmVyeSBnb29kIHJl YXNvbiB0byBkbyBzby4gVGhhdCBzYWlkLCBpZiBpdCdzIGdvaW5nIHRvIGJlIGJldHRlciBmb3Ig ZGV2ZWxvcGVycyB3aXRoIHRoZSBuZXcgcGFyYW1ldGVyIG5hbWVzLCBJIGFtIG9wZW4gdG8gZml4 aW5nIHRoZW0gbm93Lg0KDQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQuDQoNCiAtLSBKdXN0aW4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= --_000_4E1F6AAD24975D4BA5B168042967394367742D5ATK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSBkZXBsb3ltZW50IGV2aWRlbmNlIGRvZXNu4oCZdCBzdXBwb3J0IHlvdXIgcG9zaXRpb24sIFBo aWwuJm5ic3A7IFRoZXJlIGFyZSBvdmVyIGEgZG96ZW4gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh dGlvbnMgYWxyZWFkeSBkZXBsb3llZC4mbmJzcDsgVGhvc2UgZGVwbG95bWVudHMgZGVtb25zdHJh dGUNCiB0aGF0IHRoZSBzcGVjLCBhcyB3cml0dGVuLCBpcyBhbHJlYWR5IGRvaW5nIG9uZSB0aGlu ZyB3ZWxsIOKAkyBlbmFibGluZyBjbGllbnRzIChhcyBkZWZpbmVkIGJ5IFJGQyA2NzQ5KSB0byBy ZWdpc3RlciB3aXRoIEF1dGhvcml6YXRpb24gU2VydmVycywgb2J0YWluaW5nIGNsaWVudF9pZCBh bmQgb3B0aW9uYWxseSBjbGllbnRfc2VjcmV0IHZhbHVlcyB0aGF0IGVuYWJsZSB0aG9zZSBjbGll bnRzIHRvIHVzZSB0aG9zZSBBdXRob3JpemF0aW9uIFNlcnZlcnMuJm5ic3A7DQogRG9pbmcgb25l IHRoaW5nIHdlbGwgaXMgZXhhY3RseSB3aGF0IHdlIHNob3VsZCBiZSBzdHJpdmluZyBmb3IsIGFu ZCB0aGUgZXZpZGVuY2Ugc2F5cyB0aGF0IHdl4oCZdmUgYWNoaWV2ZWQgdGhhdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkl04oCZcyB0aW1lIHRvIHNoaXAgaXQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFJpY2hlcjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyA5OjQyIEFNPGJyPg0KPGI+VG86PC9i PiBQaGlsIEh1bnQ8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFtaWMg UmVnaXN0cmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JLCBvZiBjb3Vyc2UsIGRpc2FncmVlLiBC dXQgdGhhdCdzIHdoYXQgd2UncmUgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgYXMgYSB3b3JraW5nIGdy b3VwLCBhZnRlciBhbGwuPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDUvMjAvMjAxMyAxMjo0MSBQTSwgUGhp bCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGlzbid0IHJlYWR5IGZvciBMQy4mbmJzcDs8YnI+DQo8YnI+ DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIwMTMtMDUtMjAsIGF0IDg6 NDksIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+ anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5CdXQgYWxzbyBrZWVwIGluIG1pbmQgdGhhdCB0aGlzIGlzIGxhc3QtY2FsbCwgYW5kIHRoYXQg d2UgZG9uJ3QgcmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIGF2b2lkYWJsZSBkcmFzdGljIGNoYW5n ZXMgYXQgdGhpcyBzdGFnZS4NCjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzIwLzIw MTMgMTE6MjEgQU0sIFBoaWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VlcCBpbiBtaW5kIHRoZXJlIG1heSBiZSBvdGhl ciBjaGFuZ2VzIGNvbWluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlzIHRoYXQgbmV3IGRldmVsb3BlcnMgY2Fu J3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5nIHJlZmVycmVkIHRvLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhp bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMDEzLTA1LTIwLCBhdCA4OjA5LCBK dXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNo ZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWwgSHVudCdzIHJldmlldyBvZiB0aGUgRHluYW1p YyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBoYXMgcmFpc2VkIGEgY291cGxlIG9mIGlzc3Vl cyB0aGF0IEkgZmVsdCB3ZXJlIGdldHRpbmcgYnVyaWVkIGJ5IHRoZSBsYXJnZXIgZGlzY3Vzc2lv biAod2hpY2ggSSBzdGlsbCBzdHJvbmdseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIGp1bXAgaW4gdG8p LiBOYW1lbHksIFBoaWwgaGFzIHN1Z2dlc3RlZCBhIGNvdXBsZQ0KIG9mIHN5bnRheCBjaGFuZ2Vz IHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFsIHBhcmFtZXRlcnMuIDxicj4NCjxicj4NCjxicj4NCjEp IGV4cGlyZXNfYXQgLSZndDsgY2xpZW50X3NlY3JldF9leHBpcmVzX2F0PGJyPg0KMikgaXNzdWVk X2F0IC0mZ3Q7IGNsaWVudF9pZF9pc3N1ZWRfYXQ8YnI+DQozKSB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZCAtJmd0OyB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2Q8YnI+DQo8YnI+ DQo8YnI+DQpJJ2QgbGlrZSB0byBnZXQgYSBmZWVsaW5nLCA8Yj5lc3BlY2lhbGx5IGZyb20gZGV2 ZWxvcGVyczwvYj4gd2hvIGhhdmUgZGVwbG95ZWQgdGhpcyBkcmFmdCBzcGVjLCB3aGF0IHdlIG91 Z2h0IHRvIGRvIGZvciBlYWNoIG9mIHRoZXNlOjxicj4NCjxicj4NCiZuYnNwO0EpIEtlZXAgdGhl IHBhcmFtZXRlciBuYW1lcyBhcy1pczxicj4NCiZuYnNwO0IpIEFkb3B0IHRoZSBuZXcgbmFtZXMg YXMgYWJvdmU8YnI+DQombmJzcDtDKSBBZG9wdCBhIG5ldyBuYW1lIHRoYXQgSSB3aWxsIHNwZWNp Znk8YnI+DQo8YnI+DQpJbiBhbGwgY2FzZXMsIGNsYXJpZnlpbmcgdGV4dCB3aWxsIGJlIGFkZGVk IHRvIHRoZSBwYXJhbWV0ZXIgKmRlZmluaXRpb25zKiBzbyB0aGF0IGl0J3MgbW9yZSBjbGVhciB0 byBwZW9wbGUgcmVhZGluZyB0aGUgc3BlYyB3aGF0IGVhY2ggcGllY2UgZG9lcy4gU3BlYWtpbmcg YXMgdGhlIGVkaXRvcjogJnF1b3Q7QSZxdW90OyBpcyB0aGUgZGVmYXVsdCBhcyBmYXIgYXMgSSdt IGNvbmNlcm5lZCwgc2luY2Ugd2Ugc2hvdWxkbid0IGNoYW5nZSBzeW50YXggd2l0aG91dA0KIHZl cnkgZ29vZCByZWFzb24gdG8gZG8gc28uIFRoYXQgc2FpZCwgaWYgaXQncyBnb2luZyB0byBiZSBi ZXR0ZXIgZm9yIGRldmVsb3BlcnMgd2l0aCB0aGUgbmV3IHBhcmFtZXRlciBuYW1lcywgSSBhbSBv cGVuIHRvIGZpeGluZyB0aGVtIG5vdy48YnI+DQo8YnI+DQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQu PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B168042967394367742D5ATK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon May 20 09:53:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6F21F9696 for ; Mon, 20 May 2013 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrVprQqvL-mJ for ; Mon, 20 May 2013 09:52:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6686B21F9695 for ; Mon, 20 May 2013 09:52:55 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.200) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 16:52:53 +0000 Received: from TK5EX14HUBC103.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.698.0 via Frontend Transport; Mon, 20 May 2013 16:52:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Mon, 20 May 2013 16:52:47 +0000 From: Mike Jones To: Phil Hunt , Justin Richer Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWwkkVRUbqGmb0Chrsy2ymzpkpkOMHcAgAAY8BA= Date: Mon, 20 May 2013 16:52:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367742DDA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> In-Reply-To: <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367742DDATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377424003)(24454002)(377454002)(78114002)(69226001)(49866001)(76482001)(50986001)(54356001)(51856001)(47976001)(33656001)(54316002)(4396001)(47736001)(56776001)(31966008)(46102001)(56816002)(55846006)(44976003)(512874002)(71186001)(81342001)(16236675002)(81542001)(15202345002)(59766001)(53806001)(6806003)(77982001)(16406001)(20776003)(74706001)(79102001)(63696002)(74366001)(74502001)(74662001)(47446002)(65816001)(66066001)(74876001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0852EB6797 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:53:01 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367742DDATK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgbm8gc3ludGF4IGNoYW5nZXMgYXJlIG5lY2Vzc2FyeS4NCg0KT2YgdGhl IHRocmVlIHBvc3NpYmxlIGNoYW5nZXMgZGVzY3JpYmVkIGJlbG93LCBJIHBhcnRpY3VsYXJseSBi ZWxpZXZlIHRoYXQgKDMpIGlzIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnksIGFzIHRoZXJlIGlzIG5v dGhpbmcgdGhhdCBhdXRoZW50aWNhdGVzIHRvIHRoZSBUb2tlbiBFbmRwb2ludCBvdGhlciB0aGFu IHRoZSBjbGllbnQuICBUaHVzLCBhZGRpbmcg4oCcY2xpZW50X+KAnSB0byB0aGUgbmFtZSBhZGRz IG5vIHVzZWZ1bCBzZW1hbnRpYyBjb250ZW50LiAgVGhpcyBwcm9wb3NlZCBjaGFuZ2UgaXMgZXNw ZWNpYWxseSBzdXBlcmZsdW91cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBo aWwgSHVudA0KU2VudDogTW9uZGF5LCBNYXkgMjAsIDIwMTMgODoyMSBBTQ0KVG86IEp1c3RpbiBS aWNoZXINCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUHJvcG9z ZWQgU3ludGF4IENoYW5nZXMgaW4gRHluYW1pYyBSZWdpc3RyYXRpb24NCg0KS2VlcCBpbiBtaW5k IHRoZXJlIG1heSBiZSBvdGhlciBjaGFuZ2VzIGNvbWluZy4NCg0KVGhlIGlzc3VlIGlzIHRoYXQg bmV3IGRldmVsb3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5nIHJlZmVy cmVkIHRvLg0KDQpQaGlsDQoNCk9uIDIwMTMtMDUtMjAsIGF0IDg6MDksIEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KUGhp bCBIdW50J3MgcmV2aWV3IG9mIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9u IGhhcyByYWlzZWQgYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSBmZWx0IHdlcmUgZ2V0dGluZyBi dXJpZWQgYnkgdGhlIGxhcmdlciBkaXNjdXNzaW9uICh3aGljaCBJIHN0aWxsIHN0cm9uZ2x5IGVu Y291cmFnZSBvdGhlcnMgdG8ganVtcCBpbiB0bykuIE5hbWVseSwgUGhpbCBoYXMgc3VnZ2VzdGVk IGEgY291cGxlIG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFsIHBhcmFt ZXRlcnMuDQoNCg0KMSkgZXhwaXJlc19hdCAtPiBjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXQNCjIp IGlzc3VlZF9hdCAtPiBjbGllbnRfaWRfaXNzdWVkX2F0DQozKSB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZCAtPiB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QNCg0KDQpJJ2QgbGlr ZSB0byBnZXQgYSBmZWVsaW5nLCBlc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVycyB3aG8gaGF2ZSBk ZXBsb3llZCB0aGlzIGRyYWZ0IHNwZWMsIHdoYXQgd2Ugb3VnaHQgdG8gZG8gZm9yIGVhY2ggb2Yg dGhlc2U6DQoNCiBBKSBLZWVwIHRoZSBwYXJhbWV0ZXIgbmFtZXMgYXMtaXMNCiBCKSBBZG9wdCB0 aGUgbmV3IG5hbWVzIGFzIGFib3ZlDQogQykgQWRvcHQgYSBuZXcgbmFtZSB0aGF0IEkgd2lsbCBz cGVjaWZ5DQoNCkluIGFsbCBjYXNlcywgY2xhcmlmeWluZyB0ZXh0IHdpbGwgYmUgYWRkZWQgdG8g dGhlIHBhcmFtZXRlciAqZGVmaW5pdGlvbnMqIHNvIHRoYXQgaXQncyBtb3JlIGNsZWFyIHRvIHBl b3BsZSByZWFkaW5nIHRoZSBzcGVjIHdoYXQgZWFjaCBwaWVjZSBkb2VzLiBTcGVha2luZyBhcyB0 aGUgZWRpdG9yOiAiQSIgaXMgdGhlIGRlZmF1bHQgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQsIHNp bmNlIHdlIHNob3VsZG4ndCBjaGFuZ2Ugc3ludGF4IHdpdGhvdXQgdmVyeSBnb29kIHJlYXNvbiB0 byBkbyBzby4gVGhhdCBzYWlkLCBpZiBpdCdzIGdvaW5nIHRvIGJlIGJldHRlciBmb3IgZGV2ZWxv cGVycyB3aXRoIHRoZSBuZXcgcGFyYW1ldGVyIG5hbWVzLCBJIGFtIG9wZW4gdG8gZml4aW5nIHRo ZW0gbm93Lg0KDQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQuDQoNCiAtLSBKdXN0aW4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_4E1F6AAD24975D4BA5B168042967394367742DDATK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRoYXQgbm8gc3ludGF4IGNoYW5nZXMg YXJlIG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mIHRoZSB0aHJlZSBwb3NzaWJsZSBjaGFuZ2VzIGRl c2NyaWJlZCBiZWxvdywgSSBwYXJ0aWN1bGFybHkgYmVsaWV2ZSB0aGF0ICgzKSBpcyBjb21wbGV0 ZWx5IHVubmVjZXNzYXJ5LCBhcyB0aGVyZSBpcyBub3RoaW5nIHRoYXQgYXV0aGVudGljYXRlcyB0 byB0aGUgVG9rZW4NCiBFbmRwb2ludCBvdGhlciB0aGFuIHRoZSBjbGllbnQuJm5ic3A7IFRodXMs IGFkZGluZyDigJxjbGllbnRf4oCdIHRvIHRoZSBuYW1lIGFkZHMgbm8gdXNlZnVsIHNlbWFudGlj IGNvbnRlbnQuJm5ic3A7IFRoaXMgcHJvcG9zZWQgY2hhbmdlIGlzIGVzcGVjaWFsbHkgc3VwZXJm bHVvdXMuPG86cD48L286cD48L3NwYW4+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+ IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBN YXkgMjAsIDIwMTMgODoyMSBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlcjxicj4NCjxi PkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gUHJvcG9zZWQgU3ludGF4IENoYW5nZXMgaW4gRHluYW1pYyBSZWdpc3RyYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VlcCBpbiBt aW5kIHRoZXJlIG1heSBiZSBvdGhlciBjaGFuZ2VzIGNvbWluZy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlzIHRo YXQgbmV3IGRldmVsb3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5nIHJl ZmVycmVkIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAy MDEzLTA1LTIwLCBhdCA4OjA5LCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJp Y2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWwgSHVudCdz IHJldmlldyBvZiB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBoYXMgcmFp c2VkIGEgY291cGxlIG9mIGlzc3VlcyB0aGF0IEkgZmVsdCB3ZXJlIGdldHRpbmcgYnVyaWVkIGJ5 IHRoZSBsYXJnZXIgZGlzY3Vzc2lvbiAod2hpY2ggSSBzdGlsbCBzdHJvbmdseSBlbmNvdXJhZ2Ug b3RoZXJzIHRvIGp1bXAgaW4gdG8pLiBOYW1lbHksIFBoaWwgaGFzIHN1Z2dlc3RlZCBhIGNvdXBs ZQ0KIG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFsIHBhcmFtZXRlcnMu IDxicj4NCjxicj4NCjxicj4NCjEpIGV4cGlyZXNfYXQgLSZndDsgY2xpZW50X3NlY3JldF9leHBp cmVzX2F0PGJyPg0KMikgaXNzdWVkX2F0IC0mZ3Q7IGNsaWVudF9pZF9pc3N1ZWRfYXQ8YnI+DQoz KSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCAtJmd0OyB0b2tlbl9lbmRwb2ludF9jbGllbnRf YXV0aF9tZXRob2Q8YnI+DQo8YnI+DQo8YnI+DQpJJ2QgbGlrZSB0byBnZXQgYSBmZWVsaW5nLCA8 Yj5lc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVyczwvYj4gd2hvIGhhdmUgZGVwbG95ZWQgdGhpcyBk cmFmdCBzcGVjLCB3aGF0IHdlIG91Z2h0IHRvIGRvIGZvciBlYWNoIG9mIHRoZXNlOjxicj4NCjxi cj4NCiZuYnNwO0EpIEtlZXAgdGhlIHBhcmFtZXRlciBuYW1lcyBhcy1pczxicj4NCiZuYnNwO0Ip IEFkb3B0IHRoZSBuZXcgbmFtZXMgYXMgYWJvdmU8YnI+DQombmJzcDtDKSBBZG9wdCBhIG5ldyBu YW1lIHRoYXQgSSB3aWxsIHNwZWNpZnk8YnI+DQo8YnI+DQpJbiBhbGwgY2FzZXMsIGNsYXJpZnlp bmcgdGV4dCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBwYXJhbWV0ZXIgKmRlZmluaXRpb25zKiBzbyB0 aGF0IGl0J3MgbW9yZSBjbGVhciB0byBwZW9wbGUgcmVhZGluZyB0aGUgc3BlYyB3aGF0IGVhY2gg cGllY2UgZG9lcy4gU3BlYWtpbmcgYXMgdGhlIGVkaXRvcjogJnF1b3Q7QSZxdW90OyBpcyB0aGUg ZGVmYXVsdCBhcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwgc2luY2Ugd2Ugc2hvdWxkbid0IGNoYW5n ZSBzeW50YXggd2l0aG91dA0KIHZlcnkgZ29vZCByZWFzb24gdG8gZG8gc28uIFRoYXQgc2FpZCwg aWYgaXQncyBnb2luZyB0byBiZSBiZXR0ZXIgZm9yIGRldmVsb3BlcnMgd2l0aCB0aGUgbmV3IHBh cmFtZXRlciBuYW1lcywgSSBhbSBvcGVuIHRvIGZpeGluZyB0aGVtIG5vdy48YnI+DQo8YnI+DQpO YW1pbmcgdGhpbmdzIGlzIGhhcmQuPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B168042967394367742DDATK5EX14MBXC283r_-- From jricher@mitre.org Mon May 20 09:58:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C5C21F96D3 for ; Mon, 20 May 2013 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKCsZW9VnHcN for ; Mon, 20 May 2013 09:58:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 964A821F96D2 for ; Mon, 20 May 2013 09:58:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3437E6250062; Mon, 20 May 2013 12:58:11 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 12B036250065; Mon, 20 May 2013 12:58:11 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 12:58:10 -0400 Message-ID: <519A5606.8010000@mitre.org> Date: Mon, 20 May 2013 12:57:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <4E1F6AAD24975D4BA5B168042967394367742DDA@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367742DDA@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080606060606030103010300" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 16:58:17 -0000 --------------080606060606030103010300 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit For what it's worth, I also agree that (3) is overkill. The other two, I believe, have more potential value in clarity, and I haven't yet heard evidence that making this particular syntax change would be either easy or difficult from other developers. It's possible (though completely conjectural on my part) that nobody's actually using these informational fields yet, so changing them now would be relatively painless on the ground and would make things clearer going forward. -- Justin On 05/20/2013 12:52 PM, Mike Jones wrote: > > I believe that no syntax changes are necessary. > > Of the three possible changes described below, I particularly believe > that (3) is completely unnecessary, as there is nothing that > authenticates to the Token Endpoint other than the client. Thus, > adding “client_” to the name adds no useful semantic content. This > proposed change is especially superfluous. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Phil Hunt > *Sent:* Monday, May 20, 2013 8:21 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out what token is being > referred to. > > > Phil > > > On 2013-05-20, at 8:09, Justin Richer > wrote: > > Phil Hunt's review of the Dynamic Registration specification has > raised a couple of issues that I felt were getting buried by the > larger discussion (which I still strongly encourage others to jump > in to). Namely, Phil has suggested a couple of syntax changes to > the names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from developers* who have > deployed this draft spec, what we ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the parameter > *definitions* so that it's more clear to people reading the spec > what each piece does. Speaking as the editor: "A" is the default > as far as I'm concerned, since we shouldn't change syntax without > very good reason to do so. That said, if it's going to be better > for developers with the new parameter names, I am open to fixing > them now. > > Naming things is hard. > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------080606060606030103010300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit For what it's worth, I also agree that (3) is overkill. The other two, I believe, have more potential value in clarity, and I haven't yet heard evidence that making this particular syntax change would be either easy or difficult from other developers. It's possible (though completely conjectural on my part) that nobody's actually using these informational fields yet, so changing them now would be relatively painless on the ground and would make things clearer going forward.

 -- Justin


On 05/20/2013 12:52 PM, Mike Jones wrote:

I believe that no syntax changes are necessary.

 

Of the three possible changes described below, I particularly believe that (3) is completely unnecessary, as there is nothing that authenticates to the Token Endpoint other than the client.  Thus, adding “client_” to the name adds no useful semantic content.  This proposed change is especially superfluous.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 8:21 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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


--------------080606060606030103010300-- From phil.hunt@oracle.com Mon May 20 10:51:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092A721F8F6E for ; Mon, 20 May 2013 10:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki-EiRuDxmrQ for ; Mon, 20 May 2013 10:51:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2721F94F5 for ; Mon, 20 May 2013 10:51:10 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KHp61i008667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 17:51:07 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KHp777016297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 17:51:08 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KHp7Gq016293; Mon, 20 May 2013 17:51:07 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 10:51:07 -0700 References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-A5BEFF2D-6A6B-4B40-ABCD-3FE243421554 Content-Transfer-Encoding: 7bit Message-Id: <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Mon, 20 May 2013 10:51:02 -0700 To: Mike Jones X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 17:51:17 -0000 --Apple-Mail-A5BEFF2D-6A6B-4B40-ABCD-3FE243421554 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -1 The draft has features that are unclear and will double the operational cost= . The fact that it works doesn't mean it is ready from the wg perspective.=20= For the production use, has anyone outside of oidc implemented and placed in= production? As a non-oidc implementer, I can't make the same assumptions (like discovery= ) that oidc umplementers have.=20 Phil On 2013-05-20, at 9:48, Mike Jones wrote: > The deployment evidence doesn=E2=80=99t support your position, Phil. Ther= e are over a dozen interoperable implementations already deployed. Those de= ployments demonstrate that the spec, as written, is already doing one thing w= ell =E2=80=93 enabling clients (as defined by RFC 6749) to register with Aut= horization Servers, obtaining client_id and optionally client_secret values t= hat enable those clients to use those Authorization Servers. Doing one thin= g well is exactly what we should be striving for, and the evidence says that= we=E2=80=99ve achieved that. > =20 > It=E2=80=99s time to ship it! > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer > Sent: Monday, May 20, 2013 9:42 AM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > =20 > I, of course, disagree. But that's what we're trying to figure out as a wo= rking group, after all. >=20 > -- Justin >=20 > On 05/20/2013 12:41 PM, Phil Hunt wrote: > This draft isn't ready for LC.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:49, Justin Richer wrote: >=20 > But also keep in mind that this is last-call, and that we don't really wan= t to encourage avoidable drastic changes at this stage.=20 >=20 > -- Justin >=20 >=20 > On 05/20/2013 11:21 AM, Phil Hunt wrote: > Keep in mind there may be other changes coming.=20 > =20 > The issue is that new developers can't figure out what token is being refe= rred to.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:09, Justin Richer wrote: >=20 > Phil Hunt's review of the Dynamic Registration specification has raised a c= ouple of issues that I felt were getting buried by the larger discussion (wh= ich I still strongly encourage others to jump in to). Namely, Phil has sugge= sted a couple of syntax changes to the names of several parameters.=20 >=20 >=20 > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >=20 >=20 > I'd like to get a feeling, especially from developers who have deployed th= is draft spec, what we ought to do for each of these: >=20 > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify >=20 > In all cases, clarifying text will be added to the parameter *definitions*= so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned, since we s= houldn't change syntax without very good reason to do so. That said, if it's= going to be better for developers with the new parameter names, I am open t= o fixing them now. >=20 > Naming things is hard. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 --Apple-Mail-A5BEFF2D-6A6B-4B40-ABCD-3FE243421554 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
-1

The draft h= as features that are unclear and will double the operational cost. The fact t= hat it works doesn't mean it is ready from the wg perspective. 

For the production use, has anyone outside of oidc impleme= nted and placed in production?

As a non-oidc implem= enter, I can't make the same assumptions (like discovery) that oidc umplemen= ters have. 

Phil

On 2013-05-20, at 9:48, Mike Jone= s <Michael.Jones@microsoft= .com> wrote:

The deployment evidence doe= sn=E2=80=99t support your position, Phil.  There are over a dozen inter= operable implementations already deployed.  Those deployments demonstra= te that the spec, as written, is already doing one thing well =E2=80=93 enabli= ng clients (as defined by RFC 6749) to register with Authorization Servers, o= btaining client_id and optionally client_secret values that enable those cli= ents to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the evi= dence says that we=E2=80=99ve achieved that.

 

It=E2=80=99s time to ship i= t!

 

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

 

From: oauth-bounce= s@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrati= on

 

I, of course, disagree= . But that's what we're trying to figure out as a working group, after all.<= br>
 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt wrote:

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind t= hat this is last-call, and that we don't really want to encourage avoidable d= rastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. =

 

The issue is that new developers can't figure out wha= t token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specif= ication has raised a couple of issues that I felt were getting buried by the= larger discussion (which I still strongly encourage others to jump in to). N= amely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deploy= ed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* s= o that it's more clear to people reading the spec what each piece does. Spea= king as the editor: "A" is the default as far as I'm concerned, since we sho= uldn't change syntax without very good reason to do so. That said, if it's going to be better for develo= pers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 

 

= --Apple-Mail-A5BEFF2D-6A6B-4B40-ABCD-3FE243421554-- From jricher@mitre.org Mon May 20 11:00:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126E121F93F9 for ; Mon, 20 May 2013 11:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InsYcVrOla0z for ; Mon, 20 May 2013 11:00:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEF21F95D7 for ; Mon, 20 May 2013 11:00:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AE5B12290012; Mon, 20 May 2013 14:00:30 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4DE7D1F071E; Mon, 20 May 2013 14:00:29 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 14:00:29 -0400 Message-ID: <519A64A1.8080003@mitre.org> Date: Mon, 20 May 2013 14:00:01 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> In-Reply-To: <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> Content-Type: multipart/alternative; boundary="------------050903090208080005010109" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:00:37 -0000 --------------050903090208080005010109 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Phil, I think what you're bringing up is a red herring. Everyone that does OAuth today does "discovery" in some manner or another, even if it's not specified to be dynamic like it is in OIDC. Most of the time this happens manually, out of band. For instance, a number of our clients here have historically done "discovery" of the server's capabilities by the client developers just pasting in all the URLs and parameters to their application's configuration. They get these values from the server documentation. Just because a piece of information needs to be known doesn't mean that it needs to be automatically discovered at runtime. And yes, we are using it in a plain-OAuth context here, in addition to an OIDC context. This is using the same server code, for what its worth. I also take issue with your contention that it will "double the operational cost" -- how so? If you don't want to enforce the token_endpoint_auth_method, just don't have your clients send it and don't have the server return it. It's optional for a reason -- if you don't like it or have no use for it, don't use it. -- Justin On 05/20/2013 01:51 PM, Phil Hunt wrote: > -1 > > The draft has features that are unclear and will double the > operational cost. The fact that it works doesn't mean it is ready from > the wg perspective. > > For the production use, has anyone outside of oidc implemented and > placed in production? > > As a non-oidc implementer, I can't make the same assumptions (like > discovery) that oidc umplementers have. > > Phil > > On 2013-05-20, at 9:48, Mike Jones > wrote: > >> The deployment evidence doesn’t support your position, Phil. There >> are over a dozen interoperable implementations already deployed. >> Those deployments demonstrate that the spec, as written, is already >> doing one thing well – enabling clients (as defined by RFC 6749) to >> register with Authorization Servers, obtaining client_id and >> optionally client_secret values that enable those clients to use >> those Authorization Servers. Doing one thing well is exactly what we >> should be striving for, and the evidence says that we’ve achieved that. >> >> It’s time to ship it! >> >> -- Mike >> >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer >> *Sent:* Monday, May 20, 2013 9:42 AM >> *To:* Phil Hunt >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration >> >> I, of course, disagree. But that's what we're trying to figure out as >> a working group, after all. >> >> -- Justin >> >> On 05/20/2013 12:41 PM, Phil Hunt wrote: >> >> This draft isn't ready for LC. >> >> Phil >> >> >> On 2013-05-20, at 8:49, Justin Richer > > wrote: >> >> But also keep in mind that this is last-call, and that we >> don't really want to encourage avoidable drastic changes at >> this stage. >> >> -- Justin >> >> On 05/20/2013 11:21 AM, Phil Hunt wrote: >> >> Keep in mind there may be other changes coming. >> >> The issue is that new developers can't figure out what >> token is being referred to. >> >> >> Phil >> >> >> On 2013-05-20, at 8:09, Justin Richer > > wrote: >> >> Phil Hunt's review of the Dynamic Registration >> specification has raised a couple of issues that I >> felt were getting buried by the larger discussion >> (which I still strongly encourage others to jump in >> to). Namely, Phil has suggested a couple of syntax >> changes to the names of several parameters. >> >> >> 1) expires_at -> client_secret_expires_at >> 2) issued_at -> client_id_issued_at >> 3) token_endpoint_auth_method -> >> token_endpoint_client_auth_method >> >> >> I'd like to get a feeling, *especially from >> developers* who have deployed this draft spec, what >> we ought to do for each of these: >> >> A) Keep the parameter names as-is >> B) Adopt the new names as above >> C) Adopt a new name that I will specify >> >> In all cases, clarifying text will be added to the >> parameter *definitions* so that it's more clear to >> people reading the spec what each piece does. >> Speaking as the editor: "A" is the default as far as >> I'm concerned, since we shouldn't change syntax >> without very good reason to do so. That said, if it's >> going to be better for developers with the new >> parameter names, I am open to fixing them now. >> >> Naming things is hard. >> >> -- Justin >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> --------------050903090208080005010109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Phil, I think what you're bringing up is a red herring. Everyone that does OAuth today does "discovery" in some manner or another, even if it's not specified to be dynamic like it is in OIDC. Most of the time this happens manually, out of band. For instance, a number of our clients here have historically done "discovery" of the server's capabilities by the client developers just pasting in all the URLs and parameters to their application's configuration. They get these values from the server documentation. Just because a piece of information needs to be known doesn't mean that it needs to be automatically discovered at runtime.

And yes, we are using it in a plain-OAuth context here, in addition to an OIDC context. This is using the same server code, for what its worth.

I also take issue with your contention that it will "double the operational cost" -- how so? If you don't want to enforce the token_endpoint_auth_method, just don't have your clients send it and don't have the server return it. It's optional for a reason -- if you don't like it or have no use for it, don't use it.

 -- Justin

On 05/20/2013 01:51 PM, Phil Hunt wrote:
-1

The draft has features that are unclear and will double the operational cost. The fact that it works doesn't mean it is ready from the wg perspective. 

For the production use, has anyone outside of oidc implemented and placed in production?

As a non-oidc implementer, I can't make the same assumptions (like discovery) that oidc umplementers have. 

Phil

On 2013-05-20, at 9:48, Mike Jones <Michael.Jones@microsoft.com> wrote:

The deployment evidence doesn’t support your position, Phil.  There are over a dozen interoperable implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well – enabling clients (as defined by RFC 6749) to register with Authorization Servers, obtaining client_id and optionally client_secret values that enable those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the evidence says that we’ve achieved that.

 

It’s time to ship it!

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

I, of course, disagree. But that's what we're trying to figure out as a working group, after all.

 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt wrote:

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 

 


--------------050903090208080005010109-- From jricher@mitre.org Mon May 20 11:11:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8524621F95E0 for ; Mon, 20 May 2013 11:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvhWSI5AzJ3a for ; Mon, 20 May 2013 11:10:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC221F95F1 for ; Mon, 20 May 2013 11:10:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5921D1F04E6; Mon, 20 May 2013 14:10:58 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1F5C01F0446; Mon, 20 May 2013 14:10:58 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 14:10:57 -0400 Message-ID: <519A6715.9040904@mitre.org> Date: Mon, 20 May 2013 14:10:29 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Anthony Nadalin References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040305010804040709000408" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:11:04 -0000 --------------040305010804040709000408 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Tony, can you be more specific? What needs to be changed in your opinion? What text changes would you suggest? -- Justin On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > > Agree > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Phil Hunt > *Sent:* Monday, May 20, 2013 9:42 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > This draft isn't ready for LC. > > Phil > > > On 2013-05-20, at 8:49, Justin Richer > wrote: > > But also keep in mind that this is last-call, and that we don't > really want to encourage avoidable drastic changes at this stage. > > -- Justin > > On 05/20/2013 11:21 AM, Phil Hunt wrote: > > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out what token > is being referred to. > > > Phil > > > On 2013-05-20, at 8:09, Justin Richer > wrote: > > Phil Hunt's review of the Dynamic Registration > specification has raised a couple of issues that I felt > were getting buried by the larger discussion (which I > still strongly encourage others to jump in to). Namely, > Phil has suggested a couple of syntax changes to the names > of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> > token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from developers* > who have deployed this draft spec, what we ought to do for > each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the > parameter *definitions* so that it's more clear to people > reading the spec what each piece does. Speaking as the > editor: "A" is the default as far as I'm concerned, since > we shouldn't change syntax without very good reason to do > so. That said, if it's going to be better for developers > with the new parameter names, I am open to fixing them now. > > Naming things is hard. > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040305010804040709000408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Tony, can you be more specific? What needs to be changed in your opinion? What text changes would you suggest?

 -- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin wrote:

Agree

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 


--------------040305010804040709000408-- From tonynad@microsoft.com Mon May 20 11:11:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5F21F960C for ; Mon, 20 May 2013 11:11:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+i6M7Oub5R5 for ; Mon, 20 May 2013 11:11:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4021F95E0 for ; Mon, 20 May 2013 11:11:20 -0700 (PDT) Received: from BN1BFFO11FD010.protection.gbl (10.58.52.200) by BN1BFFO11HUB011.protection.gbl (10.58.53.121) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 18:11:18 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD010.mail.protection.outlook.com (10.58.53.70) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 20 May 2013 18:11:18 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 20 May 2013 18:10:50 +0000 Received: from mail119-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 18:09:46 +0000 Received: from mail119-co1 (localhost [127.0.0.1]) by mail119-co1-R.bigfish.com (Postfix) with ESMTP id 58E2D340489 for ; Mon, 20 May 2013 18:09:46 +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: -22 X-BigFish: PS-22(zzbb2dI98dI9371I936eI1e83Mc857hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh17ej9a9j1155h) Received-SPF: softfail (mail119-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:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail119-co1 (localhost.localdomain [127.0.0.1]) by mail119-co1 (MessageSwitch) id 1369073384261197_26191; Mon, 20 May 2013 18:09:44 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.254]) by mail119-co1.bigfish.com (Postfix) with ESMTP id 3C5C32004B; Mon, 20 May 2013 18:09:44 +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; Mon, 20 May 2013 18:09:44 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.311.1; Mon, 20 May 2013 18:09:42 +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.698.13; Mon, 20 May 2013 18:09:40 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) with mapi id 15.00.0698.010; Mon, 20 May 2013 18:09:39 +0000 From: Anthony Nadalin To: Phil Hunt , Justin Richer Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWw2HOVR1MGBX02Be07cmNz/cpkOMHcAgAAH54CAAA6lAIAAGIDA Date: Mon, 20 May 2013 18:09:38 +0000 Message-ID: References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:2a:2:3c75:56df:35ea:3e93] Content-Type: multipart/alternative; boundary="_000_a71babc7649b457e899f07954756a635BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.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%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(78114002)(24454002)(377424003)(189002)(199002)(479174002)(377454002)(63696002)(81342001)(74502001)(15202345002)(50986001)(54356001)(47446002)(53806001)(79102001)(46102001)(31966008)(74662001)(33646001)(81542001)(16236675002)(512874002)(71186001)(6806003)(4396001)(69226001)(76482001)(16676001)(74876001)(74366001)(74706001)(77982001)(59766001)(49866001)(47736001)(20776003)(65816001)(51856001)(54316002)(80022001)(74316001)(56776001)(47976001)(56816002)(42262001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB011; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0852EB6797 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:11:33 -0000 --_000_a71babc7649b457e899f07954756a635BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IE1vbmRheSwgTWF5IDIw LCAyMDEzIDk6NDIgQU0NClRvOiBKdXN0aW4gUmljaGVyDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFtaWMg UmVnaXN0cmF0aW9uDQoNClRoaXMgZHJhZnQgaXNuJ3QgcmVhZHkgZm9yIExDLg0KDQpQaGlsDQoN Ck9uIDIwMTMtMDUtMjAsIGF0IDg6NDksIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3Jn PG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KQnV0IGFsc28ga2VlcCBpbiBtaW5k IHRoYXQgdGhpcyBpcyBsYXN0LWNhbGwsIGFuZCB0aGF0IHdlIGRvbid0IHJlYWxseSB3YW50IHRv IGVuY291cmFnZSBhdm9pZGFibGUgZHJhc3RpYyBjaGFuZ2VzIGF0IHRoaXMgc3RhZ2UuDQoNCiAt LSBKdXN0aW4NCg0KT24gMDUvMjAvMjAxMyAxMToyMSBBTSwgUGhpbCBIdW50IHdyb3RlOg0KS2Vl cCBpbiBtaW5kIHRoZXJlIG1heSBiZSBvdGhlciBjaGFuZ2VzIGNvbWluZy4NCg0KVGhlIGlzc3Vl IGlzIHRoYXQgbmV3IGRldmVsb3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJl aW5nIHJlZmVycmVkIHRvLg0KDQpQaGlsDQoNCk9uIDIwMTMtMDUtMjAsIGF0IDg6MDksIEp1c3Rp biBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdy b3RlOg0KUGhpbCBIdW50J3MgcmV2aWV3IG9mIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVj aWZpY2F0aW9uIGhhcyByYWlzZWQgYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSBmZWx0IHdlcmUg Z2V0dGluZyBidXJpZWQgYnkgdGhlIGxhcmdlciBkaXNjdXNzaW9uICh3aGljaCBJIHN0aWxsIHN0 cm9uZ2x5IGVuY291cmFnZSBvdGhlcnMgdG8ganVtcCBpbiB0bykuIE5hbWVseSwgUGhpbCBoYXMg c3VnZ2VzdGVkIGEgY291cGxlIG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBvZiBzZXZl cmFsIHBhcmFtZXRlcnMuDQoNCg0KMSkgZXhwaXJlc19hdCAtPiBjbGllbnRfc2VjcmV0X2V4cGly ZXNfYXQNCjIpIGlzc3VlZF9hdCAtPiBjbGllbnRfaWRfaXNzdWVkX2F0DQozKSB0b2tlbl9lbmRw b2ludF9hdXRoX21ldGhvZCAtPiB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QNCg0K DQpJJ2QgbGlrZSB0byBnZXQgYSBmZWVsaW5nLCBlc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVycyB3 aG8gaGF2ZSBkZXBsb3llZCB0aGlzIGRyYWZ0IHNwZWMsIHdoYXQgd2Ugb3VnaHQgdG8gZG8gZm9y IGVhY2ggb2YgdGhlc2U6DQoNCiBBKSBLZWVwIHRoZSBwYXJhbWV0ZXIgbmFtZXMgYXMtaXMNCiBC KSBBZG9wdCB0aGUgbmV3IG5hbWVzIGFzIGFib3ZlDQogQykgQWRvcHQgYSBuZXcgbmFtZSB0aGF0 IEkgd2lsbCBzcGVjaWZ5DQoNCkluIGFsbCBjYXNlcywgY2xhcmlmeWluZyB0ZXh0IHdpbGwgYmUg YWRkZWQgdG8gdGhlIHBhcmFtZXRlciAqZGVmaW5pdGlvbnMqIHNvIHRoYXQgaXQncyBtb3JlIGNs ZWFyIHRvIHBlb3BsZSByZWFkaW5nIHRoZSBzcGVjIHdoYXQgZWFjaCBwaWVjZSBkb2VzLiBTcGVh a2luZyBhcyB0aGUgZWRpdG9yOiAiQSIgaXMgdGhlIGRlZmF1bHQgYXMgZmFyIGFzIEknbSBjb25j ZXJuZWQsIHNpbmNlIHdlIHNob3VsZG4ndCBjaGFuZ2Ugc3ludGF4IHdpdGhvdXQgdmVyeSBnb29k IHJlYXNvbiB0byBkbyBzby4gVGhhdCBzYWlkLCBpZiBpdCdzIGdvaW5nIHRvIGJlIGJldHRlciBm b3IgZGV2ZWxvcGVycyB3aXRoIHRoZSBuZXcgcGFyYW1ldGVyIG5hbWVzLCBJIGFtIG9wZW4gdG8g Zml4aW5nIHRoZW0gbm93Lg0KDQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQuDQoNCiAtLSBKdXN0aW4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_a71babc7649b457e899f07954756a635BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBI dW50PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIwLCAyMDEzIDk6NDIgQU08YnI+DQo8 Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2Vz IGluIER5bmFtaWMgUmVnaXN0cmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgaXNuJ3QgcmVhZHkgZm9yIExDLiZuYnNw Ozxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjAxMy0w NS0yMCwgYXQgODo0OSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0cmUub3JnIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkJ1dCBhbHNvIGtlZXAgaW4gbWluZCB0aGF0IHRoaXMgaXMgbGFzdC1jYWxs LCBhbmQgdGhhdCB3ZSBkb24ndCByZWFsbHkgd2FudCB0byBlbmNvdXJhZ2UgYXZvaWRhYmxlIGRy YXN0aWMgY2hhbmdlcyBhdCB0aGlzIHN0YWdlLg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGlu PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMDUvMjAvMjAxMyAxMToyMSBBTSwgUGhpbCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZWVwIGluIG1pbmQgdGhlcmUg bWF5IGJlIG90aGVyIGNoYW5nZXMgY29taW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWUgaXMgdGhhdCBuZXcgZGV2 ZWxvcGVycyBjYW4ndCBmaWd1cmUgb3V0IHdoYXQgdG9rZW4gaXMgYmVpbmcgcmVmZXJyZWQgdG8u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIwMTMtMDUtMjAs IGF0IDg6MDksIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJl Lm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbCBIdW50J3MgcmV2aWV3IG9m IHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uIGhhcyByYWlzZWQgYSBjb3Vw bGUgb2YgaXNzdWVzIHRoYXQgSSBmZWx0IHdlcmUgZ2V0dGluZyBidXJpZWQgYnkgdGhlIGxhcmdl ciBkaXNjdXNzaW9uICh3aGljaCBJIHN0aWxsIHN0cm9uZ2x5IGVuY291cmFnZSBvdGhlcnMgdG8g anVtcCBpbiB0bykuIE5hbWVseSwgUGhpbCBoYXMgc3VnZ2VzdGVkIGEgY291cGxlDQogb2Ygc3lu dGF4IGNoYW5nZXMgdG8gdGhlIG5hbWVzIG9mIHNldmVyYWwgcGFyYW1ldGVycy4gPGJyPg0KPGJy Pg0KPGJyPg0KMSkgZXhwaXJlc19hdCAtJmd0OyBjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXQ8YnI+ DQoyKSBpc3N1ZWRfYXQgLSZndDsgY2xpZW50X2lkX2lzc3VlZF9hdDxicj4NCjMpIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kIC0mZ3Q7IHRva2VuX2VuZHBvaW50X2NsaWVudF9hdXRoX21ldGhv ZDxicj4NCjxicj4NCjxicj4NCkknZCBsaWtlIHRvIGdldCBhIGZlZWxpbmcsIDxiPmVzcGVjaWFs bHkgZnJvbSBkZXZlbG9wZXJzPC9iPiB3aG8gaGF2ZSBkZXBsb3llZCB0aGlzIGRyYWZ0IHNwZWMs IHdoYXQgd2Ugb3VnaHQgdG8gZG8gZm9yIGVhY2ggb2YgdGhlc2U6PGJyPg0KPGJyPg0KJm5ic3A7 QSkgS2VlcCB0aGUgcGFyYW1ldGVyIG5hbWVzIGFzLWlzPGJyPg0KJm5ic3A7QikgQWRvcHQgdGhl IG5ldyBuYW1lcyBhcyBhYm92ZTxicj4NCiZuYnNwO0MpIEFkb3B0IGEgbmV3IG5hbWUgdGhhdCBJ IHdpbGwgc3BlY2lmeTxicj4NCjxicj4NCkluIGFsbCBjYXNlcywgY2xhcmlmeWluZyB0ZXh0IHdp bGwgYmUgYWRkZWQgdG8gdGhlIHBhcmFtZXRlciAqZGVmaW5pdGlvbnMqIHNvIHRoYXQgaXQncyBt b3JlIGNsZWFyIHRvIHBlb3BsZSByZWFkaW5nIHRoZSBzcGVjIHdoYXQgZWFjaCBwaWVjZSBkb2Vz LiBTcGVha2luZyBhcyB0aGUgZWRpdG9yOiAmcXVvdDtBJnF1b3Q7IGlzIHRoZSBkZWZhdWx0IGFz IGZhciBhcyBJJ20gY29uY2VybmVkLCBzaW5jZSB3ZSBzaG91bGRuJ3QgY2hhbmdlIHN5bnRheCB3 aXRob3V0DQogdmVyeSBnb29kIHJlYXNvbiB0byBkbyBzby4gVGhhdCBzYWlkLCBpZiBpdCdzIGdv aW5nIHRvIGJlIGJldHRlciBmb3IgZGV2ZWxvcGVycyB3aXRoIHRoZSBuZXcgcGFyYW1ldGVyIG5h bWVzLCBJIGFtIG9wZW4gdG8gZml4aW5nIHRoZW0gbm93Ljxicj4NCjxicj4NCk5hbWluZyB0aGlu Z3MgaXMgaGFyZC48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a71babc7649b457e899f07954756a635BY2PR03MB041namprd03pro_-- From phil.hunt@oracle.com Mon May 20 11:27:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03FB21F8648 for ; Mon, 20 May 2013 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEVrzjp+6Wfo for ; Mon, 20 May 2013 11:27:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A757C21F8523 for ; Mon, 20 May 2013 11:27:05 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KIR4Sp023155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 18:27:04 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KIR3Xt026241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 18:27:04 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KIR3aR009635; Mon, 20 May 2013 18:27:03 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 11:27:03 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4ED4F43C-8B87-4BFE-A929-3397DB3AAA83" From: Phil Hunt In-Reply-To: <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> Date: Mon, 20 May 2013 11:27:07 -0700 Message-Id: References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> To: Mike Jones X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:27:11 -0000 --Apple-Mail=_4ED4F43C-8B87-4BFE-A929-3397DB3AAA83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Further to my last=85 Justin has already committed to breaking changes. This may have been = lost or buried in the long review thread. Specifically - The client authentication types specified are = undocumented (client_secret_jwt and private_key_jwt) as they were all = Holder-of-Key authentication methods. The OAuth drafts currently only = have bearer drafts and dyn reg does not support these profiles. Justin = has acknowledged this. It seems to me, that since the token_endpoint_auth_method is broken, the = current implementations are actually implementing the draft correctly or = servers are just ignoring it the parameter. There are concerns with this draft. I plan to make specific suggestions = (some breaking) later this week. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-20, at 10:51 AM, Phil Hunt wrote: > -1 >=20 > The draft has features that are unclear and will double the = operational cost. The fact that it works doesn't mean it is ready from = the wg perspective.=20 >=20 > For the production use, has anyone outside of oidc implemented and = placed in production? >=20 > As a non-oidc implementer, I can't make the same assumptions (like = discovery) that oidc umplementers have.=20 >=20 > Phil >=20 > On 2013-05-20, at 9:48, Mike Jones = wrote: >=20 >> The deployment evidence doesn=92t support your position, Phil. There = are over a dozen interoperable implementations already deployed. Those = deployments demonstrate that the spec, as written, is already doing one = thing well =96 enabling clients (as defined by RFC 6749) to register = with Authorization Servers, obtaining client_id and optionally = client_secret values that enable those clients to use those = Authorization Servers. Doing one thing well is exactly what we should = be striving for, and the evidence says that we=92ve achieved that. >> =20 >> It=92s time to ship it! >> =20 >> -- = Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Justin Richer >> Sent: Monday, May 20, 2013 9:42 AM >> To: Phil Hunt >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration >> =20 >> I, of course, disagree. But that's what we're trying to figure out as = a working group, after all. >>=20 >> -- Justin >>=20 >> On 05/20/2013 12:41 PM, Phil Hunt wrote: >> This draft isn't ready for LC.=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 8:49, Justin Richer wrote: >>=20 >> But also keep in mind that this is last-call, and that we don't = really want to encourage avoidable drastic changes at this stage.=20 >>=20 >> -- Justin >>=20 >>=20 >> On 05/20/2013 11:21 AM, Phil Hunt wrote: >> Keep in mind there may be other changes coming.=20 >> =20 >> The issue is that new developers can't figure out what token is being = referred to.=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 8:09, Justin Richer wrote: >>=20 >> Phil Hunt's review of the Dynamic Registration specification has = raised a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 >>=20 >>=20 >> 1) expires_at -> client_secret_expires_at >> 2) issued_at -> client_id_issued_at >> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >>=20 >>=20 >> I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these: >>=20 >> A) Keep the parameter names as-is >> B) Adopt the new names as above >> C) Adopt a new name that I will specify >>=20 >> In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. >>=20 >> Naming things is hard. >>=20 >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4ED4F43C-8B87-4BFE-A929-3397DB3AAA83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 token_endpoint_auth_method is = broken, the current implementations are actually implementing the draft = correctly or servers are just ignoring it the = parameter.

There are concerns with this draft. =  I plan to make specific suggestions (some breaking) later this = week.

Phil

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





On 2013-05-20, at 10:51 AM, Phil Hunt wrote:

-1

The draft has features = that are unclear and will double the operational cost. The fact that it = works doesn't mean it is ready from the wg = perspective. 

For the production use, has = anyone outside of oidc implemented and placed in = production?

As a non-oidc implementer, I can't = make the same assumptions (like discovery) that oidc umplementers = have. 

Phil

On 2013-05-20, at 9:48, Mike Jones = <Michael.Jones@microsoft.com> wrote:

The deployment evidence doesn=92t support your = position, Phil.  There are over a dozen interoperable = implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well =96 enabling = clients (as defined by RFC 6749) to register with Authorization Servers, = obtaining client_id and optionally client_secret values that enable = those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the = evidence says that we=92ve achieved that.

 

It=92s time to ship it!

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

I, of course, disagree. But that's what = we're trying to figure out as a working group, after all.

 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt = wrote:

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> = wrote:

But also keep = in mind that this is last-call, and that we don't really want to = encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt = wrote:

Keep in mind there may be other changes = coming. 

 

The issue is that new developers can't = figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> = wrote:

Phil Hunt's review of the Dynamic = Registration specification has raised a couple of issues that I felt = were getting buried by the larger discussion (which I still strongly = encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for = developers with the new parameter names, I am open to fixing them = now.

Naming things is hard.

 -- Justin

_______________________________________________
OAuth mailing 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=_4ED4F43C-8B87-4BFE-A929-3397DB3AAA83-- From jricher@mitre.org Mon May 20 11:39:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3804D21F8AEA for ; Mon, 20 May 2013 11:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO3EZfYOnbI3 for ; Mon, 20 May 2013 11:39:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DB9FE21F8A74 for ; Mon, 20 May 2013 11:39:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C80A1F06F8; Mon, 20 May 2013 14:39:38 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 463891F0437; Mon, 20 May 2013 14:39:38 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 14:39:38 -0400 Message-ID: <519A6DCD.3050200@mitre.org> Date: Mon, 20 May 2013 14:39:09 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000005020407090705010008" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:39:44 -0000 --------------000005020407090705010008 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Phil, that's not a fair comparison. What I've done is a fundamentally different kind of breaking change than the one you're asking for, though. To explain more concretely: The change I agreed to make here was to remove two underspecified values (of five listed) to a parameter that is intended to be extensible. The extensions to DynReg that are using these values (like OIDC registration) can then define them fully (like they already are). That is a good change, and prompted by the good discussion and feedback you've given here. That doesn't mean that the parameter itself is "broken", and I think it's entirely another thing to remove the parameter wholesale when it has proven utility. Getting rid of it entirely would make it an OIDC-only parameter, when people are using it in non-OIDC contexts. I acknowledge the concerns that you have with the draft, and I thank you for your feedback so far. However, I don't agree with your conclusions regarding those concerns. I do look forward to any concrete proposals you'll have later this week that will help further this discussion. -- Justin On 05/20/2013 02:27 PM, Phil Hunt wrote: > Further to my last... > > Justin has already committed to breaking changes. This may have been > lost or buried in the long review thread. > > Specifically - The client authentication types specified are > undocumented (client_secret_jwt and private_key_jwt) as they were all > Holder-of-Key authentication methods. The OAuth drafts currently only > have bearer drafts and dyn reg does not support these profiles. > Justin has acknowledged this. > > It seems to me, that since the token_endpoint_auth_method is broken, > the current implementations are actually implementing the draft > correctly or servers are just ignoring it the parameter. > > There are concerns with this draft. I plan to make specific > suggestions (some breaking) later this week. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-20, at 10:51 AM, Phil Hunt wrote: > >> -1 >> >> The draft has features that are unclear and will double the >> operational cost. The fact that it works doesn't mean it is ready >> from the wg perspective. >> >> For the production use, has anyone outside of oidc implemented and >> placed in production? >> >> As a non-oidc implementer, I can't make the same assumptions (like >> discovery) that oidc umplementers have. >> >> Phil >> >> On 2013-05-20, at 9:48, Mike Jones > > wrote: >> >>> The deployment evidence doesn't support your position, Phil. There >>> are over a dozen interoperable implementations already deployed. >>> Those deployments demonstrate that the spec, as written, is already >>> doing one thing well -- enabling clients (as defined by RFC 6749) to >>> register with Authorization Servers, obtaining client_id and >>> optionally client_secret values that enable those clients to use >>> those Authorization Servers. Doing one thing well is exactly what >>> we should be striving for, and the evidence says that we've achieved >>> that. >>> >>> It's time to ship it! >>> >>> -- Mike >>> >>> *From:*oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer >>> *Sent:* Monday, May 20, 2013 9:42 AM >>> *To:* Phil Hunt >>> *Cc:* oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic >>> Registration >>> >>> I, of course, disagree. But that's what we're trying to figure out >>> as a working group, after all. >>> >>> -- Justin >>> >>> On 05/20/2013 12:41 PM, Phil Hunt wrote: >>> >>> This draft isn't ready for LC. >>> >>> Phil >>> >>> >>> On 2013-05-20, at 8:49, Justin Richer >> > wrote: >>> >>> But also keep in mind that this is last-call, and that we >>> don't really want to encourage avoidable drastic changes at >>> this stage. >>> >>> -- Justin >>> >>> On 05/20/2013 11:21 AM, Phil Hunt wrote: >>> >>> Keep in mind there may be other changes coming. >>> >>> The issue is that new developers can't figure out what >>> token is being referred to. >>> >>> >>> Phil >>> >>> >>> On 2013-05-20, at 8:09, Justin Richer >> > wrote: >>> >>> Phil Hunt's review of the Dynamic Registration >>> specification has raised a couple of issues that I >>> felt were getting buried by the larger discussion >>> (which I still strongly encourage others to jump in >>> to). Namely, Phil has suggested a couple of syntax >>> changes to the names of several parameters. >>> >>> >>> 1) expires_at -> client_secret_expires_at >>> 2) issued_at -> client_id_issued_at >>> 3) token_endpoint_auth_method -> >>> token_endpoint_client_auth_method >>> >>> >>> I'd like to get a feeling, *especially from >>> developers* who have deployed this draft spec, what >>> we ought to do for each of these: >>> >>> A) Keep the parameter names as-is >>> B) Adopt the new names as above >>> C) Adopt a new name that I will specify >>> >>> In all cases, clarifying text will be added to the >>> parameter *definitions* so that it's more clear to >>> people reading the spec what each piece does. >>> Speaking as the editor: "A" is the default as far as >>> I'm concerned, since we shouldn't change syntax >>> without very good reason to do so. That said, if >>> it's going to be better for developers with the new >>> parameter names, I am open to fixing them now. >>> >>> Naming things is hard. >>> >>> -- Justin >>> >>> _______________________________________________ >>> OAuth mailing 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 --------------000005020407090705010008 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Phil, that's not a fair comparison. What I've done is a fundamentally different kind of breaking change than the one you're asking for, though.

To explain more concretely: The change I agreed to make here was to remove two underspecified values (of five listed) to a parameter that is intended to be extensible. The extensions to DynReg that are using these values (like OIDC registration) can then define them fully (like they already are). That is a good change, and prompted by the good discussion and feedback you've given here. That doesn't mean that the parameter itself is "broken", and I think it's entirely another thing to remove the parameter wholesale when it has proven utility. Getting rid of it entirely would make it an OIDC-only parameter, when people are using it in non-OIDC contexts.

I acknowledge the concerns that you have with the draft, and I thank you for your feedback so far. However, I don't agree with your conclusions regarding those concerns. I do look forward to any concrete proposals you'll have later this week that will help further this discussion.

 -- Justin


On 05/20/2013 02:27 PM, Phil Hunt wrote:
Further to my last…

Justin has already committed to breaking changes.  This may have been lost or buried in the long review thread.

Specifically - The client authentication types specified are undocumented (client_secret_jwt and private_key_jwt) as they were all Holder-of-Key authentication methods.  The OAuth drafts currently only have bearer drafts and dyn reg does not support these profiles.  Justin has acknowledged this.

It seems to me, that since the token_endpoint_auth_method is broken, the current implementations are actually implementing the draft correctly or servers are just ignoring it the parameter.

There are concerns with this draft.  I plan to make specific suggestions (some breaking) later this week.


On 2013-05-20, at 10:51 AM, Phil Hunt wrote:

-1

The draft has features that are unclear and will double the operational cost. The fact that it works doesn't mean it is ready from the wg perspective. 

For the production use, has anyone outside of oidc implemented and placed in production?

As a non-oidc implementer, I can't make the same assumptions (like discovery) that oidc umplementers have. 

Phil

On 2013-05-20, at 9:48, Mike Jones <Michael.Jones@microsoft.com> wrote:

The deployment evidence doesn’t support your position, Phil.  There are over a dozen interoperable implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well – enabling clients (as defined by RFC 6749) to register with Authorization Servers, obtaining client_id and optionally client_secret values that enable those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the evidence says that we’ve achieved that.

 

It’s time to ship it!

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

I, of course, disagree. But that's what we're trying to figure out as a working group, after all.

 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt wrote:

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

_______________________________________________
OAuth mailing 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

--------------000005020407090705010008-- From sakimura@gmail.com Mon May 20 11:42:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4321F8E56 for ; Mon, 20 May 2013 11:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEtAlwyg6-FM for ; Mon, 20 May 2013 11:42:15 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5821F8B18 for ; Mon, 20 May 2013 11:42:14 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ea20so2861647lab.12 for ; Mon, 20 May 2013 11:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=bgIiPsk5uIkG4eHrZcCoHdcVhDYm9HGrNmritQtkMHs=; b=1DNXGdMU/pcET06B0ZYm2c/RIO+LPiP+/oaFAwKaNDInb+egFi9VTV9PhBD8IcLkdX Wdb7ElvpVoFl4poj1uuvqAnFC2drYV3jo4ZmMaK319DfJg3kRSpm8j2oZkySKBmWEuvV QR3b3dNsUV5bdbs6TAgOdPfJNcpDluh/uBxBlRBsoWDfegjf+GkH/jxTAVPDCe1UMSWO DuEjC+ZtY+IBntrG7lb8Bju9pBcnIo8DdFHNuBsy1G0qjGsfZDpcYgiqbteQyiE5HsiP mF/Pr6yR4Bufmm1wuA8EByCJ5eHACwdK1fSr6cN5W4yBY79mAo1deQ8tZG6erq5i2fBF s0tg== X-Received: by 10.152.115.173 with SMTP id jp13mr29029207lab.49.1369075333519; Mon, 20 May 2013 11:42:13 -0700 (PDT) References: <519A3C9A.8060305@mitre.org> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <519A3C9A.8060305@mitre.org> Date: Mon, 20 May 2013 20:42:09 +0200 Message-ID: <-3365254035477557424@unknownmsgid> To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c235dced69ce04dd2ab03c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 18:42:16 -0000 --001a11c235dced69ce04dd2ab03c Content-Type: text/plain; charset=ISO-8859-1 No change please. =nat via iPhone On May 20, 2013, at 17:10, Justin Richer wrote: Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, *especially from developers* who have deployed this draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now. Naming things is hard. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a11c235dced69ce04dd2ab03c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No change please.=A0

=3Dnat= via iPhone

On May 20, 2013, at 17:10, Justin Richer <jricher@mitre.org> wrote:

=20 =20 =20 Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

=A0A) Keep the parameter names as-is
=A0B) Adopt the new names as above
=A0C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the defa= ult as far as I'm concerned, since we shouldn't change syntax without = very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

=A0-- Justin
=20
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth
--001a11c235dced69ce04dd2ab03c-- From edmundjay@sbcglobal.net Mon May 20 13:24:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CC421F93FC for ; Mon, 20 May 2013 13:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByVdB5CANkZz for ; Mon, 20 May 2013 13:23:54 -0700 (PDT) Received: from nm12-vm0.access.bullet.mail.mud.yahoo.com (nm12-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.11]) by ietfa.amsl.com (Postfix) with ESMTP id B5CA321F93B6 for ; Mon, 20 May 2013 13:23:54 -0700 (PDT) Received: from [66.94.237.199] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 20 May 2013 20:23:54 -0000 Received: from [66.94.237.102] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 20 May 2013 20:23:54 -0000 Received: from [127.0.0.1] by omp1007.access.mail.mud.yahoo.com with NNFMP; 20 May 2013 20:23:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 239544.32422.bm@omp1007.access.mail.mud.yahoo.com Received: (qmail 32060 invoked by uid 60001); 20 May 2013 20:23:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1369081433; bh=MVQGoCsvp0mxmC5zWQh6HN8hZjplW5/YvHSoU69dBK8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Rep3PL3Ofhui+xrv9HPfPG7NVP9DKQCWRCCOQXJKEjVjIokPoOM65w97zNmNSn8bI/GyxxkzAe0U5mFkll0RkZaixS+IwpZHZFoKdfzvg0mSn8K5roWnXlTt3g4qda6x2b2YswA/TjrXj9S6T5iny76G7GvKZdDAmd3vZIj1cxM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=byZgk544CjNw0H6P0l25dqYu/Fb2EYAoCaDAgjgaHCeyVgN/l+xjRcQOG1EnzOGotvHYEdqLTi+N961j1s/dtuxvMKxiqMqdDTlocPejy/UBAJJ4nbni//QfvcbZNQ9KxtrBHyPv0gMz+GeDqCjR3e00CtCO1zG9kLJnjVWf5vk=; X-YMail-OSG: d9_64QoVM1mlL5pgaEDJm0dX9OAwKpba062UELtoBsKNXEd 5dGXUSUT4VLIaUqLpem0ua7ZZmDVd8a6oJ2dfp.YsOHNKnFAFx9FJz3LIO72 etnepJPivPhYY9hyup.RZmrdDHR_CTOJeQ6acSKPM2hMkUSGvojFsSX1CyVF fais28pOa0AqO.PvUVXUmO71n1oEuK9ZZs.RP6uEMYpx13nbRV9S0THeAVU4 HihimYZPvFGeOS6QpZjfhmhQ8KgbsjDnmo6F51UyOEORakNtIELjlbhoXgw8 KcImBCGFg6tSyykoQOOppHjxX13kue4pIBopfT7KVEqwCwWfNtMQm7cIWXqI SCIcAMLeTSA7dv06xoXVP7aug8qmahvJ7ZnMNvuBOlT5w6YYMqw0DRvSxoES DkKdKP3M3HhQjIAAbo6qPeB09aNM239IA3imNZ9evP8XwgMJvUbkvyz1f5vB 3OGVBwrVobgPLtBNirHHDjF85vPysri00rMV2sEOCtt7UVYgy_0YG.uiFhzP ANO44pdXd2r75vS5IZYSqUAvq4A-- Received: from [70.36.254.42] by web184401.mail.bf1.yahoo.com via HTTP; Mon, 20 May 2013 13:23:53 PDT X-Rocket-MIMEInfo: 002.001, KzEgZm9yIGtlZXBpbmcgbmFtZXMgYXMgaXMuCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPgpUbzogIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc.ClNlbnQ6IE1vbiwgTWF5IDIwLCAyMDEzIDg6MTA6MTMgQU0KU3ViamVjdDogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbgoKUGhpbCBIdW50J3MgcmV2aWV3IG9mIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGkBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/729 YahooMailWebService/0.8.142.542 References: <519A3C9A.8060305@mitre.org> Message-ID: <1369081433.10108.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Mon, 20 May 2013 13:23:53 -0700 (PDT) From: Edmund Jay To: Justin Richer , "oauth@ietf.org" In-Reply-To: <519A3C9A.8060305@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1009959307-1404435011-1369081433=:10108" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 20:24:01 -0000 --1009959307-1404435011-1369081433=:10108 Content-Type: text/plain; charset=us-ascii +1 for keeping names as is. ________________________________ From: Justin Richer To: "oauth@ietf.org" Sent: Mon, May 20, 2013 8:10:13 AM Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now. Naming things is hard. -- Justin --1009959307-1404435011-1369081433=:10108 Content-Type: text/html; charset=us-ascii
+1 for keeping names as is.

From: Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Mon, May 20, 2013 8:10:13 AM
Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin
--1009959307-1404435011-1369081433=:10108-- From matake@gmail.com Mon May 20 15:21:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050E421F9644 for ; Mon, 20 May 2013 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXCq5IHbL1JO for ; Mon, 20 May 2013 15:21:12 -0700 (PDT) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59B21F9610 for ; Mon, 20 May 2013 15:21:12 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id z8so4175101daj.31 for ; Mon, 20 May 2013 15:21:11 -0700 (PDT) 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=mioBK5ebzfpZWeo5x3CCSgApM+M4Q1wagDm9xsklpvc=; b=soi3J8/h3zxAFTDVM4oZaW+d+wViWHcyNXv3iWeeBp1JwWsbyXw/JhLj27AmLeW1dk GKWrZoc1IRv1w0IhEORtHzOb9eH6kcjgR+nzbIzqdXCS++U+PDb+ZHN7c/rYPonm/kv1 5YjHMUTb+W8LGZvWMbSwc1RYLdu3D6b6PKcwNILQt7CHbvs5VGnGU4tcXOTB4+vbq7PR s2+dKsnBKWvL8z1YDsZPtoVfUUztNjYFnKgzOmSf26rlCvomOgXNa9Ho0sCg5Q0R+0W4 iPSBYn4tAXp54G0C2dLyAOyBETp9I7Asf5WDGGcK8XrCb26/l7nDwHZRCgBwX9tznn4x 5yhw== X-Received: by 10.68.177.33 with SMTP id cn1mr62852467pbc.189.1369088471611; Mon, 20 May 2013 15:21:11 -0700 (PDT) Received: from [192.168.1.35] (z197007.dynamic.ppp.asahi-net.or.jp. [110.4.197.7]) by mx.google.com with ESMTPSA id 3sm19435755pbj.46.2013.05.20.15.21.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 15:21:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0550441D-A9DF-466B-B48A-134B55486184" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: <1369081433.10108.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Tue, 21 May 2013 07:21:07 +0900 Message-Id: <1AA85E6D-525D-4DCE-9A7D-B5573AF33E3E@gmail.com> References: <519A3C9A.8060305@mitre.org> <1369081433.10108.YahooMailRC@web184401.mail.bf1.yahoo.com> To: Edmund Jay X-Mailer: Apple Mail (2.1503) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 22:21:13 -0000 --Apple-Mail=_0550441D-A9DF-466B-B48A-134B55486184 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On 2013/05/21, at 5:23, Edmund Jay wrote: > +1 for keeping names as is. >=20 > From: Justin Richer > To: "oauth@ietf.org" > Sent: Mon, May 20, 2013 8:10:13 AM > Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration >=20 > Phil Hunt's review of the Dynamic Registration specification has = raised a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 >=20 >=20 > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >=20 >=20 > I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these: >=20 > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify >=20 > In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. >=20 > Naming things is hard. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0550441D-A9DF-466B-B48A-134B55486184 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

On = 2013/05/21, at 5:23, Edmund Jay <ejay@mgi1.com> wrote:

+1 for keeping = names as is.

From: Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Mon, May 20, 2013 8:10:13 = AM
Subject: [OAUTH-WG] Proposed Syntax = Changes in Dynamic Registration

Phil Hunt's review of the = Dynamic Registration specification has raised a couple of issues that I = felt were getting buried by the larger discussion (which I still = strongly encourage others to jump in to). Namely, Phil has suggested a = couple of syntax changes to the names of several parameters. 


1) expires_at = -> client_secret_expires_at
2) issued_at -> = client_id_issued_at
3) token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a = feeling, especially = from developers who = have deployed this draft spec, what we ought to do for each of = these:

 A) Keep the parameter names as-is
 B) Adopt = the new names as above
 C) Adopt a new name that I will = specify

In all cases, clarifying text will be added to the = parameter *definitions* so that it's more clear to people reading the = spec what each piece does. Speaking as the editor: "A" is the default as = far as I'm concerned, since we shouldn't change syntax without very good = reason to do so. That said, if it's going to be better for developers = with the new parameter names, I am open to fixing them = now.

Naming things is hard.

 -- = Justin
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_0550441D-A9DF-466B-B48A-134B55486184-- From ve7jtb@ve7jtb.com Mon May 20 16:10:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992621F9625 for ; Mon, 20 May 2013 16:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOYw+z-PL8EM for ; Mon, 20 May 2013 16:10:57 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25A21F961C for ; Mon, 20 May 2013 16:10:54 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id y26so7364119iab.17 for ; Mon, 20 May 2013 16:10:53 -0700 (PDT) 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=VxSasqUS9cmAI8GXgmeQXGhAfwSeURIPGjLhwfm2OIs=; b=O3YVGXevSDShZSN0X6IsBO8S8z3eYA62KD0Auw4jddbru+UwKY6S4OidoG0dQW2nmd gGpUAOG/f9EpPQyc6x3T1OBBvD8cwfk0QUNVEUyvaUEpWDaUbIQp59QBVUm+6qo5cl/d SweTKVoFK/qjLe/eDhwMdmOQCra2swAiTfDrbiHcnhoHJC7G/4o7V2CZTevXLhyF0x/C P1rDH86jbWKm/6UVZjsKDyzk4wNd26n10aBXSLnWKThK5yqRLxEBlbU9V6lBQlQd63O2 X9qN9ng+WYwfXhffxTyGSZsemJD+72Sfvw0kxxZUNb1wRCeUNmd+lwk+sn//5DjHYYMy WsyQ== X-Received: by 10.50.130.65 with SMTP id oc1mr6395858igb.32.1369091453556; Mon, 20 May 2013 16:10:53 -0700 (PDT) Received: from [192.168.1.42] (190-20-31-25.baf.movistar.cl. [190.20.31.25]) by mx.google.com with ESMTPSA id 9sm13848263igy.7.2013.05.20.16.10.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 16:10:51 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CCA5EB79-C8FC-486A-8518-05F1267330C8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <519A3AF6.7030302@mitre.org> Date: Mon, 20 May 2013 19:10:23 -0400 Message-Id: <06C7D6A2-501C-4DA5-908F-9A8AA7B00FEC@ve7jtb.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <80E6C4AC-5402-43E3-A6A2-0A98595F7203@oracle.com> <4E1F6AAD24975D4BA5B168042967394367734D79@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A3AF6.7030302@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkoFpOo5yLpEjaBSj/GrtvuDGImmtKQc07lhrSydaLVjUFPrufMFAZ6wXUlJSE/xwT7+Uw6 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 May 2013 23:10:59 -0000 --Apple-Mail=_CCA5EB79-C8FC-486A-8518-05F1267330C8 Content-Type: multipart/alternative; boundary="Apple-Mail=_7E00F785-C402-474D-B69C-609D6FC417A0" --Apple-Mail=_7E00F785-C402-474D-B69C-609D6FC417A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am prepending my comments with [JTB] On 2013-05-20, at 11:02 AM, Justin Richer wrote: > Since the various mail clients that people use have been wreaking = havoc with the threaded nesting of this discussion, I'm prepending my = newest comments with [JR] below. >=20 > -- Justin >=20 > On 05/17/2013 08:01 PM, Mike Jones wrote: >> My replies are in green and marked [mbj]. >> =20 >> -- Mike >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Friday, May 17, 2013 2:24 PM >> To: Mike Jones >> Cc: Richer, Justin P.; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 >> =20 >> I have started a separate thread on having dyn reg correlate client = software. >> =20 >> My other comments are embedded marked with [PH]. =20 >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >> =20 >> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>=20 >>=20 >> Thanks for the detailed feedback, Phil. Sorry for the delayed = response =E2=80=93 I was pretty fully engaged at the European Identity = Conference (where OAuth 2.0 won the award for best new standard J). My = feedback on the points raised is inline in green=E2=80=A6 >> =20 >> (Perhaps if any of you reply to this thread, you could also choose a = distinct color for your inline replies, so that it will be easily = evident who said what. As it is, just the back-and-forth between Phil = and Justin is already very difficult to follow. Thanks.) >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt >> Sent: Thursday, May 16, 2013 12:54 PM >> To: Richer, Justin P. >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 >> =20 >> Justin, >> =20 >> Thanks for the discussion. More comments below... >> =20 >> BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >> =20 >> On May 15, 2013, at 10:30 PM, Phil Hunt >> wrote: >> =20 >> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >> =20 >> Phil, many thanks for the extremely thorough review! It is very = useful indeed.=20 >> =20 >> My comments and responses to each point are inline.=20 >> =20 >> On May 15, 2013, at 4:30 PM, Phil Hunt wrote: >> =20 >> It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. >> =20 >> Overall =20 >> ----------- >> I think dynamic registration is a critical part of the OAuth = framework now that we are starting to consider how individual client = applications should operate when there is one or more deployments of a = particular resource API. We've moved from the simple use case of a = single API provider like Facebook or Flickr and moved on to standards = based, open source based, and commercial based deployments where there = are multiple service endpoints and many clients to manage. >> =20 >> The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: >> =20 >> 1. How is a new client application recognized for the first time = when deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? >> =20 >> In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 >> =20 >> I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. >> =20 >> But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? >> =20 >> I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) >> =20 >> I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. >> =20 >> In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. >> =20 >> What the UUID does is link multiple instances of a client app = together as the same "thing" that should have similar = heuristics/behaviours. This is very useful if = you want to be able to revoke access to a set of clients identified by = application id (or a version of that app). >> =20 >> While I=E2=80=99m sympathetic to the OAuth working group eventually = doing work on differentiating between instances of an OAuth client, = I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as = a client instance. There are only clients, which are identified by = client_id values. If we want to do work on client instances, we should = recharter to add this new work as a working group deliverable. We = should not try to shoehorn bits and pieces of it into the Dynamic = Registration spec, any more than we should have tried to shoehorn it = into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients = as defined in RFC 6749. It=E2=80=99s not the right place to extend what = an OAuth client is in new ways. >> =20 >> [PH] See new thread I have begun. >>=20 >> =20 >> 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? >> =20 >> The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 >> Something like this should be in the draft. >> =20 >> Should this be up in the introductory text, somewhere else, or have = its own section? >> =20 >> I'm starting to think credential management is a key part of the = draft. It may be worth introducing a specific section outling the = registration life-cycle, registration access token usage, and client = token usage and bootstrapping. >> =20 >> I think that adding a discussion on this would be fine, as it could = help developers understand the workflow of registering, using, and = updating registered clients. >> =20 >> How does a client authenticate the first time and subsequent times to = the registration service? >> =20 >> This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: >> - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) >> - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. >> =20 >> Subsequent times that the same registered client (by which we mean = the same instance of a client with a particular client_id) shows up at = the registration endpoint (actually, the Client Configuration Endpoint), = it uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. >> =20 >> Something like this should be in the draft. >> =20 >> OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer. >> =20 >> See the discussion on what the registration_access_token is in the = thread =E2=80=9CClient Credential Expiry and new Registration Access = Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin = to apply these clarifications to the specification. This may go into = the proposed credential management overview section discussed above. >> =20 >> 3. How is versioning of clients managed? Should each new version of = a client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. >> =20 >> This is up to the AS, really, and I don't think that any global = policy would ever fly here. Especially if you consider that the entire = notion of "version" is more fluid these days than it ever has been. I = wouldn't mind adding a discussion in the security considerations if it = merits mentioning though, so that we can help both client developers and = server developers institute reasonably good policy. >> =20 >> I guess the issue is that when a client upgrades it may have access = to the old credentials. What is the intent then of registration. Since = you have an update are clients expected to update /re-register or not? = I'm not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. >> =20 >> If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= >> I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. >> =20 >> I think this may be just a case of letting people exchange = credentials for whatever reason they feel is appropriate. The version = upgrade thing suggests that when a client is upgraded it should go to = the registration server to "re-register". Depending on the policy of = the server, it may (or may not) receive a new client_id and/or new = credential. =20 >> =20 >> One of the best benefits I can think of is if you discover a version = of a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ >> =20 >> Again, RFC 6749 defines no client instances or groups of clients, = therefore I believe that it=E2=80=99s inappropriate to do so here. We = don=E2=80=99t need to boil the ocean. If a new charter item is approved = to do work on client instances and protocol elements to use and express = them, that=E2=80=99s the time for the working group to consider that = possibility =E2=80=93 not as part of Dynamic Client Registration. >> =20 >> [PH] We disagree strongly here. I think it is well within charter = and in fact if such a new charter item were developed we would be = quickly moving to replace dyn reg version 2. >>=20 >> [mbj] Per my comments on the new thread you started, we wouldn=E2=80=99= t be replacing the existing dynamic registration spec =E2=80=93 we=E2=80=99= d be creating a new OAuth Client Instance Management spec, once piece of = which would be defining the 5% extensions needed to use it for that use = case. (And also per my comments on that thread, I=E2=80=99m sure that = the registration bits wouldn=E2=80=99t be all that would be in that spec = =E2=80=93 they=E2=80=99d probably only be a small part of it.) >=20 > [JR] And if this new work were to start up, I think that the BB+ = protocol for managing client classes and instances would be a good place = to start, or at least learn from what we're doing in there. As Mike = points out, the registration is actually a very small part of what's = needed, and BB+ doesn't actually define any new registration parameters. = There is a whole other layer of service discovery and vetting of client = parameters that happens in BB+, though, that don't make sense to cram = into OAuth Dyn Reg. As I've stated in a previous message, a simple = client-generated UUID *cannot* be sufficient for tying multiple clients = together, the race conditions between multiple auth servers alone make = it completely unusable. Which is to say, it's a more complex problem = than it seems on its surface, and it deserves to get a good amount of = attention and be actually engineered and solved appropriately. >=20 [JTB] I agree with Justin that full instance management takes more than = registration. The current Dynamic Registration draft allows higher = level instance management to be built on top of it like BB+, but only = registers clients as defined in OAuth 2. What higher level developer = interfaces do is out of scope, as long as they produce a bearer token = for bootstrapping registration. Any logic you like can be linked to = the bearer token. >> =20 >> 4. What is the registration access token? Why is is used? What is = its life-cycle? When is it issued, when is it changed? When is it = deleted? >> =20 >> See the response above above and the definition in =C2=A71.2:=20 >> =20 >> Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. >> =20 >> If this can be clarified, I welcome text suggestions. >> =20 >> The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. >> =20 >> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >> a Client can request new registration. The means of the Client >> obtaining the URL for this endpoint are out of scope for this >> specification. >> =20 >> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >> which a specific Client can manage its registration = information, >> provided by the Authorization Server to the Client. This URL = for >> this endpoint is communicated to the client by the = Authorization >> Server in the Client Information Response. >> =20 >> o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the >> Authorization Server through the Client Registration Endpoint >> which is used by the Client to authenticate itself during read, >> update, and delete operations. This token is associated with a >> particular Client. >> =20 >> This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? >> =20 >> Probably this is more a matter of style. But, what happened for me = is I naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? >> =20 >> If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. >> =20 >> When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" = be negotiated or be different for the = same client software? Should not all instances use the same = authentication method. >> =20 >> I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? >> =20 >> We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. >> =20 >> I haven't heard a reason justifying this parameter other then "it is = needed". Why? >> =20 >> The role of the dynamic registration protocol is twofold: half of = that is the server informing the client what it must do. But the other = half is the client informing the server what it *can* do, or what it = *wants* to do.=20 >> =20 >> And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 >> =20 >> I think we've discussed how recognizing subsequent instances is = easily done. >> =20 >> As I mentioned in the other thread, if a developer chooses to limit = the capabilities of the client it must do so by looking to the developer = or standard behind the API. Otherwise they are = taking the chance. There's no way a developer can query all the = potential deployers to ask what authn types will you use. As I said, the = net effect in the absence of an API standard dictating what should be = supported, the developer will have to implement all methods. >> =20 >> My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? >> =20 >> And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same = token_endpoint_auth_method from all auth servers they talk to, right? = And each AS will tell each instance that registers with it to use a = particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a = significant amount of other machinery. >> =20 >> Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. >> =20 >> See my previous comments on differentiating client instances being = out of scope without rechartering to do this new work and on what the = registration_access_token is. In short, the registration_access_token = is an RFC 6750 bearer token issued to the party registering the client, = enabling it to subsequently retrieve information about the client = registration and to potentially update the registration information for = that registered client. Again, I=E2=80=99ll work with Justin to make = sure that this is as clear as possible in the specification. >> =20 >> Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? >> =20 >> That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. >> =20 >> Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 >> =20 >> One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. >> =20 >> There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 >> =20 >> If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. >> =20 >> ETags seem like an unnecessary addition (and potential complication) = to the specification. It=E2=80=99s already working fine as-is. >> =20 >> Specific items: >> --------------------- >> "token_endpoint_auth_method" >> =20 >> There is some confusion as to whether this applies to server or = client authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" >> =20 >> This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. >> =20 >> The question was raised to me by some new developers. It seems = obvious to us as experienced OAuth persons, but to new developers it = seems unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) >> =20 >> Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to. >> =20 >> I agree with Justin here. I=E2=80=99m fine clarifying the = description of this parameter to resolve the potential ambiguities that = you cite, Phil. I=E2=80=99m not OK revising the syntax without a = compelling reason to do so. >> =20 >> [PH] I don't think we're changing any syntax here. Just clarifying = the name. This seems important now that there are 3 types of tokens = being managed (registration, client, access). =20 >> =20 >> I would much prefer just dumping the registration access token rather = then renaming parameters that would otherwise be unclear. >>=20 >> [mbj] Changing a name is changing the syntax.=20 >=20 > [JR] Agreed w/Mike, and this applies to all of the suggested name = changes: token_endpoint_client_auth_method, client_id_issued_at, = client_secret_expires_at. It's not that I disagree with the new = names (the latter two are actually markedly better), it's that I don't = want to change syntax without a chorus of developers here on the list = saying that the new syntax would be better for *them*. Editorial = changes, like expanding the explanatory text for these parameters, are = another matter and can be made without breaking running code. >=20 > That said, I *really* want to hear from people who are building and = deploying this right now to see if the suggested syntax changes would be = good, bad, or neutral to them. I think I should perhaps start another = thread on just that topic, since this important point might be getting = lost in this wall of text. >=20 >> As for dumping the registration access token, given that the = registration access token is used by the code author to access one = resource and the client_id is used by the code to access a different = resource, and that the security characteristics of the two kinds of = access are very different, I believe it would be a security and = usability disaster to try to blend them together. >=20 > [JR] This is a completely separate issue, and as Mike points out, the = client_id, client_secret, and registration_access_token serve completely = different purposes. If those purposes are unclear, we can explain them. = Deleting any of these or merging them is a terrible idea. [JTB] Agree with Justin and Mike. >=20 >> =20 >> * Currently, the API only supports a single value instead of an = array. If the purpose is to allow the client to know what auth methods = it supports, this should be an array indicated what methods the client = supports - or it should not be used. >> =20 >> I would rather like this to be an array, personally, and brought it = up with the OpenID Connect working group about six months ago. But there = it was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. >> =20 >> I can get behind multiple values. In this case, it changes the = meaning of the parameter. Instead of the client forcing the server to = use a particular method, the client is informing the server about what = methods it can perform. This allows the server to assign the appropriate = method based on its own policy. >>=20 >>=20 >> Also note that this field, like all others in =C2=A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. >> =20 >> This is the heart of my objection. This fuzziness is is going to lead = to interop issues. >> =20 >> There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 >> =20 >> The inter-op issue I would like to point out is that the spec does = not currently specify if particular input values are singular or = multiple. If an implementer assumes singular and clients assume = multiple, we have issues. >> =20 >> The multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written. The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification. I strongly believe that we need to add a = clear statement to this effect in the introduction to the specification. >> =20 >> The purpose of the Dynamic Client Registration specification is for = the client to register with the Authorization Server and to inform it of = properties of the client that the AS may = want/need to be aware of. It *is not* the purpose of this specification = for it to be used by clients in any manner to discover features of the = Authorization Server. That should be explicitly out of scope. >> =20 >> [PH] Agreed. >>=20 >> =20 >> Currently, clients are instructed by RFC 6749 to discover information = about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and = 3.2). They can also learn information about Authorization Servers in = specific contexts through discovery protocols such as OpenID Connect = Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) = and UMA Discovery (TBD). >> =20 >> I suspect that at some point, someone in the OAuth working group will = propose developing a generic OAuth discovery mechanism, which will lead = to a rechartering to include this work in the working group=E2=80=99s = set of deliverables. I would support doing this work and the necessary = rechartering to do so. >> [PH] So, given the above, the client shouldn't be dictating token = type. The AS should simply assign the credential and inform the client = what it must use. > [JR] How can a public client tell the AS that it doesn't want a = client_secret, and can't reasonably protect it? How can a client that = wants to do some kind of holder-of-key [JTB] I get the feeling that [PH] is not considering the use case of a = public AS like a IdP that has many clients with different security = profiles. Yes in an enterprise situation you probably would have the = developer say in the web interface my client needs LoA 3 and the = client_id registered on my registration_access_token MUST only use = client_secret_jwt. (the profile precludes sending the secret unencrypted = to the token endpoint even over TLS, not a unlikely requirement.)=20 However we DON'T want to require the use of a developer portal to = specify these things. A web server client (RP) needs to be able to = register at any AS (IdP) that allows open registration and specify it's = requirements, as long as those are within the capabilities of the server = then all should be good. The enterprise use case is different from a open environment. Not = wanting to allow symmetric keys or the passing of the symmetric key = unencrypted over the channel (http basic) are things that a client may = reasonably want to disallow if it intends to use a more secure method = that the server supports. The other reason is to not generate the = client secret for public clients. >=20 >> =20 >> [mbj] You seem to be (intentionally?) ignoring John Bradley=E2=80=99s = point that it=E2=80=99s the client that knows which of the security = profiles supported by the AS that it needs to use =E2=80=93 not the AS. = Therefore, for security reasons, it must be the client that picks the = method from among those supported by the AS =E2=80=93 not the other way = around. The AS has no way to know which methods are appropriate for = which clients, but the clients do. >> =20 >> We agree, no discovery. But I also want to eliminate negotiation = that doesn't actually help anything. >>=20 >> [mbj] I=E2=80=99m not describing negotiation above. I=E2=80=99m = describing the party with the knowledge to make the appropriate choice = being able to make that choice. >> =20 >> That being said, I strongly oppose trying to shoehorn piecemeal = aspects of discovery into the Dynamic Client Registration specification. = It is distinct functionality and deserves first-class and separable = treatment by the working group. Discovery is for potential clients to = learn properties of the AS before registration. Registration is for = potential clients to inform the AS of its properties, creating a = registered client. Discovery sends information about the AS to the = Client. Registration sends information about the Client to the AS. = That=E2=80=99s a clean separation. We should strongly resist muddying = the two functions. >> =20 >> OAuth 2.0 is a success because it didn=E2=80=99t try to boil the = ocean. It specified how to do one thing well in a simple, web-friendly = manner. We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this work. >> =20 >> I apologize at this point on behalf of myself and the other spec = editors for not being 100% clear that discovery functionality is = explicitly out of scope for Dynamic Client Registration. If we had done = so, I=E2=80=99m sure that many of the current questions and confusions = would not have arisen. I think we=E2=80=99d assumed that this was = obvious, but from the current discussions, it=E2=80=99s apparent that = it=E2=80=99s not obvious. I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion. >> =20 >> Getting back to the specifics, the only useful purpose of a = multi-valued =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member = would be to enable the client to discover information about the = authentication methods supported by the AS after the registration had = been performed. But that is a discovery function, and so should be part = of the discovery work =E2=80=93 not this specification. We should = resist shoehorning in bits of discovery into this specification. It = *is* a worthwhile topic, but deserves full consideration by the working = group in its own right. Therefore, this member must remain = single-valued, and be clearly specified as the method by which a client = informs the AS which token endpoint authentication method it will use. = Anything else would be scope creep, and result in an unnecessarily = complicated specification and unnecessarily complicated clients. >> =20 >> [PH] Agreed. Let's remove the parameter.in the request. It should = only be in the response. >>=20 >> [mbj] Removing the parameter would make it impossible for the = client, which knows which security profile it needs to use, to declare = to the AS which method, from among the methods supported by the AS, that = it needs to use. The client MUST be the one doing the choosing. > [JR] Again, see above note about public clients. The server knows = nothing about the client before it shows up, including what the client = believes it can protect. Registration on this parameter is the client = saying "I can do this", and the server's response is "you may do this". = Both are distinct and necessary. >=20 [JTB] I think [PH] is again assuming the existence of a developer portal = of sorts that would have configured this. However the Dynamic = Registration spec needs to work without that. >> =20 >> * There is no authn method for "client_secret_saml" or = "private_key_saml". >> =20 >> Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? >> =20 >> I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. >> =20 >> There are no profiles referenced or defined for "client_secret_jwt" = or "private_key_jwt". Neither of the JWT or SAML Bearer drafts = referenced cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. >> =20 >> The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. >> =20 >> Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) >> =20 >> Regardless, you are introducing a new profile which is undefined. >> =20 >> I think I see the point that you're making now, let me try to = re-state it: >> =20 >> While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). >> =20 >> I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. >> =20 >> I guess then the mistake the JWT Bearer and SAML Bearer drafts = authors made is they assumed everyone had the same definition of bearer = token. To me a bearer token opaque to the client. It therefore cannot = do any signature work with regards to the token itself. Now, that's not = to say a proof didn't occur between the client and the token issuer, but = when the client wields the token, it is handling an opaque string. >> =20 >> The concept of client_secret_jwt suggests an HoK profile. Therefore = of course the bearer drafts are a little underspecified when it comes to = HoK profiles. [JTB] Not a HoK profile at all. It is a JWT bearer assertion to the = token endpoint to authenticate the client using the client secret for = calculating the HMAC. The bearer profile dosent specify = signing/integrity algorithm or where to get the key from. Connect = specifies those things. I agree that taking them out of the generic = client registration and specifying them in a separate profile is a good = idea. Those identifiers are defined in Connect. >> =20 >> So for example, you need a draft like the MAC draft for this.=20 >> =20 >> I'm having trouble overall here. It seems the authn types suggest = ONLY strong authentication for clients, yet during the registration = process the current draft isn't able to correlate multiple instances of = the same software (even in a self-asserted way). If you haven't = authenticated the software at all, why have strong client auth? >> =20 >> There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. >> =20 >> I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. >> =20 >> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. >> =20 >> What you are describing is not bearer. It is holder of key. Very very = different.=20 >>=20 >>=20 >> A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. >> =20 >> That's possible, but they are in active use already.=20 >> =20 >> That may be true. But then you need to write another draft so the = rest of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. >> =20 >> This much I agree with. >> =20 >> Justin, John, and I discussed this issue and agree with your = suggestion, Phil. Since they are not completely specified, we will = remove the client_secret_jwt and private_key_jwt methods from the = specification and add a registry, enabling specification that do fully = specify these and other token endpoint authentication methods, including = potential methods using SAML assertions, to register them in the = registry, rather than trying to bake them into the Dynamic Client = Registration specification. >> =20 >> About "tos_uri" and "policy_uri" >> =20 >> The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? >> =20 >> Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. >> =20 >> Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. >> =20 >> OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) >> =20 >> I support clarifying the language on these definitions, and will work = with Justin to do so. >> =20 >> Also, aren't these really URIs or are they meant to be URLs? >> =20 >> There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. >> =20 >> Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. >> =20 >> That's fair, and it's something that the AS can even check if it = wants to. >> =20 >> Agreed on this clarification. >> =20 >> About "jwks_uri" >> =20 >> A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 >> =20 >> Yes, you're correct, I'll add that. >> =20 >> Should be URL instead of URI? >> =20 >> See above. :) >> =20 >> Agreed on adding this reference. >> =20 >> Section 2.1 >> =20 >> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >> is missing. >> =20 >> It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? >> ' >> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >> =20 >> Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. >> =20 >> =E2=80=9CAs such, a server supporting these fields SHOULD take steps = to ensure that a client cannot register itself into an inconsistent = state.=E2=80=9D >>=20 >> We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? >> =20 >> I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. >> =20 >> I *think* that this goes away with the deletion of client_secret_jwt = and private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a = consistency check and verify that when the spec is updated accordingly. >> [PH] Agreed. >>=20 >> =20 >> Section 2.2 >> =20 >> May want to add: >> =20 >> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2= =80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. >> =20 >> That seems inconsistent with what we already have: >> =20 >> If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user = interface. >> =20 >> Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. >> =20 >> I will discuss with our developers. I'm not sure the as-is works. =20 >> =20 >> Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? >> =20 >> Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? >> =20 >> =20 >> No, the client should pass parameters as multiple separate values. = Connect has this in its example: >> =20 >> "client_name": "My Example", >> "client_name#ja-Jpan-JP": >> "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D",= >> Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) >> =20 >> An example would definitely help. >> If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. >> =20 >> Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 >> =20 >> I think what I meant is since you are allowing each client to = register different things, AND the client likely already knows the = user's preferred language, why wouldn't the client just pass text values = in one language and another parameter indicating preferred language in = the case of any service generated text. >> =20 >> Is the reason you are passing multiple localizations is so that you = can use the preferred language of the resource owner rather then the = client user? I wonder if that is correct. If the language preferences = are in fact different, what would the user of the client app expect? >> =20 >> ----> any multi-lingual people have any opinions here? >> =20 >> Without specific proposed text changes to review, it=E2=80=99s hard = to know what to think about this comment. Unless a specific proposed = text change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and reviewed by the working group, = I don=E2=80=99t believe we should change the specification in response = to this comment. >> =20 >> [PH] I agree. I plan to follow up and see if I can't get more = clarification on requirements from my side.=20 >>=20 >> =20 >> Section 3 >> =20 >> Existing text: >>=20 >> =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >>=20 >> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 >> =20 >> I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 >> =20 >> I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? >> =20 >> No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 >> =20 >> I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >>=20 >> On the flip side, the earlier paragraph: >>=20 >> =E2=80=9CThe 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.=E2=80=9D >>=20 >> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D= to =E2=80=9CSHOULD=E2=80=9D. >>=20 >> That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. >> =20 >> Again, disagree, for the same reasoning as above. >> =20 >> Same reasoning.=20 >>=20 >>=20 >> I agree with Justin here. The default should be that open = registrations are enabled. The exception case is that specific = permissions are required to perform dynamic client registration. >> =20 >> [PH] I'm not sure I understand your last sentence. It seems to = contradict your position. If you need specific permissions, then surely = you can't be anonymous??? >>=20 >> [mbj] More clearly put, it should be an exception for the party = wanting to register a client to have to obtain special permissions up = front to register the client. In the normal case, the party wanting to = register a client should require no special up-front permissions. >=20 > [JR] To reiterate, the text is correct as it stands. Unauthenticated = registration should be the norm. Authenticated registration is the = exception. This is intentional. [JTB] Yes unauthenticated clients with self asserted info should be the = norm. How a developer/client gets Authenticated (there are several = possibilities for this) prior to registration is out of scope. >=20 >>=20 >> About section 4.3: >> =20 >> If the client does not exist on this server, the server MUST respond >> with HTTP 401 Unauthorized, and the Registration Access Token used = to >> make this request SHOULD be immediately revoked. >> =20 >> If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >>=20 >> If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. >> =20 >> The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. >> =20 >> Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 >> =20 >> Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. >> =20 >> I think we should look at it. >>=20 >>=20 >> For security reasons, it=E2=80=99s generally not good to distinguish = between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D = errors in responses, as that can provide the attacker an oracle to probe = whether a particular entity exists I don=E2=80=99t think a change is = called for here. >> =20 >> [PH] I agree in principle. This issue is bound up too in what the = life-cycle of the registration and the access token and client tokens. = We need to describe those first before this becomes clear. For example, = if the client is still authenticated, but its registration is gone, it = should be not found. But I agree this doesn't make sense, because the = "implied" action was that the deletion of a registration invalidates all = associated credentials. ---> meaning the client should never be able to = authenticate with the registration endpoint anyway. >>=20 >> [mbj] By the way, you writing that =E2=80=9Cthe client should never = be able to authenticate with the registration endpoint anyway=E2=80=9D = makes the case for why the permissions on the client=E2=80=99s = registration endpoint are different than those granted to the client =E2=80= =93 hence the need for the registration_access_token. >>=20 >> About section 5.1: >> Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. >> =20 >> The registration_access_token is unique to a registered client, in = the RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly. >> =20 >> [PH] Disagree. I think it is well within charter and in fact a = foundational requirement. >> =20 >> [mbj] I interpret your comment above as part of your desire for the = working group to define OAuth Client Instance Management functionality. = Again, that=E2=80=99s bigger than just registration. > [JR] Agree with Mike -- this is way bigger than just a registration = parameter. [JTB] Agree with [mjb] & [jr] >=20 >>=20 >> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >>=20 >> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D >> =20 >> While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >>=20 >>=20 >>=20 >> I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. >> =20 >> That's why we are having last call. To confirm consensus on the = draft.=20 >> =20 >> Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. >> =20 >> I'm fine with the suggested change but I would like more feedback = from other people before moving forward with it. There's a lot of value = in "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) >> =20 >> Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 >> =20 >> I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >>=20 >>=20 >> If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_a= t=E2=80=9D are unclear, we should clarify them. If you believe that = this is the case Phil, can you supply proposed alternative definition = text that is clearer? That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them. They are = already working fine as-is in production deployments. >> =20 >> [PH] I'm just reporting the confusion people have had with ambiguity. >=20 > [JR] As above, I am very hesitant to change syntax without a lot of = direct feedback from developers as to how it would affect them. Wearing = my own developer hat, I'm willing to make the change. But I can't speak = for the rest of the community, so I'm going to start a new thread. >=20 [JTB] The definition is clear, and the names are not unreasonable. I = don't think they need changing. =20 >> =20 >> =20 >> =20 >> Section 7 >> =20 >> When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? >> =20 >> Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. >> =20 >> Either is a reasonable behavior on the behalf of clients, depending = upon context. I support adding text to clarify this. >> =20 >> Again, thanks for the very thorough read through. Have you = implemented any of the spec yet, either as-is or with any of your = suggested changes? >> =20 >> Yes. Much of the feedback is coming from our development community.=20= >> =20 >> Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) >> =20 >> Glad to hear that you=E2=80=99re working with developers building the = spec. Please thank them for the feedback. >> =20 >> -- Justin >> =20 >> Best = wishes, >> -- Mike >> =20 >> [PH] Thankss. >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7E00F785-C402-474D-B69C-609D6FC417A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am = prepending my comments with [JTB]

On 2013-05-20, at = 11:02 AM, Justin Richer <jricher@mitre.org> = wrote:

=20 =20
Since the various mail clients that people use have been wreaking havoc with the threaded nesting of this discussion, I'm prepending my newest comments with [JR] below.

 -- Justin

On 05/17/2013 08:01 PM, Mike Jones wrote:

My replies are in green and marked [mbj].

 

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

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 17, 2013 2:24 PM
To: Mike Jones
Cc: Richer, Justin P.; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

 

I have started a separate thread on having dyn reg correlate client software.

 

My other comments are embedded = marked with [PH].  

 

 

On 2013-05-17, at 1:08 PM, Mike = Jones wrote:



Thanks for the detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 I was pretty fully = engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in = green=E2=80=A6

 

(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  = Thanks.)

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10

 

Justin,

 

Thanks for the discussion. More comments below...

 

BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a = away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I = can put together some intro text, etc.

 

Phil

 

@independentid

 

On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:

 

On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>

 wrote:

 

On 2013-05-15, at 5:53 PM, Richer, Justin P. = wrote:

 

Phil, many thanks for the extremely thorough review! It is very useful = indeed. 

 

My comments and responses to each point are inline. 

 

On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.

 

Overall =  

-----------

I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.

 

The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the = spec:

 

1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients = actually assert an application_id UUID that never changes and possibly a version id that does change with versions?

 

In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 

 

I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It = seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.

 

But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?

 

I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for = BB+)

 

I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application = IDs.

 

In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app = credential.

 

What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very = useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).

 

While I=E2=80=99m sympathetic to the OAuth working = group eventually doing work on differentiating between instances of an OAuth client, I=E2=80=99= ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  = There are only clients, which are identified by client_id values.  If we want to do = work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to = shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC = 6749.  It=E2=80=99s not the right place to extend = what an OAuth client is in new = ways.

 

[PH] See new thread I have = begun.

 

2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?

 

The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (=C2=A74.2)= to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 

Something like this should be in the = draft.

 

Should this be up in the introductory text, somewhere else, or have its own section?

 

I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and = bootstrapping.

 

I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered = clients.

 

How does a client authenticate the first time and subsequent times to the registration service?

 

This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:

  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)

 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.

 

Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.

 

Something like this should be in the draft.

 

OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer.

 

See the discussion on what the registration_access_token is in the thread =E2=80=9CClient Credential Expiry = and new Registration Access Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. = ; I will work with Justin to apply these clarifications to the = specification.  This may go into the proposed credential management overview section discussed above.

 

3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should = consider.

 

This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good = policy.

 

I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not = sure this is a security consideration but more part of the whole change management function dynamic registration supports.

 

If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 

I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it = solves.

 

I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that = when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, = it may (or may not) receive a new client_id and/or new credential.  

 

One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked = about this as an issue for Blue Button+

 

Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it=E2=80=99s inappropriate to do so = here.  We don=E2=80=99t need to boil the ocean.  If a new = charter item is approved to do work on client instances and protocol elements to use and express them, that=E2=80=99s the time for = the working group to consider that possibility = =E2=80=93 not as part of Dynamic Client = Registration.

 

[PH] We disagree strongly here. =  I think it is well within charter and in fact if such a new charter item were developed we would be quickly moving to replace dyn reg version 2.

[mbj] Per my comments on the new thread you started, we wouldn=E2=80=99t be replacing = the existing dynamic registration spec =E2=80=93 = we=E2=80=99d be creating a new OAuth Client Instance Management spec, once piece of which would be defining the 5% extensions needed to use it for that use case.  (And also per my comments on that thread, I=E2=80=99m sure = that the registration bits wouldn=E2=80=99t be all = that would be in that spec =E2=80=93 they=E2=80=99d = probably only be a small part of it.)


[JR] And if this new work were to start up, I think that the BB+ protocol for managing client classes and instances would be a good place to start, or at least learn from what we're doing in there. As Mike points out, the registration is actually a very small part of what's needed, and BB+ doesn't actually define any new registration parameters. There is a whole other layer of service discovery and vetting of client parameters that happens in BB+, though, that don't make sense to cram into OAuth Dyn Reg. As I've stated in a previous message, a simple client-generated UUID *cannot* be sufficient for tying multiple clients together, the race conditions between multiple auth servers alone make it completely unusable. Which is to say, it's a more complex problem than it seems on its surface, and it deserves to get a good amount of attention and be actually engineered and solved appropriately.

[JTB] I agree with Justin that full = instance management takes more than registration.  The current = Dynamic Registration draft allows higher level instance management to be = built on top of it like BB+, but only registers clients as defined in = OAuth 2.   What higher level developer interfaces do is out of = scope, as long as they produce a bearer token for bootstrapping = registration.   Any logic you like can be linked to the bearer = token.

 

4.  What is the = registration access token? Why is is used? What is its life-cycle?  When is = it issued, when is it changed? When is it deleted?

 

See the response above above and the definition in = =C2=A71.2: 

 

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular = Client.

 

If this can be clarified, I welcome text = suggestions.

 

The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access = tokens.

 

Client Registration Endpoint: The OAuth 2.0 =
Endpoint through which
      a Client can =
request new registration.  The means of the =
Client
      obtaining the =
URL for this endpoint are out of scope for this
      =
specification.
 
   o  Client Configuration =
Endpoint: The OAuth 2.0 Endpoint through
      which a =
specific Client can manage its registration =
information,
      provided by =
the Authorization Server to the Client.  This URL =
for
      this endpoint =
is communicated to the client by the =
Authorization
      Server in the =
Client Information Response.
 
   o  Registration Access =
Token: An OAuth 2.0 Bearer Token issued by the
      Authorization =
Server through the Client Registration Endpoint
      which is used =
by the Client to authenticate itself during =
read,
      update, and =
delete operations.  This token is associated with =
a
      particular =
Client.

 

This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?

 

Probably this is more a matter of style.  But, what happened for me = is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe = the chairs can advise?

 

If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per = instance.

 

When subsequent instances register, I have to ask the question, for example when would things like = "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.

 

I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?

 

We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic = reg endpoint is to inform the client what it must do.  My assumption = is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.

 

I haven't heard a reason justifying this parameter other then "it is needed". =  Why?

 

The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to = do. 

 

And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent = that kind of behavior if you also want open registration of = clients. 

 

I think we've discussed how recognizing subsequent instances is easily = done.

 

As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all = the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.

 

My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why = negotiate within registration?

 

And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other = machinery.

 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too = limiting.

 

See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token = is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I=E2=80=99ll work with = Justin to make sure that this is as clear as possible in the = specification.

 

Finally, there seems to be an inconsistent style approach with draft-hardjono-o= auth-resource-reg which uses ETags. Should this draft do so as well?

 

That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this = late.

 

Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 

 

One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the = design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.

 

There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in = =C2=A74.1. 

 

If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if = adopted.

 

ETags seem like an unnecessary addition (and potential complication) to the = specification.  It=E2=80=99s already working fine = as-is.

 

Specific = items:

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

"token_endpoint_auth_method"

 

There is some confusion as to whether this applies to server or client authentication.  Suggest renaming = parameter to = "token_endpoint_client_auth_method"

 

This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.

 

The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you = are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible. =  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)

 

Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants = to.

 

I agree with Justin here.  I=E2=80=99= m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  = I=E2=80=99m not OK revising the syntax without a compelling reason to do = so.

 

[PH] I don't think we're = changing any syntax here. Just clarifying the name. This seems important now that there are 3 types of tokens being managed (registration, client, access). =  

 

I would much prefer just dumping = the registration access token rather then renaming parameters that would otherwise be unclear.

[mbj] Changing a name is changing the syntax.  =


[JR] Agreed w/Mike, and this applies to all of the suggested name changes: token_endpoint_client_auth_method, client_id_issued_at, client_secret_expires_at. It's not that I disagree with the new names (the latter two are actually markedly better), it's that I don't want to change syntax without a chorus of developers here on the list saying that the new syntax would be better for *them*. Editorial changes, like expanding the explanatory text for these parameters, are another matter and can be made without breaking running code.

That said, I *really* want to hear from people who are building and deploying this right now to see if the suggested syntax changes would be good, bad, or neutral to them. I think I should perhaps start another thread on just that topic, since this important point might be getting lost in this wall of text.

As for dumping the registration access token, given that the registration access token is used by the code author to access one resource and the client_id is used by the code to access a different resource, and that the security characteristics of the two kinds of access are very different, I believe it would be a security and usability disaster to try to blend them = together.


[JR] This is a completely separate issue, and as Mike points out, the client_id, client_secret, and registration_access_token serve completely different purposes. If those purposes are unclear, we can explain them. Deleting any of these or merging them is a terrible idea.

[JTB] Agree with Justin = and Mike.


 

* Currently, the API only supports a single value instead of an array.  If = the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be = used.

 

I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.

 

I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.


Also note that this field, like all others in = =C2=A72, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.

 

This is the heart of my objection. This fuzziness is is going to lead to interop = issues.

 

There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 

 

The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer = assumes singular and clients assume multiple, we have issues.

 

The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it=E2=80=99s= currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that = we need to add a clear statement to this effect in the introduction to the = specification.

 

The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is = not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  = That should be explicitly out of = scope.

 

[PH] Agreed.

 

Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2).  They = can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1= _0.html) and UMA Discovery (TBD).

 

I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group=E2=80=99s set of = deliverables.  I would support doing this work and the necessary rechartering to do = so.

[PH] So, given the above, the = client shouldn't be dictating token type. The AS should simply assign the credential and inform the client what it must use.

[JR] How can a public client tell the AS that it doesn't want a client_secret, and can't reasonably protect it? How can a client that wants to do some kind of = holder-of-key

[JTB] I get the = feeling that [PH] is not considering the use case of a public AS like a = IdP that has many clients with different security profiles.   Yes = in an enterprise situation you probably would have the developer say in = the web interface my client needs LoA 3 and the client_id registered on = my registration_access_token MUST only = use client_secret_jwt. (the profile precludes sending the = secret unencrypted to the token endpoint even over TLS, not a unlikely = requirement.) 

However we DON'T want to = require the use of a developer portal to specify these things.  A = web server client (RP) needs to be able to register at any AS (IdP) that = allows open registration and specify it's requirements, as long as those = are within the capabilities of the server then all should be = good.

The enterprise use case is different from = a open environment.  Not wanting to allow symmetric keys  or = the passing of the symmetric key unencrypted over the channel (http = basic) are things that a client may reasonably want to disallow if it = intends to use a more secure method that the server supports.   The = other reason is to not generate the client secret for public = clients.


 

[mbj] You seem to be (intentionally?) ignoring John = Bradley=E2=80=99s point that it=E2=80=99s the client that knows which of = the security profiles supported by the AS that it needs to use =E2=80=93 not the AS.  Therefore, for security = reasons, it must be the client that picks the method from among those supported by the AS =E2=80=93 not the other way = around.  The AS has no way to know which methods are appropriate for which clients, but the clients = do.

 

We agree, no discovery.  But = I also want to eliminate negotiation that doesn't actually help anything.

[mbj] I=E2=80=99m not describing negotiation above.  = I=E2=80=99m describing the party with the knowledge to make the appropriate choice being able to make that = choice.

 

That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct = functionality and deserves first-class and separable treatment by the working group.  = Discovery is for potential clients to learn properties of the AS before registration.  Registration = is for potential clients to inform the AS of its properties, creating a registered = client.  Discovery sends information about the AS to the Client.  Registration sends = information about the Client to the AS.  That=E2=80=99s= a clean separation.  We should strongly resist muddying the two = functions.

 

OAuth 2.0 is a success because it didn=E2=80=99t try = to boil the ocean.  It specified how to do one = thing well in a simple, web-friendly manner.  = We should do the same =E2=80=93 focusing on = specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this = work.

 

I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I=E2=80=99= m sure that many of the current questions and confusions would not have arisen.  I = think we=E2=80=99d assumed that this was obvious, = but from the current discussions, it=E2=80=99s apparent = that it=E2=80=99s not obvious.  I will = personally commit to clarifying the specification at this point to eliminate this potential point of = confusion.

 

Getting back to the specifics, the only useful purpose of a multi-valued = =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But = that is a discovery function, and so should be part of the discovery work =E2=80=93 not this = specification.  We should resist shoehorning in bits of discovery into this specification.  It = *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must = remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, = and result in an unnecessarily complicated specification and unnecessarily complicated clients.

 

[PH] Agreed. Let's remove the parameter.in the request. It should only be in the response.

 [mbj] Removing the parameter would make it impossible for the client, which knows which security profile it needs to use, to declare to the AS which method, from among the methods supported by the AS, that it needs to = use.  The client MUST be the one doing the = choosing.

[JR] Again, see above note about public clients. The server knows nothing about the client before it shows up, including what the client believes it can protect. Registration on this parameter is the client saying "I can do this", and the server's response is "you may do this". Both are distinct and necessary.

[JTB] I think [PH] is again assuming the = existence of a developer portal of sorts that would have configured = this.  However the Dynamic Registration spec needs to work without = that.

 

* There is no authn method for "client_secret_saml" or = "private_key_saml".

 

Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?

 

I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are = defining an authentication that isn't even defined.

 

There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" = and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these = either.

 

The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, = asymmetrically.

 

Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is = that if a client has the assertion it has the right to present it. =  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)

 

Regardless, you are introducing a new profile which is undefined.

 

I think I see the point that you're making now, let me try to re-state it:

 

While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#r= fc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).

 

I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.

 

I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token = opaque to the client. It therefore cannot do any signature work with regards to the token itself. =  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.

 

The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are = a little underspecified when it comes to HoK profiles.


[JTB]  Not a HoK = profile at all.  It is a JWT bearer assertion to the token endpoint = to authenticate the client using the client secret for calculating the = HMAC.   The bearer profile dosent specify signing/integrity = algorithm or where to get the key from.  Connect specifies those = things.   I agree that taking them out of the generic client = registration and specifying them in a separate profile is a good idea. =   Those identifiers are defined in = Connect.

 

So for example, you need a draft like the MAC draft for = this. 

 

I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If = you haven't authenticated the software at all, why have strong client auth?

 

There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer = specs say this is acceptable,  the dynamic = registration spec should accept = these.

 

I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.

 

6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating = or modifying the assertion. The client is simply passing one it previously = obtained.

 

What you are describing is not bearer. It is holder of key. Very very different. 


A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.

 

That's possible, but they are in active use = already. 

 

That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I = prefer not to guess what you are = doing.

 

This much I agree with.

 

Justin, John, and I discussed this issue and agree with your suggestion, = Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration = specification.

 

About "tos_uri" and = "policy_uri"

 

The distinction between tos_uri and policy_uri is unclear.  Can we clarify or = combine them?

 

Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be = split.

 

Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the = feedback.

 

OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)

 

I support clarifying the language on these definitions, and will work with Justin to do so.

 

Also, aren't these really URIs or are they meant to be = URLs?

 

There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a = plus.

 

Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.

 

That's fair, and it's something that the AS can even check if it wants to.

 

Agreed on this = clarification.

 

About = "jwks_uri"

 

A normative reference = for http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is = needed. 

 

Yes, you're correct, I'll add = that.

 

Should be URL instead of = URI?

 

See above. :)

 

Agreed on adding this = reference.

 

Section 2.1

 

In the table urn:ietf:params:oauth:grant-type:jwt-bearer<= /o:p>

is missing.

 

It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80=A6 = ?

'

Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer=

 

Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.

 

=E2=80=9CAs such, a server supporting these fields SHOULD take = steps to ensure that a client cannot register itself into an inconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code = (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?

 

I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.

 

I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6&nbs= p; I=E2=80=99ll do a consistency check and verify that when the spec is updated = accordingly.

[PH] Agreed.

 

Section 2.2

 

May want to add:

 

When =E2=80=9C#=E2=80= =9D language tag is missing, (e.g. = =E2=80=9C#en=E2=80=9D is missing in = =E2=80=9Cclient_name=E2=80=9D, = instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret = the language used = based on server configuration or = heuristics.

 

That seems inconsistent with what we already = have:

 

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user = interface.

 

Which is to say, treat it as a raw byte-value-string and don't try to get = fancy.

 

I will discuss with our developers. I'm not sure the as-is works. =  

 

Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?

 

Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only = passes a single value for that registration?

 

 

No, the client should pass parameters as multiple separate values. Connect has this in its = example:

 

   =
"client_name": "My Example",
   =
"client_name#ja-Jpan-JP":
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=
=8D",

Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)

 

An example would definitely help.

If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with = it.

 

Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable = fields. 

 

I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.

 

Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language = preferences are in fact different, what would the user of the client app expect?

 

----> any multi-lingual people have any opinions here?

 

Without specific proposed text changes to review, it=E2=80=99s hard to know what = to think about this comment.  Unless a = specific proposed text change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and = reviewed by the working group, I don=E2=80=99t = believe we should change the specification in response to this = comment.

 

[PH] I agree. I plan to follow = up and see if I can't get more clarification on requirements from my side. 

 

Section = 3

 

Existing text:

=E2=80=9CIn = order to support open registration and facilitate = wider interoperability, the Client Registration = Endpoint SHOULD allow initial = registration requests with = no authentication.  These requests MAY = be rate-limited or otherwise limited to prevent a = denial-of-service attack on = the Client Registration Endpoint.=E2=80=9D=

I would suggest to change the first = =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D.   In most cloud services, the first client = is registered by a human user. Then, = other clients can be further used to = automate other client = registration.  So, the = first request would typically come with an authenticated user = identity. 

 

I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 

 

I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?

 

No, I think that anonymous authentication should be the rule. Open registration should be default. 

 

I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about = it.


On the flip side, the earlier paragraph:

=E2=80=9CThe 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.=E2=80=9D

I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D= to =E2=80=9CSHOULD=E2=80=9D.

That access token would carry a human user = authenticated identity somehow. In some cases, it can be a pure authenticated user = assertion token.

 

Again, disagree, for the same reasoning as above.

 

Same reasoning. 


I agree with Justin here.  The = default should be that open registrations are enabled.  The exception = case is that specific permissions are required to perform dynamic client registration.

 

[PH] I'm not sure I understand = your last sentence. It seems to contradict your position. If you need specific permissions, then surely you can't be anonymous???

[mbj] More clearly put, it should be an exception for the party wanting to register a client to have to obtain special permissions up front to register the = client.  In the normal case, the party wanting to register a client should require no special up-front = permissions.


[JR] To reiterate, the text is correct as it stands. Unauthenticated registration should be the norm. Authenticated registration is the exception. This is = intentional.

[JTB] Yes = unauthenticated clients with self asserted info should be the norm. =  How a developer/client gets Authenticated (there are several = possibilities for this) prior to registration is out of = scope.


About section = 4.3:

 

If the client does not exist on this server, =
the server MUST respond
   with HTTP 401 Unauthorized, and =
the Registration Access Token used to
   make this request SHOULD be =
immediately revoked.

 

If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration? =  This is not clear. =  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.

 

The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here = actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound = token.

 

Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the = client. 

 

Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.

 

I think we should look at it.


For security reasons, it=E2=80=99s = generally not good to distinguish between =E2=80=9Cn= ot found=E2=80=9D and = =E2=80=9Cunauthorized=E2=80=9D errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I = don=E2=80=99t think a change is called for = here.

 

[PH] I agree in principle. This = issue is bound up too in what the life-cycle of the registration and the access token and client tokens. We need to describe those first before this becomes clear.  For example, if the client is still authenticated, but its registration is gone, it should be not found.  But I = agree this doesn't make sense, because the "implied" action was that the deletion of a registration invalidates all associated credentials. ---> meaning the client should never be able to authenticate with the registration endpoint anyway.

[mbj] By the way, you writing that =E2=80=9Cthe client = should never be able to authenticate with the registration endpoint anyway=E2=80=9D makes the case for why the permissions on the client=E2=80= =99s registration endpoint are different than those granted to the client =E2=80=93 hence the need for the registration_access_token.


About section = 5.1:

Is = registration_access_token unique?  Or is = it shared by multiple instances?   If shared, then = registration_access_token can't be revoked on delete of = client.

 

The = registration_access_token is unique to a registered client, in the RFC 6749 sense of = =E2=80=9Cclient=E2=80=9D.  Again, if we want to do work on =E2=80=9Ccli= ent instances=E2=80=9D, = we need to recharter and take this distinct work item up = explicitly.

 

[PH] Disagree. I think it is = well within charter and in fact a foundational = requirement.

 

[mbj] I interpret your comment above as part of your desire for the working group to define OAuth Client Instance Management functionality.  Again, that=E2=80=99s = bigger than just registration.

[JR] Agree with Mike -- this is way bigger than just a registration parameter.

[JTB]  Agree = with [mjb] & [jr]


Suggest rename =E2=80=9Cexpires_at=E2= =80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at=E2= =80=9D to = =E2=80=9Cid_issued_at=E2=80=9D

 

While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,




I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing = so.

 

That's why we are having last call. To confirm consensus on the = draft. 

 

Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.

 

I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)

 

Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a = house.  :-) 

 

I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 


If the definitions of =E2=80=9Cexpires_at=E2=80=9D= or =E2=80=9Cissued_at=E2=80=9D are unclear, we = should clarify them.  If you believe that this is the = case Phil, can you supply proposed alternative definition text that is clearer?  That = being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They = are already working fine as-is in production deployments.

 

[PH] I'm just reporting the = confusion people have had with ambiguity.


[JR] As above, I am very hesitant to change syntax without a lot of direct feedback from developers as to how it would affect them. Wearing my own developer hat, I'm willing to make the change. But I can't speak for the rest of the community, so I'm going to start a new thread.

[JTB]  The definition is clear, and the = names are not unreasonable.  I don't think they need changing. =  

 

 

 

Section = 7

 

When a client_secret expires is it the intent that clients do an update or refresh to get a new client = secret?

 

Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify = this.

 

Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify = this.

 

Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested = changes?

 

Yes. Much of the feedback is coming from our development = community. 

 

Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)

 

Glad to hear that you=E2=80=99re working = with developers building the spec.  = Please thank them for the = feedback.

 

 -- Justin

 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =   Best wishes,

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

 

[PH] Thankss.

 


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

= --Apple-Mail=_7E00F785-C402-474D-B69C-609D6FC417A0-- --Apple-Mail=_CCA5EB79-C8FC-486A-8518-05F1267330C8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIwMjMxMDI0WjAjBgkqhkiG9w0BCQQxFgQUgFlBEsPX wn5c7zxd3UFL7YGHmREwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAVudQuRo4wmFwN7zfL0vD1cNP4HjxILHRgAY30dD6 /EFvkUShBGSzo0IW58erdspDMNknKSb7tT4GIwIL1wa2nSNx9E7Jz6qj9OclMYyDDHpUj5jekeup tvyTPL3VWO6eHcKQhZLVdr59d/EgPqfnwFhJLSXTDb5671i5s3ZJ86CxJWhdIpOIbJjSdBDcUE/S nxIYrvMOE5UFc1o+hxvfs09QiuP/PiOwfHwv2dher6kYx9FaXVWayCY7HX7UBie0pwfzni6m0h6W RXEaYv8a2Zc3b9xRF+rGeUiSvx9RsKYeEEhKvH2h5iu5BICBhVM2QSxIwOXY8/aDd+g3oCMqGAAA AAAAAA== --Apple-Mail=_CCA5EB79-C8FC-486A-8518-05F1267330C8-- From ve7jtb@ve7jtb.com Mon May 20 19:52:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3894C21F8F83 for ; Mon, 20 May 2013 19:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGbWTJFJMkpf for ; Mon, 20 May 2013 19:52:40 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1B43721F8F3E for ; Mon, 20 May 2013 19:52:39 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id y26so164397iab.17 for ; Mon, 20 May 2013 19:52:39 -0700 (PDT) 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=1X5YBfp3Iv5qRKjtVRIXCxy4KETAIqtSNOrpJBWTxKg=; b=l/ounnm9wEfQys4+MjQAzZ/Kq2kJ4B92KGfh3FZwHDW/UKwf7YrxaQHPded3Y6Olys IbWy3mtZmD0dQJCFRqqZJNVFBiZ41Fs0/OzU7FsVoL31AVayiaVgOC88bi9IeqTq7xU4 gFRw1OjR3R180ImmEl8/fGfvLj6VeewUmUAXkPc+4MbRmRGDD85slySvGhHKeuhRhdDo 48dwIuRNt+McyXD6PHkNEDFAFQo2srI0iYJeqBUmkn/NzfuHH+MJinwmLUUSYzLy0ewY qCibaLTst9MN4oO91BUTlzfDFqIWX0j/tgmLT6QLlH6veeuqsJ3xiHR8OKRN7lZdEidq trkQ== X-Received: by 10.50.115.100 with SMTP id jn4mr196467igb.92.1369104759449; Mon, 20 May 2013 19:52:39 -0700 (PDT) Received: from [192.168.1.42] (190-20-31-25.baf.movistar.cl. [190.20.31.25]) by mx.google.com with ESMTPSA id d7sm797313igx.5.2013.05.20.19.52.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 19:52:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E51F90E1-7BDB-4F76-8CEA-8F79993DCE7A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> Date: Mon, 20 May 2013 22:50:57 -0400 Message-Id: <54CD1656-0DEE-4060-B68D-3FE5FB77098B@ve7jtb.com> References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> <519A4512.9080905@mitre.org> <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkWAxlV2WQXK4I0X2FMm/u5CV3sLC7EmJ4uH3+79f2+fwQ+UCMQi17RWwxR1UBYieN5Chk/ Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 02:52:41 -0000 --Apple-Mail=_E51F90E1-7BDB-4F76-8CEA-8F79993DCE7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dynamic registration provides: 1 A client_id=20 2 (Optionally) a client secret that is used at the token endpoint per = OAuth. to authenticate the associated client_id 3 a URI that can be used to update the client_id (this is a REST concept = and may be thought of as a instance of client_id rather than the generic = registration URI that takes a POST to create a client instance and = assign it a resource identifier (registration_client_uri) , Name = (client_id) , client_secret and registration_access_token(access the new = resource) . =46rom the API point of view this is a new new resource = that is a instance of client and NOT a new instance of a particular = client. 4 a registration_access_token used by a developer or client to access = the new resource via registration_client_uri. So we are being more REST like than OAuth and that may be confusing some = developers. Mike and I had concerns about that, but I think creating a = specific resource for each client_id is likely the correct thing in the = long term. One slightly slipper part of this is that in some cases it may be the = client that is using this and in others it may be a developer. Lets not forget one of the main current uses of OAuth in Phone apps. = These are not confidential clients even if they are using the code flow. Typically a developer would use the dynamic registration API to create a = client at the AS. They would then take the client_id and bake that into = there distributed code. (this is super common now) They would not get a client_secret and hold on to the = registration_client_uri and registration_access_token to be able to = update settings for the deployed client instances and to be able to = revoke them possibly at some point in the future. All client instances = have the same client_id and client_secret (some people like to use it = even if it is not a real secret), the AS has no way to differentiate = between client instances. Perhaps that is a bad thing but that is = OAuth. We are not going to change the fundamental logic of OAuth in = registration. One thing we did leave room for in the spec was building something on = top of Dynamic registration using a bearer token provided out of band to = the developer. That token might constrain or provide defaults for clients registered = with it. This however needs to be defined as a part of another spec. = We discussed possibilities for dynamically creating client_id and = secrets for native apps so that a code generated form phone A could not = be intercepted by an attacker and used to get a access/refresh token.=20 This is perhaps instance management from a high level but still = conforming OAuth from the perspective of the AS and the flows. Looking at the wording we may not be doing a good enough job describing = that out of access token provisioned out of band for use at the dynamic = client registration endpoint which is described as "OAuth 2.0 [RFC6749] = access token" in Sec 3 as opposed to registration_access_token which is = used in Sec 4.2, 4.3, and 4.4 to access the "Client Configuration = Endpoint". John B. On 2013-05-20, at 12:36 PM, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2013-05-20, at 8:45, Justin Richer wrote: >=20 >>=20 >> On 05/17/2013 07:29 PM, Phil Hunt wrote: >>> He's saying every client gets a registration token and a client = token. >> What's a "client token", exactly? There are three potential places = for OAuth tokens in and around dynamic registration, and none of them = are called "client token". >=20 > i meant client credential. Client token is obviously a type of = client cred.=20 >>=20 >> 1) The registration access token, which binds a "client" (or = "instance of a client", if you will) to a set of registration = information at a specific authorization server. The client uses this to = call its Client Information Endpoint to do updates, refreshes, and = potentially delete itself. This token is *only* good at this Client = Information Endpoint, and nowhere else. This token is specific to the = registration it represents. >=20 > This is not apparent at all. No more than binding the = registration to the client credential since the implication is one reg = -> one client cred and one reg token.=20 >=20 > John Bradley has brought up seemingly other scenarios that would not = bind but rather associates a dev or an admin to a reg. i may be wrong. I = have not had time to consider his explanations yet.=20 >=20 > What seems clear is that there is confusion as to the purpose and role = for this token and what the use cases are for registration.=20 >=20 > My plan is to review and suggest clarifying text and changes if = necessary this week.=20 >>=20 >> 2) The (optional) initial token used to authenticate to the Client = Registration Endpoint. This is *not* the registration access token, and = it is *not* used to access the Client Information Endpoint. How the = client or developer get this token is out of scope. How the registration = server validates this token is out of scope. The structure and contents = of this token are out of scope. >>=20 >> 3) The access/refresh tokens that a registered client eventually gets = from the Token Endpoint and uses with protected resources. These tokens = aren't used at the Client Registration Endpoint or at the Client = Information Endpoint. >>=20 >> There are also a couple of related concepts that aren't tokens at = all: >>=20 >> 4) The client_id, which is issued to a "client" (or "client = instance") by the authorization server. This must be unique at the auth = server for each client instance. The client uses this client_id at the = Authorization Endpoint and the Token Endpoint in normal OAuth flows. >>=20 >> 5) The client_secret, which is issued to a "client" (or "client = instance") by the auth server, for confidential clients (ie: clients = that can protect their client_secret). This is used by the client to = authenticate to the Token Endpoint and nowhere else. >>=20 >>=20 >> Which of these do you mean by a "client token"? >>=20 >> -- Justin --Apple-Mail=_E51F90E1-7BDB-4F76-8CEA-8F79993DCE7A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIxMDI1MDU3WjAjBgkqhkiG9w0BCQQxFgQUm4ZIWnOg yc60ImvVXZ+z2XJQgRwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAK25H6IosqBB9nDc/UkDEMfaPyFjTheRypdCELvtD nXGIKnG8JlgEbeim8BZJsXFaJi+W2/7wu5BMs4bQL6uvUIYbOwCoFhaD+9sDjAq2T07fbTo3L+03 Yu40+h/9T0D3GvgNIHVA3VRU+e5CCWEQtJ30EuHFE91EGUHbj8cn2lOf8jPIVBh7KcU45RRwp3pr Zu9ZakjLlMtQHp9MPWFu4u28LwgQlGoMUnY4SAu1AkiejuYmBO5U/T71LWjpjlNLZfZ/+tDCaFQx GL9lbOomPIMr8ZZgLP+ZfZ9ZtgAU1JTOOTT+Y/X9p+QeG1LPOt8deSX5+Hmi2/fc+fLf8o9bOwAA AAAAAA== --Apple-Mail=_E51F90E1-7BDB-4F76-8CEA-8F79993DCE7A-- From ve7jtb@ve7jtb.com Mon May 20 19:53:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5921F93B6 for ; Mon, 20 May 2013 19:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0CpVlKZ1boz for ; Mon, 20 May 2013 19:53:06 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7683A21F8F3E for ; Mon, 20 May 2013 19:53:06 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c13so298791ieb.24 for ; Mon, 20 May 2013 19:53:06 -0700 (PDT) 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=Z+STI25vOSRE5OI44/KfVqNiN9tS5mkdhUG0X8uJPDE=; b=af6Spi7VIaLKJtkoH/z/MvjnOx+U/XHPJMp6I3CPROh+Qwz42z42Khb4OhaO+zpkvW J5vXMArpBIsJoD3tnQoYMzO+zXAHyMGQUbpPRDje1DpLshDDxfaHFc7gTXUnQu3BigP9 s5FadiOO8DZhUtOymQ1qH764p6+A6jDTlXq7OMc1MUULNGTZ+G0fa+syRi1gHDfUyTf2 3mDw0LSXlO9isl2UXNEHf6ATud5+EzyvBWEtBy8DmMej4WrCL+kD+Ck78jGLvS8fu81b btckgDaUYoxmew3v4YWQg97bDCDStesRbej4iRMRitSFJXc3NB6OQrqsBIbhf5pT2XlJ tbKA== X-Received: by 10.43.60.198 with SMTP id wt6mr206650icb.18.1369104785836; Mon, 20 May 2013 19:53:05 -0700 (PDT) Received: from [192.168.1.42] (190-20-31-25.baf.movistar.cl. [190.20.31.25]) by mx.google.com with ESMTPSA id d7sm797313igx.5.2013.05.20.19.52.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 19:53:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CB555A5A-2F24-420B-B46D-D27D753052F0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> Date: Mon, 20 May 2013 22:51:20 -0400 Message-Id: <51E8ECDF-9EFE-4E40-A5CD-DDBF4966AD65@ve7jtb.com> References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> <519A4512.9080905@mitre.org> <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkaKQKQIIGHsovA4kYfaeCblLhqxbbcR8No2ZGXWPftr28SEJxt/WVHIgT8Pzw4PD1vmFOR Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 02:53:07 -0000 --Apple-Mail=_CB555A5A-2F24-420B-B46D-D27D753052F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dynamic registration provides: 1 A client_id=20 2 (Optionally) a client secret that is used at the token endpoint per = OAuth. to authenticate the associated client_id 3 a URI that can be used to update the client_id (this is a REST concept = and may be thought of as a instance of client_id rather than the generic = registration URI that takes a POST to create a client instance and = assign it a resource identifier (registration_client_uri) , Name = (client_id) , client_secret and registration_access_token(access the new = resource) . =46rom the API point of view this is a new new resource = that is a instance of client and NOT a new instance of a particular = client. 4 a registration_access_token used by a developer or client to access = the new resource via registration_client_uri. So we are being more REST like than OAuth and that may be confusing some = developers. Mike and I had concerns about that, but I think creating a = specific resource for each client_id is likely the correct thing in the = long term. One slightly slipper part of this is that in some cases it may be the = client that is using this and in others it may be a developer. Lets not forget one of the main current uses of OAuth in Phone apps. = These are not confidential clients even if they are using the code flow. Typically a developer would use the dynamic registration API to create a = client at the AS. They would then take the client_id and bake that into = there distributed code. (this is super common now) They would not get a client_secret and hold on to the = registration_client_uri and registration_access_token to be able to = update settings for the deployed client instances and to be able to = revoke them possibly at some point in the future. All client instances = have the same client_id and client_secret (some people like to use it = even if it is not a real secret), the AS has no way to differentiate = between client instances. Perhaps that is a bad thing but that is = OAuth. We are not going to change the fundamental logic of OAuth in = registration. One thing we did leave room for in the spec was building something on = top of Dynamic registration using a bearer token provided out of band to = the developer. That token might constrain or provide defaults for clients registered = with it. This however needs to be defined as a part of another spec. = We discussed possibilities for dynamically creating client_id and = secrets for native apps so that a code generated form phone A could not = be intercepted by an attacker and used to get a access/refresh token.=20 This is perhaps instance management from a high level but still = conforming OAuth from the perspective of the AS and the flows. Looking at the wording we may not be doing a good enough job describing = that out of access token provisioned out of band for use at the dynamic = client registration endpoint which is described as "OAuth 2.0 [RFC6749] = access token" in Sec 3 as opposed to registration_access_token which is = used in Sec 4.2, 4.3, and 4.4 to access the "Client Configuration = Endpoint". John B. On 2013-05-20, at 12:36 PM, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2013-05-20, at 8:45, Justin Richer wrote: >=20 >>=20 >> On 05/17/2013 07:29 PM, Phil Hunt wrote: >>> He's saying every client gets a registration token and a client = token. >> What's a "client token", exactly? There are three potential places = for OAuth tokens in and around dynamic registration, and none of them = are called "client token". >=20 > i meant client credential. Client token is obviously a type of = client cred.=20 >>=20 >> 1) The registration access token, which binds a "client" (or = "instance of a client", if you will) to a set of registration = information at a specific authorization server. The client uses this to = call its Client Information Endpoint to do updates, refreshes, and = potentially delete itself. This token is *only* good at this Client = Information Endpoint, and nowhere else. This token is specific to the = registration it represents. >=20 > This is not apparent at all. No more than binding the = registration to the client credential since the implication is one reg = -> one client cred and one reg token.=20 >=20 > John Bradley has brought up seemingly other scenarios that would not = bind but rather associates a dev or an admin to a reg. i may be wrong. I = have not had time to consider his explanations yet.=20 >=20 > What seems clear is that there is confusion as to the purpose and role = for this token and what the use cases are for registration.=20 >=20 > My plan is to review and suggest clarifying text and changes if = necessary this week.=20 >>=20 >> 2) The (optional) initial token used to authenticate to the Client = Registration Endpoint. This is *not* the registration access token, and = it is *not* used to access the Client Information Endpoint. How the = client or developer get this token is out of scope. How the registration = server validates this token is out of scope. The structure and contents = of this token are out of scope. >>=20 >> 3) The access/refresh tokens that a registered client eventually gets = from the Token Endpoint and uses with protected resources. These tokens = aren't used at the Client Registration Endpoint or at the Client = Information Endpoint. >>=20 >> There are also a couple of related concepts that aren't tokens at = all: >>=20 >> 4) The client_id, which is issued to a "client" (or "client = instance") by the authorization server. This must be unique at the auth = server for each client instance. The client uses this client_id at the = Authorization Endpoint and the Token Endpoint in normal OAuth flows. >>=20 >> 5) The client_secret, which is issued to a "client" (or "client = instance") by the auth server, for confidential clients (ie: clients = that can protect their client_secret). This is used by the client to = authenticate to the Token Endpoint and nowhere else. >>=20 >>=20 >> Which of these do you mean by a "client token"? >>=20 >> -- Justin --Apple-Mail=_CB555A5A-2F24-420B-B46D-D27D753052F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIxMDI1MTIwWjAjBgkqhkiG9w0BCQQxFgQUm4ZIWnOg yc60ImvVXZ+z2XJQgRwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAPYHOVKPsnwdr9TE5ly5XLHMNOoeMhkjTBOR9L+5m STQGgA+iAsGrvgDKi5w4qwGgD3MdnP2u4JIGiQLH1r2uo/wl6QRV76sF1Y3okheuKIGCzm4tM7uz BK21anWNdbwVT2gpIInzWzfZEe59RdQNnhye7BC7AVB4Xl6GeQBHSZPIu2v9ox19rhFm8pF8IFze +mAu/fyU2+KpGC+GTjCx9+iv+wAKFRXT5xJbTaWxACENLxNcFanHQ4bCTEiUNuBZTn7N0AgJHpGA ZRGkadNBx9b2czs3pil3hjiTtQp4culmUC1zGoXO8Y4Yr7mb5Zbsx0D/OynMnmw5GroWnmtF+QAA AAAAAA== --Apple-Mail=_CB555A5A-2F24-420B-B46D-D27D753052F0-- From ve7jtb@ve7jtb.com Mon May 20 20:04:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CD821F96B3 for ; Mon, 20 May 2013 20:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X4TXdw7Cxt7 for ; Mon, 20 May 2013 20:04:05 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E727021F96A8 for ; Mon, 20 May 2013 20:04:04 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id m10so169230iam.6 for ; Mon, 20 May 2013 20:04:04 -0700 (PDT) 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=iMuWmd3cYmHGkrUoUCPJMpHOhjgNpbvGY0nvCJ2DZvQ=; b=K5p8PYxIiNz9R3dSXoyljmaYCvQftZHtq6gQV1Si1Z8JRjuOfz2h9rlAdeID92yzV3 9wC56KxEmFfylmCp2CSUVKS9ALqn1er/K+/aOt0MektsJ48nBekzQcOYlrYp1lmXZugu 33QAZTa2CD+NyThQGi0xzkRuunzR595kgc/nU85uoObznwOHpWC8USzbmroMWpK2g5YO UNAXb4odAvOIhjeZRXr43IoyJeW3wKyYrGxCDJSA2XpHj7kdevSejsm1BTS3Z9Npvrvg FijlUBhtMFXX/BLRfZ8rC7C5TpUoYsjiwp858QU1nieOB/QDan3qh4WYWYJr86Xyew6w pWRQ== X-Received: by 10.42.35.75 with SMTP id p11mr242025icd.6.1369105444231; Mon, 20 May 2013 20:04:04 -0700 (PDT) Received: from [192.168.1.42] (190-20-31-25.baf.movistar.cl. [190.20.31.25]) by mx.google.com with ESMTPSA id qr3sm22886166igb.1.2013.05.20.20.03.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 20:04:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2804F0C2-7962-4101-9967-E48E90216456"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Mon, 20 May 2013 23:03:50 -0400 Message-Id: References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A5261.1010506@mitre.org> <4E1F6AAD24975D4BA5B168042967394367742D5A@TK5EX14MBXC283.redmond.corp.microsoft.com> <278419A3-8FFE-45F6-81A8-90D5CFFC13CB@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk8nYL7a4jeCQkDeYVzo4eRrBSxvyiYJY83cs8e/6L4HRXVjQHe8rat/ySUi/dhbpn8L06Y Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 03:04:07 -0000 --Apple-Mail=_2804F0C2-7962-4101-9967-E48E90216456 Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBF1238-1029-4643-9717-D0F5849707CF" --Apple-Mail=_5BBF1238-1029-4643-9717-D0F5849707CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Phil the token_endpoint_auth_method is not broken. We have agreed that = the methods defined in Connect and not in the base spec will be = registered separately in the registry rather than being in the base = spec. I don't think that is broken. They are documented in Connect, that works for connect but less so for = people who don't use that spec, so they go in the registry. They are NOT related to HoK in any way they are just the JWT assertion = profile with keying specified for symmetric and asymmetric. The bearer = profile as it is needs both sides to agree on keying otherwise it tends = not to work. =20 Some similar generic profile will need to be defined for JWT and SAML = assertions to get interoperability outside of connect. So this is not a breaking change, just a slight shuffling of where = things are. John B. On 2013-05-20, at 2:27 PM, Phil Hunt wrote: > Further to my last=85 >=20 > Justin has already committed to breaking changes. This may have been = lost or buried in the long review thread. >=20 > Specifically - The client authentication types specified are = undocumented (client_secret_jwt and private_key_jwt) as they were all = Holder-of-Key authentication methods. The OAuth drafts currently only = have bearer drafts and dyn reg does not support these profiles. Justin = has acknowledged this. >=20 > It seems to me, that since the token_endpoint_auth_method is broken, = the current implementations are actually implementing the draft = correctly or servers are just ignoring it the parameter. >=20 > There are concerns with this draft. I plan to make specific = suggestions (some breaking) later this week. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-20, at 10:51 AM, Phil Hunt wrote: >=20 >> -1 >>=20 >> The draft has features that are unclear and will double the = operational cost. The fact that it works doesn't mean it is ready from = the wg perspective.=20 >>=20 >> For the production use, has anyone outside of oidc implemented and = placed in production? >>=20 >> As a non-oidc implementer, I can't make the same assumptions (like = discovery) that oidc umplementers have.=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 9:48, Mike Jones = wrote: >>=20 >>> The deployment evidence doesn=92t support your position, Phil. = There are over a dozen interoperable implementations already deployed. = Those deployments demonstrate that the spec, as written, is already = doing one thing well =96 enabling clients (as defined by RFC 6749) to = register with Authorization Servers, obtaining client_id and optionally = client_secret values that enable those clients to use those = Authorization Servers. Doing one thing well is exactly what we should = be striving for, and the evidence says that we=92ve achieved that. >>> =20 >>> It=92s time to ship it! >>> =20 >>> -- = Mike >>> =20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Justin Richer >>> Sent: Monday, May 20, 2013 9:42 AM >>> To: Phil Hunt >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration >>> =20 >>> I, of course, disagree. But that's what we're trying to figure out = as a working group, after all. >>>=20 >>> -- Justin >>>=20 >>> On 05/20/2013 12:41 PM, Phil Hunt wrote: >>> This draft isn't ready for LC.=20 >>>=20 >>> Phil >>>=20 >>> On 2013-05-20, at 8:49, Justin Richer wrote: >>>=20 >>> But also keep in mind that this is last-call, and that we don't = really want to encourage avoidable drastic changes at this stage.=20 >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On 05/20/2013 11:21 AM, Phil Hunt wrote: >>> Keep in mind there may be other changes coming.=20 >>> =20 >>> The issue is that new developers can't figure out what token is = being referred to.=20 >>>=20 >>> Phil >>>=20 >>> On 2013-05-20, at 8:09, Justin Richer wrote: >>>=20 >>> Phil Hunt's review of the Dynamic Registration specification has = raised a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 >>>=20 >>>=20 >>> 1) expires_at -> client_secret_expires_at >>> 2) issued_at -> client_id_issued_at >>> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >>>=20 >>>=20 >>> I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these: >>>=20 >>> A) Keep the parameter names as-is >>> B) Adopt the new names as above >>> C) Adopt a new name that I will specify >>>=20 >>> In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. >>>=20 >>> Naming things is hard. >>>=20 >>> -- Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5BBF1238-1029-4643-9717-D0F5849707CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Phil = the token_endpoint_auth_method is not broken. We have agreed that the = methods defined in Connect and not in the base spec will be = registered separately in the = registry rather than being in the base spec. I don't think that is = broken.

They are = documented in Connect, that works for connect but less so for people who = don't use that spec, so they go in the = registry.

They are NOT related to HoK = in any way they are just the JWT assertion profile with keying specified = for symmetric and asymmetric. The bearer profile as it is needs both = sides to agree on keying otherwise it tends not to work. =

Some = similar generic profile will need to be defined for JWT and SAML = assertions to get interoperability outside of = connect.

So this = is not a breaking change, just a slight shuffling of where things = are.

John = B.


On 2013-05-20, at 2:27 PM, Phil Hunt = <phil.hunt@oracle.com> = wrote:

Further to my = last=85

Justin has already committed to breaking = changes.  This may have been lost or buried in the long review = thread.

Specifically - The client authentication = types specified are undocumented (client_secret_jwt and private_key_jwt) = as they were all Holder-of-Key authentication methods.  The OAuth = drafts currently only have bearer drafts and dyn reg does not support = these profiles.  Justin has acknowledged = this.

It seems to me, that since the token_endpoint_auth_method is = broken, the current implementations are actually implementing the draft = correctly or servers are just ignoring it the = parameter.

There are concerns with this draft. =  I plan to make specific suggestions (some breaking) later this = week.

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





On 2013-05-20, at 10:51 AM, Phil Hunt wrote:

-1

The draft has features = that are unclear and will double the operational cost. The fact that it = works doesn't mean it is ready from the wg = perspective. 

For the production use, has = anyone outside of oidc implemented and placed in = production?

As a non-oidc implementer, I can't = make the same assumptions (like discovery) that oidc umplementers = have. 

Phil

On 2013-05-20, at 9:48, Mike Jones = <Michael.Jones@microsoft.com> wrote:

The deployment evidence doesn=92t support your = position, Phil.  There are over a dozen interoperable = implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well =96 enabling = clients (as defined by RFC 6749) to register with Authorization Servers, = obtaining client_id and optionally client_secret values that enable = those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the = evidence says that we=92ve achieved that.

 

It=92s time to ship it!

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

I, of course, disagree. But that's what = we're trying to figure out as a working group, after all.

 -- Justin

On 05/20/2013 12:41 PM, Phil Hunt = wrote:

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> = wrote:

But also keep = in mind that this is last-call, and that we don't really want to = encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt = wrote:

Keep in mind there may be other changes = coming. 

 

The issue is that new developers can't = figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> = wrote:

Phil Hunt's review of the Dynamic = Registration specification has raised a couple of issues that I felt = were getting buried by the larger discussion (which I still strongly = encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for = developers with the new parameter names, I am open to fixing them = now.

Naming things is hard.

 -- Justin

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

 

 

=
_______________________________________________
OAut= h mailing 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=_5BBF1238-1029-4643-9717-D0F5849707CF-- --Apple-Mail=_2804F0C2-7962-4101-9967-E48E90216456 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIxMDMwMzUwWjAjBgkqhkiG9w0BCQQxFgQUq0Sv2Dg9 vXs0BRbSuYNBigf4BeowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlqYzmGmYrD/BU9Yet9Yx7Ey8PD1dUgorQvkLOkqo gbiyouOzDQkarCBqhNBmX5UJ7KuFaOT60VkQ6MzTZd3PaHNbcKtQ/0B2pl6ramCSgt2h8GMXlMsD gjtRVLfS2CVAG7pdY+Ojj/IwdNHtRYwTkwREWQha7hq+CYffl0HV+pKDpI1X+0zb/8HD7qQspZdd kLmFYwnCYUcunibrnmoDgll8Xq+7jrLzmBqTE1xtgtUXdWqj7lWVCMEgQznHM06mSnFZtcXxhkFw fED4a2jhaXcL+wInpO0unjdoIcYmklbvpvJBpOYgoCly1N1V23Ze7iK3N8o0NQINyD/yH3wrxQAA AAAAAA== --Apple-Mail=_2804F0C2-7962-4101-9967-E48E90216456-- From roland.hedberg@adm.umu.se Mon May 20 20:53:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CAC21F973F for ; Mon, 20 May 2013 20:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6iaq9Qj+Pol for ; Mon, 20 May 2013 20:53:08 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch1.ad.umu.se [130.239.1.246]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8021F973C for ; Mon, 20 May 2013 20:53:04 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.2.46]) by UMDAC-CH1.ad.umu.se ([130.239.1.246]) with mapi; Tue, 21 May 2013 05:52:54 +0200 From: Roland Hedberg To: nov matake Date: Tue, 21 May 2013 05:52:56 +0200 Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: Ac5V1qv7fF7S/PfdSdGo/zMEGX1d7Q== Message-ID: <6C60D517-5601-4979-A68B-3C192C00F365@umu.se> References: <519A3C9A.8060305@mitre.org> <1369081433.10108.YahooMailRC@web184401.mail.bf1.yahoo.com> <1AA85E6D-525D-4DCE-9A7D-B5573AF33E3E@gmail.com> In-Reply-To: <1AA85E6D-525D-4DCE-9A7D-B5573AF33E3E@gmail.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" , Edmund Jay Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 03:53:16 -0000 KzENCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiAyMSBtYWogMjAxMywgYXQgMDA6MjEsICJu b3YgbWF0YWtlIiA8bWF0YWtlQGdtYWlsLmNvbTxtYWlsdG86bWF0YWtlQGdtYWlsLmNvbT4+IHdy b3RlOg0KDQorMQ0KDQpPbiAyMDEzLzA1LzIxLCBhdCA1OjIzLCBFZG11bmQgSmF5IDxlamF5QG1n aTEuY29tPG1haWx0bzplamF5QG1naTEuY29tPj4gd3JvdGU6DQoNCisxIGZvciBrZWVwaW5nIG5h bWVzIGFzIGlzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4N ClRvOiAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBNb24sIE1heSAyMCwgMjAxMyA4OjEw OjEzIEFNDQpTdWJqZWN0OiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5 bmFtaWMgUmVnaXN0cmF0aW9uDQoNClBoaWwgSHVudCdzIHJldmlldyBvZiB0aGUgRHluYW1pYyBS ZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBoYXMgcmFpc2VkIGEgY291cGxlIG9mIGlzc3VlcyB0 aGF0IEkgZmVsdCB3ZXJlIGdldHRpbmcgYnVyaWVkIGJ5IHRoZSBsYXJnZXIgZGlzY3Vzc2lvbiAo d2hpY2ggSSBzdGlsbCBzdHJvbmdseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIGp1bXAgaW4gdG8pLiBO YW1lbHksIFBoaWwgaGFzIHN1Z2dlc3RlZCBhIGNvdXBsZSBvZiBzeW50YXggY2hhbmdlcyB0byB0 aGUgbmFtZXMgb2Ygc2V2ZXJhbCBwYXJhbWV0ZXJzLg0KDQoNCjEpIGV4cGlyZXNfYXQgLT4gY2xp ZW50X3NlY3JldF9leHBpcmVzX2F0DQoyKSBpc3N1ZWRfYXQgLT4gY2xpZW50X2lkX2lzc3VlZF9h dA0KMykgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgLT4gdG9rZW5fZW5kcG9pbnRfY2xpZW50 X2F1dGhfbWV0aG9kDQoNCg0KSSdkIGxpa2UgdG8gZ2V0IGEgZmVlbGluZywgZXNwZWNpYWxseSBm cm9tIGRldmVsb3BlcnMgd2hvIGhhdmUgZGVwbG95ZWQgdGhpcyBkcmFmdCBzcGVjLCB3aGF0IHdl IG91Z2h0IHRvIGRvIGZvciBlYWNoIG9mIHRoZXNlOg0KDQogQSkgS2VlcCB0aGUgcGFyYW1ldGVy IG5hbWVzIGFzLWlzDQogQikgQWRvcHQgdGhlIG5ldyBuYW1lcyBhcyBhYm92ZQ0KIEMpIEFkb3B0 IGEgbmV3IG5hbWUgdGhhdCBJIHdpbGwgc3BlY2lmeQ0KDQpJbiBhbGwgY2FzZXMsIGNsYXJpZnlp bmcgdGV4dCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBwYXJhbWV0ZXIgKmRlZmluaXRpb25zKiBzbyB0 aGF0IGl0J3MgbW9yZSBjbGVhciB0byBwZW9wbGUgcmVhZGluZyB0aGUgc3BlYyB3aGF0IGVhY2gg cGllY2UgZG9lcy4gU3BlYWtpbmcgYXMgdGhlIGVkaXRvcjogIkEiIGlzIHRoZSBkZWZhdWx0IGFz IGZhciBhcyBJJ20gY29uY2VybmVkLCBzaW5jZSB3ZSBzaG91bGRuJ3QgY2hhbmdlIHN5bnRheCB3 aXRob3V0IHZlcnkgZ29vZCByZWFzb24gdG8gZG8gc28uIFRoYXQgc2FpZCwgaWYgaXQncyBnb2lu ZyB0byBiZSBiZXR0ZXIgZm9yIGRldmVsb3BlcnMgd2l0aCB0aGUgbmV3IHBhcmFtZXRlciBuYW1l cywgSSBhbSBvcGVuIHRvIGZpeGluZyB0aGVtIG5vdy4NCg0KTmFtaW5nIHRoaW5ncyBpcyBoYXJk Lg0KDQogLS0gSnVzdGluDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From phil.hunt@oracle.com Mon May 20 23:01:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0421F9509 for ; Mon, 20 May 2013 23:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaKIISeYkdgW for ; Mon, 20 May 2013 23:01:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5321F94F9 for ; Mon, 20 May 2013 23:01:33 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4L61RiB015432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 06:01:28 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4L61RU0016785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 06:01:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4L61RGw029842; Tue, 21 May 2013 06:01:27 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 23:01:19 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519A42B4.2020803@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-F0925781-684C-4B19-A316-7463B277CFBE Content-Transfer-Encoding: 7bit Message-Id: <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Mon, 20 May 2013 23:01:14 -0700 To: Justin Richer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 06:01:34 -0000 --Apple-Mail-F0925781-684C-4B19-A316-7463B277CFBE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phil On 2013-05-20, at 8:35, Justin Richer wrote: >=20 > On 05/17/2013 05:27 PM, Phil Hunt wrote: >> Mike, >>=20 >> Rather then embed comments in an extended thread, I'd like to open up a s= pecific discussion on the objective of dyn reg. >>=20 >> I see limited to no value in having clients completely anonymously regist= ering and receiving tokens without any ability to correlate applications bet= ween applications. >=20 > I think that herein lies a very big disconnect in assumptions. I see a hug= e benefit in anonymously registered clients getting tokens because there is a= n end-user in the loop during the authorization phase (long after registrati= on has happened). The arity of registrations to authorizations approaches 1:= 1 in these cases, and I'm just fine with that.=20 Then what you describe is NOT anonymous but rather a profile not covered= by the spec as there is no discussion of user authenticated registration. I= mplicitly or explicitly.=20 >=20 > =46rom the RFC6749 perspective, a "client" is not a particular piece of co= de, it is a particular copy of a piece of code with a particular client_id f= rom the vantage point of a particular authorization server. actually, i disagree. This spec fundamentally breaks the old definition= and behavior from 6749. In the old way every instance of software shared a c= lient_id. In this draft, u throw that away without preserving the informatio= n. This is BAD! > A "client" is, conceptually, a pairwise association between two running co= debases. When you have a particular piece of code talking only to one auth s= erver and being manually configured at said auth server with its client_id, t= his is fairly clear and straightforward and the arity is simple. Things get a= bit muddy when you introduce dynamic registration, which is why I think tha= t we need to have introductory text about this. Specifically: >=20 > - a particular piece of code can be run on multiple devices and talk to t= he same auth server, each copy of that code getting its own client_id.=20 > - a particular copy of a particular piece of code can now be expected to t= alk to multiple auth servers, each auth server giving the piece of code its o= wn client_id.=20 >=20 > Both of these are cases of what defines an "instance" in most people's hea= ds, even though it's the same software, even sometimes the same running copy= of the same software. But as far as RFC6749's definition of "client" is con= cerned, these are all completely separate "client"s with no way to tie them t= ogether out of the box. And that's fine. >=20 >>=20 >> Associating client_id's with known client applications to allow admins to= know who is running what version of clients seems to be the most fundamenta= l part of the reason for dynamic reg. How can you revoke access to particula= r client app types? As Justin already talked about in his Blue Butt= on+ scenario, there are often life and death situations where particular set= s of clients need to be revoked.=20 > While it's very useful, I wouldn't (and haven't) classified it quite like t= hat. Nor would I say that the BB+ profile is a complete solution -- our Regi= stry component does not actually push revocation notifications down to Provi= ders (yet), so it's more like invalidating a root certificate and waiting fo= r caches to time out for things to cascade. We've been talking about adding s= ome form of callback to providers, but we don't want to boil that particular= ocean right now. However, the BB+ profile makes use of a well-specified dis= covery and Registry set up, as well as data conveyed in structured, signed t= okens (JWTs) at different points in the process. >=20 >>=20 >> Or put another way. I believe this will be a critical operational require= ment going forwards. If the spec is published as is, it will be quickly inva= lidated by one that does at least partially address the problem. > That's not true at all. BB+ addresses this scenario and still uses the Dyn= amic Registration spec as-is. I would encourage folks to read what we're doi= ng, a work-in-progress found here: but you are breaking other things and overloading client cred etc to pa= ss in signed data. I don't want a hack for a solution. I want interop.=20 >=20 > http://blue-button.github.io/blue-button-plus-pull/ >=20 > Just because you make something better doesn't mean you throw necessarily a= way everything you've done to date. >=20 >>=20 >> We're ahead of schedule, lets talk through the requirement. > I believe that the requirement of tying instances together is explicitly o= ut of scope for the dynamic registration protocol. I intended to have text t= o that effect in the section I'm adding about the client lifecycle. where is this stated in charter? >=20 >>=20 >> As I mentioned in my comments to the other thread. Let's say we agree not= do this now. Well, then the new draft that does solve it would likely be 95= % overlap. Thus I see this issue as within charter and should be solved now= rather then waiting for a V2 dyn reg in the next charter. > Why wouldn't the new draft just be the extra 5%? I personally think that i= t's a lot more than 5% once you have in all the assurance and safety mechani= sms in place to avoid self-asserted values causing race conditions, and what= not. Two drafts to do registration is not the way to go. It implies complexi= ty where there should be none. There is no technical reason for two drafts.=20= >=20 > -- Justin >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>=20 >>> Thanks for the detailed feedback, Phil. Sorry for the delayed response =E2= =80=93 I was pretty fully engaged at the European Identity Conference (where= OAuth 2.0 won the award for best new standard J). My feedback on the point= s raised is inline in green=E2=80=A6 >>> =20 >>> (Perhaps if any of you reply to this thread, you could also choose a dis= tinct color for your inline replies, so that it will be easily evident who s= aid what. As it is, just the back-and-forth between Phil and Justin is alre= ady very difficult to follow. Thanks.) >>> =20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Phil Hunt >>> Sent: Thursday, May 16, 2013 12:54 PM >>> To: Richer, Justin P. >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 >>> =20 >>> Justin, >>> =20 >>> Thanks for the discussion. More comments below... >>> =20 >>> BTW. I'm happy to contribute text. Just want to get to some rough agreem= ent first. For example, I think we need to have a away to recognize two pie= ces of software as being the same (even if self-asserted). Once defined, I c= an put together some intro text, etc. >>> =20 >>> Phil >>> =20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> =20 >>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>> =20 >>> On May 15, 2013, at 10:30 PM, Phil Hunt >>> wrote: >>> =20 >>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>> =20 >>> Phil, many thanks for the extremely thorough review! It is very useful i= ndeed.=20 >>> =20 >>> My comments and responses to each point are inline.=20 >>> =20 >>> On May 15, 2013, at 4:30 PM, Phil Hunt wrote: >>> =20 >>> It seems unfortunate that I have not gotten a chance to get into this le= vel of detail much earlier. But then, I guess that's what LC review is for! M= y apologies for not getting many of these concerns to the WG much earlier. >>> =20 >>> Overall =20 >>> ----------- >>> I think dynamic registration is a critical part of the OAuth framework n= ow that we are starting to consider how individual client applications shoul= d operate when there is one or more deployments of a particular resource API= . We've moved from the simple use case of a single API provider like Faceboo= k or Flickr and moved on to standards based, open source based, and commerci= al based deployments where there are multiple service endpoints and = many clients to manage. >>> =20 >>> The dynamic registration spec is actually dealing with a couple of issue= s that I would like to see made more clear in early part of the spec: >>> =20 >>> 1. How is a new client application recognized for the first time when d= eployed against a particular SP endpoint? Should clients actually assert an= application_id UUID that never changes and possibly a version id that does c= hange with versions? >>> =20 >>> In the general case, why is any = recognition required? If you're doing things as part of a larger proto= col ecosystem, like Blue Button+ or a particular OpenID Connect provider, th= en you can define semantics for tying together classes of clients (see below= for more discussion on this very point). But in general, a client is just g= oing to show up as a new instance to the AS and get issued a new, unique cli= ent_id, and that's that.=20 >>> =20 >>> I think we have to define more clearly what an "instance" is. For me, th= ere are applications and there are instances of that application. It is use= ful to understand that a client application represents a set of code that sh= ould behave in a consistent way. It seems to me the first time a new applic= ation shows up is very different from the subsequent instances that register= . For example, after the first registration, subsequent instances don't need= special review or approval to the same degree. >>> =20 >>> But without other mechanisms to tie things together, there's no way for a= n authorization server to know if any client instance is tied to any other c= lient instance. Therefore, from the perspective of an AS, the first instance= of an application (i.e., particular configuration of a set of code) to regi= ster is no different to subsequent instances of that same = application. How were you envisioning an AS knowing the differ= ence between the first and subsequent instances of an application, specifica= lly? If there's an "application_id" like you mention above, I think it raise= s more questions than it resolves: Who issues the application_id, some serve= r or the application itself? Is it validated at all? Should it be considered= secret? What happens when someone simply steals an application_id? Does an A= S have to do anything to check with any other AS to see if the application_i= d has already been used elsewhere? >>> =20 >>> I do agree that a discussion of "instance vs. application" would be help= ful in clearing this up, I'll make a note to add text to that effect. (We ha= d to do something similar for BB+) >>> =20 >>> I think it is simple enough to at least add a self generated UUID for th= e application ID. Though I would allow for cases where the application ID i= s assigned when the client developer and the APIs owner do a formal assignme= nt of application IDs. >>> =20 >>> In a sense this is just a lower tech way of doing it than what you descr= ibed as the initial client credential in Blue Button+ where you encoded extr= a claims into the initial app credential. >>> =20 >>> What the UUID does is link multiple instances of a client app together a= s the same "thing" that should have similar heuristics/behaviours. This is v= ery useful if you want to be able to revoke access to a set of clients ident= ified by application id (or a version of that app). >>> =20 >>> While I=E2=80=99m sympathetic to the OAuth working group eventually doin= g work on differentiating between instances of= an OAuth client, I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no= such thing as a client instance. There are o= nly clients, which are identified by client_id values. = If we want to do work on client instances, we should recharter to a= dd this new work as a working group deliverable. We should not try to shoeh= orn bits and pieces of it into the Dynamic Registration spec, any more than w= e should have tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg= is there to register clients as defined in RFC 6749. It=E2=80=99s not the r= ight place to extend what an OAuth client is in new ways. >>> =20 >>> 2. How are client credentials managed. Are we assuming client credentia= ls have a limited lifetime or rotation policy? >>> =20 >>> The intent was that client_secret could be rotated, as indicated by the e= xpires_at member of the response. If a client's secret expires, it calls the= read operation on the Client Configuration Endpoint (=C2=A74.2) to get its n= ew client_secret. If this is unclear in the current text (which I suspect it= may be after multiple refactoring= s), then I welcome suggestions and specific text as to how to make that clea= r.=20 >>> Something like this should be in the draft. >>> =20 >>> Should this be up in the introductory text, somewhere else, or have its o= wn section? >>> =20 >>> I'm starting to think credential management is a key part of the draft. I= t may be worth introducing a specific section outling the registration life-= cycle, registration access token usage, and cl= ient token usage and bootstrapping. >>> =20 >>> I think that adding a discussion on this would be fine, as it could help= developers understand the workflow of registering, using, and updating regi= stered clients. >>> =20 >>> How does a client authenticate the first time and subsequent times to th= e registration service? >>> =20 >>> This is a separate question all = together, as it does not involve the client_secret or client_id at all. R= ather, the first time the client shows up to the registration service, it ma= y either: >>> - Not authenticate at all (this is the true public, open registration,= and it is recommended that servers do this) >>> - Authenticate using an OAuth 2.0 token (which ATM means a bearer token= ). How the client gets that bearer token and what the bearer token means to t= he AS beyond "this client is authorized to register" is out of scope for the= spec, by design. >>> =20 >>> Subsequent times that the same registered client (by which we mean the s= ame instance of a client with a particular client_id) shows up at the regist= ration endpoint (actually, the Client Configuration Endpoint), it uses its R= egistration Access Token that it was issued on initial registration. This is= an OAuth 2.0 Bearer token that is unique to the client instance. >>> =20 >>> Something like this should be in the draft. >>> =20 >>> OK, the definition of the registration access token can be expanded, but= I think that the rest of it is already in there in =C2=A73. I'd welcome sug= gestions on which bits of this could be made clearer. >>> =20 >>> See the discussion on what the registration_access_token is in the threa= d =E2=80=9CClient Credential Expiry and new Registration Access Token - draf= t-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin to apply these cl= arifications to the specification. This may go into the proposed credential= management overview section discussed above. >>> =20 >>> 3. How is versioning of clients managed? Should each new version of a c= lient require a change in clie= nt registration including possibly changing client_id and authentication cre= dential? I don't have a strong feeling, but it is something that implementor= s should consider. >>> =20 >>> This is up to the AS, really, and I don't think that any global policy w= ould ever fly here. Especially if you consider that the entire notion of "ve= rsion" is more fluid these days than it ever has been. I wouldn't mind addin= g a discussion in the security considerations if it merits mentioning though= , so that we can help both client developers and server developers institute= reasonably good policy. >>> =20 >>> I guess the issue is that when a client upgrades it may have access to t= he old credentials. What is the intent then of registration. Since you have= an update are clients expected to update /re-register or not? I'm not sure= this is a security consideration but more part of the whole change manageme= nt function dynamic registration supports. >>> =20 >>> If your upgraded version of the client still has access to its old crede= ntials, why wouldn't it just use those? I don't see a reason for forcing a r= e-registration. Nor do I see any way that an AS would even be able to tell t= hat a client had been upgraded. An upgraded client always has the *option* o= f re-registering itself and getting a new client_id.=20 >>> I think the concern here is that rotation of client credential is not so= mething discussed before. Before we put it in the spec we should consider th= e reasons for doing it and what problems it solves. >>> =20 >>> I think this may be just a case of letting people exchange credentials f= or whatever reason they feel is appropriate. The version upgrade thing sugg= ests that when a client is upgraded it should go to the registration server t= o "re-register". Depending on the policy of the server, it may (or may not)= receive a new client_id and/or new credential. =20 >>> =20 >>> One of the best benefits I can think of is if you discover a version of a= client has a problem, being able to select a group of clients by software a= nd version is important. Thus if client_id doesn't trace to a particular sof= tware and version, that makes it hard to do. I think you talked about this= as an issue for Blue Button+ >>> =20 >>> Again, RFC 6749 defines no client instances or groups of clients, theref= ore I believe that it=E2=80=99s inappropriate t= o do so here. We don=E2=80=99t need to boil the ocean. = If a new charter item is approved to do work on client instances a= nd protocol elements to use and express them, that=E2=80=99s the time for th= e working group to consider that possibility =E2=80=93 not as part of Dynami= c Client Registration. >>> =20 >>> 4. What is the registration access token? Why is is used? What is its l= ife-cycle? When is it issued, when is it changed? When is it deleted? >>> =20 >>> See the response above above and the definition in =C2=A71.2:=20 >>> =20 >>> Registration Access Token: An OAuth 2.0 Bearer Token issued by the Autho= rization Server through the Client Registration Endpoint which is used by th= e Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client. >>> =20 >>> If this can be clarified, I welcome text suggestions. >>> =20 >>> The latter part of 1.2 didn't seem like terminology but rather architect= ure or part of the introduction that describes what the spec does. The third= point doesn't seem to fit with the other two except to say that the dynamic= registration endpoints use their own access tokens called registration acce= ss tokens. >>> =20 >>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>> a Client can request new registration. The means of the Client >>> obtaining the URL for this endpoint are out of scope for this >>> specification. >>> =20 >>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>> which a specific Client can manage its registration information, >>> provided by the Authorization Server to the Client. This URL for >>> this endpoint is communicated to the client by the Authorization >>> Server in the Client Information Response. >>> =20 >>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the= >>> Authorization Server through the Client Registration Endpoint >>> which is used by the Client to authenticate itself during read, >>> update, and delete operations. This token is associated with a >>> particular Client. >>> =20 >>> This section is meant to just introduce the new terms that are then expl= ained in greater detail throughout the rest of the document. Yes, it's a bit= architecture, but only in the sense that you need to define the terms that m= ake up your architecture. How would you suggest that it change? >>> =20 >>> Probably this is more a matter of style. But, what happened for me is I= naturally skipped the terminology section, as I wasn't expecting protocol c= omponents to be there. "terminology" is something I think people tend to us= e as a dictionary rather than as protocol component description. Maybe the c= hairs can advise? >>> =20 >>> If we distinguish between first = time registration of a particular client software package, it is possibl= e that somethings like authentication method can be = negotiate in or out-of-band at that time. Subsequent reg= istrations should only have parameters for items that could change per deplo= yment (like tos_uri). I think token_endpoint_auth_method is one thing that s= hould not be negotiated per instance. >>> =20 >>> When subsequent instances = register, I have to ask the question, for example when would things like "= token_endpoint_auth_method" be negotiated or be different for the same clien= t software? Should not all instances use the same authentication method. >>> =20 >>> I'm confused by this -- as far as the dynamic registration spec is conce= rned, all instances are separate from each other. All parameters change per i= nstance. And instance, you should keep in mind, is defined as any one copy o= f the client code connecting to any new authorization server. That pairing c= reates the client_id, and therefore the instance, and therefore the registra= tion access token, and therefore the registration itself at a conceptual lev= el. So there is no way other than per-instance for a client to ask for a par= ticular token_endpoint_auth_method. Where else would the AS find out about i= t? >>> =20 >>> We still disagree on this. It is my assertion that clients should NEVER a= sk for a particular token auth method.= Since it is the AS that is authenticating the client, then it is the AS's r= ight to set the authentication policy. The role of dynamic reg endpoint is t= o inform the client what it must do. My assumption is that during the first= time a piece of software is registered (the first instance), there could be= some OOB discussion by an administrator to approve the particular authentic= ation type for the AS in question. >>> =20 >>> I haven't heard a reason justifying = this parameter other then "it is needed". Why? >>> =20 >>> The role of the dynamic registration protocol is twofold: half of that i= s the server informing the client what it must do. But the other half is the= client informing the server what it *can* do, or what it *wants* to do.=20 >>> =20 >>> And again, there's no way to distinguish a first instance from a subsequ= ent instance unless you're doing something in addition. Nothing is stopping t= he same application from registering a new i= nstance of itself for every single user or every single token that it wants t= o get access for. That's complicated and wasteful and not a great idea, sure= , but there's no useful way to prevent that kind of behavior if you also wa= nt open registration of clients.=20 >>> =20 >>> I think we've discussed how recognizing subsequent instances is easily d= one. >>> =20 >>> As I mentioned in the other thread, if a developer chooses to limit the c= apabilities of the client it must do so by looking to the developer or stand= ard behind the API. Otherwise they are taking the chance. There's no way a= developer can query all the potential deployers to ask what authn types wil= l you use. As I said, the net effect in the absence of an API standard dicta= ting what should be supported, the developer will have to implement all meth= ods. >>> =20 >>> My point here is that none of this is helped by the client app saying wh= at it supports. A developer who takes the route of= limiting implementation takes the chance that the server will not accept. S= o why negotiate within registration? >>> =20 >>> And there's no way other than per-instance for the server to tell the cl= ient which token_endpoint_auth_method to = use. All instances will probably ask for the same token_endpoint_auth= _method from all auth servers they talk to, right? And each AS will tell eac= h instance that registers with it to use a particular auth method. There is n= o way to tie together different instances across (or within) auth servers wi= thout specifying a significant amount of other machinery. >>> =20 >>> Which is not to say that it's not useful in some circumstances to tie to= gether different instances of the same code across (or within) auth servers.= This is why, with Blue Button+, we specified a specific token format for th= e initial access token that the clients use to call the registration endpoin= t the first time, as well as a discovery protocol against a centralized ser= ver that handles pre-registration. All of this machinery is, in my opinion, a= stupendous overkill for the gener= al case, though if some folks find use for it outside of BB+ then it'd be a g= ood thing to abstract out and make= its own spec that extends the Dyn Reg spec in a fully compatible way. Furth= ermore, even in Blue Button+ we specify that all auth servers MUST also acce= pt open registration, without an initial access token, where the client simp= ly shows up and says "hey, here are my parameters." The auth server has no w= ay to know in this case any kind of out-of-band negotiation for different th= ings. In BB+ we are writing very specific policy = guidelines about how to present the UX and things to the end u= ser for all of these different cases. But again, all of this is specific to t= he BB+ use case, and I don't see value in dragging it in to the registration= spec on its own. I believe it would be far too limiting. >>> =20 >>> See my previous comments on differentiating client instances being out o= f scope without rechartering to do this new work and on what the registratio= n_access_token is. In short, the registration_access_token is an RFC 6750 b= earer token issued to the party registering the client, enabling it to subse= quently retrieve information about the client registration and to potentiall= y update the registration information for that registered client. Again, I=E2= =80=99ll work with Justin to make sure that this is as clear as possible in t= he specification. >>> =20 >>> Finally, there seems to be an = inconsistent style approach with draft-hardjono-oauth-resource-reg which u= ses ETags. Should this draft do so as well? >>> =20 >>> That's an individual submission, not a working group draft. Nobody has, u= ntil now, even mentioned the use of ETags here. UMA (where the resource regi= stration draft comes from) uses ETags, hence their inclusion there. I person= ally don't see their utility here, though, and I wouldn't want to include a w= holly new mechanism this late. >>> =20 >>> Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn'= t have a point. It's worth discussing.=20 >>> =20 >>> One could argue that the point of an ETag is that it is useful for chang= e detection when there are multiple writers to a particular resource. In th= e design of dynamic registration endpoint, there should only be one writer -= - the client. This is an important observation. >>> =20 >>> There are other mechanisms that handle this -- namely, the registration a= ccess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as descr= ibed in =C2=A74.1.=20 >>> =20 >>> If everyone agrees, I'm in agreement. But it will likely mean changes fo= r the resource reg draft if adopted. >>> =20 >>> ETags seem like an unnecessary addition (and potential complication) to t= he specification. It=E2=80=99s already working fine as-is. >>> =20 >>> Specific items: >>> --------------------- >>> "token_endpoint_auth_method" >>> =20 >>> There is some confusion as to whether this applies to server or client a= uthentication. Suggest renaming parameter to "token_endpoint_client_auth_me= thod" >>> =20 >>> This is the first I've heard of this particular confusion. I'm fine with= either name but at this stage I don't want to make syntax changes without v= ery, very compelling reasons to do so. >>> =20 >>> The question was raised to me by some new developers. It seems obvious t= o us as experienced OAuth persons, but to new developers it seems unclear. A= lso, now that you are introducing registration authentication, the whole thi= ng gets very confusing. So it is useful disambiguate all the parameters wher= e possible. That said, I wouldn't mind shorter names (maybe not quite as sh= ort as the JOSE stuff ;-) >>> =20 >>> Fair enough, but again, I only want to do syntax changes if the rest of t= he WG *really* wants to. >>> =20 >>> I agree with Justin here. I=E2=80=99m fine clarifying the description o= f this parameter to resolve the potential ambiguities that you cite, Phil. I= =E2=80=99m not OK revising the syntax without a compelling reason to do so. >>> =20 >>> * Currently, the API only supports a single value instead of an array. I= f the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it sh= ould not be used. >>> =20 >>> I would rather like this to be an array, personally, and brought it up w= ith the OpenID Connect working group about six months ago. But there it was d= ecided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% posit= ive) that I brought up this very issue in the WG here but didn't receive any= traction on it, so single it remains. >>> =20 >>> I can get behind multiple values. In this case, it changes the meaning o= f the parameter. Instead of the client forcing the server to use a particula= r method, the client is informing the server about what methods it can perfo= rm. This allows the server to assign the appropriate method based on its own= policy. >>>=20 >>> Also note that this field, like all others in =C2=A72, represents two th= ings: the client telling the server "I want to use this value for this field= ", and the server telling the client "this is the value you have for this fi= eld". It's not exactly a negotiation, more like making a polite request to a= n absolute dictator who has the last word anyway. But at least this dictator= is nice enough to tell you what their decision was instead of just decapita= ting you. >>> =20 >>> This is the heart of my objection. This fuzziness is is going to lead to= interop issues. >>> =20 >>> There is no fuzziness that I can see here. It's parallelism between what= goes in to the endpoint and what comes out of it. The semantics for the req= uest and the response are different, and differentiable by the fact that one= is a request and the other is a response.=20 >>> =20 >>> The inter-op issue I would like to point out is that the spec does not c= urrently specify if particular input values are singular or multiple. If an= implementer assumes singular and clients assume multiple, we have issues. >>> =20 >>> The multiple/single discussion above gets to the heart of what I *do* be= lieve is a deficiency in the specification, as it=E2=80=99s currently writte= n. The authors, myself included, have failed to make it 100% clear that dis= covery of Authorization Server functionality is out of scope for this specif= ication. I strongly believe that we need to add a clear statement to this e= ffect in the introduction to the specification. >>> =20 >>> The purpose of the Dynamic Client Registration specification is for the c= lient to register with the Authorization Server and to inform it of properti= es of the client that the AS may want/need to be aware of. It *is not* the p= urpose of this specification for it to be used by clients in any manner to d= iscover features of the Authorization Server. That should be explicitly out= of scope. >>> =20 >>> Currently, clients are instructed by RFC 6749 to discover information ab= out Authorization Servers they interact with by consulting the =E2=80=9Cserv= ice documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2). They can also l= earn information about Authorization Servers in specific contexts through di= scovery protocols such as OpenID Connect Discovery (http://openid.net/specs/= openid-connect-discovery-1_0.html) and UMA Discovery (TBD). >>> =20 >>> I suspect that at some point, someone in the OAuth working group will pr= opose developing a generic OAuth discovery mechanism, which will lead to a r= echartering to include this work in the working group=E2=80=99s set of deliv= erables. I would support doing this work and the necessary rechartering to d= o so. >>> =20 >>> That being said, I strongly oppose trying to shoehorn piecemeal aspects o= f discovery into the Dynamic Client Registration specification. It is disti= nct functionality and deserves first-class and separable treatment by the wo= rking group. Discovery is for potential clients to learn properties of the A= S before registration. Registration is for potential clients to inform the A= S of its properties, creating a registered client. Discovery sends informat= ion about the AS to the Client. Registration sends information about the Cl= ient to the AS. That=E2=80=99s a clean separation. We should strongly resi= st muddying the two functions. >>> =20 >>> OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean. = It specified how to do one thing well in a simple, web-friendly manner. We= should do the same =E2=80=93 focusing on specifying interoperable dynamic c= lient registration, while making it clear that t= his is distinct from discovery about Authorization Server properties, and ma= king it clear that discovery is out of scope for this work. >>> =20 >>> I apologize at this point on behalf of myself and the other spec editors= for not being 100% clear that discovery functionality is explicitly out of s= cope for Dynamic Client Registration. If we had done so, I=E2=80=99m sure t= hat many of the current questions and confusions would not have arisen. I t= hink we=E2=80=99d assumed that this was obvious, but from the current discus= sions, it=E2=80=99s apparent that it=E2=80=99s not obvious. I will personal= ly commit to clarifying the specification at this point = to eliminate this potential point of confusion. >>> =20 >>> Getting back to the specifics, the only useful purpose of a multi-valued= =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member would be to enab= le the client to discover information about the a= uthentication methods supported by the AS after the registration had been pe= rformed. But that is a discovery function, and so should be part of the dis= covery work =E2=80=93 not this specification. We should resist shoehorning i= n bits of discovery into this specification. It *is* a worthwhile topic, bu= t deserves full consideration by the working group in its own right. Theref= ore, this member must remain single-valued, and be clearly specified as the m= ethod by which a client informs the AS which token endpoint authentication m= ethod it will use. Anything else would be scope creep, and result in an unn= ecessarily complicated specification and unnecessarily complicated clients. >>> =20 >>> * There is no authn method for "client_secret_saml" or "private_key_saml= ". >>> =20 >>> Nobody has really asked that these two be included or specified. The ext= ension mechanism (using an absolute URI) would allow someone else to define t= hese. Is the definition in the SAML Assertion draft sufficient for their use= ? >>> =20 >>> I think this is coming from the fact that there is a JWT bearer draft an= d a SAML bearer draft. The truth is you are defining an authentication that= isn't even defined. >>> =20 >>> There are no profiles referenced or defined for "client_secret_jwt" or "= private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover t= hese types of flows. They only cover bearer flows. "client_secret_jwt" and "= private_key_jwt" seem to have some meaning within OpenID Connect, but I note= that OIDC does not fully define these either. >>> =20 >>> The JWT assertion draft does say how to use a JWT for client authenticat= ion, and the DynReg text differentiates between a client signing said JWT wi= th its own secret symmetrically vs. a client using its own private key, asym= metrically. >>> =20 >>> Actually my interpretation is the JWT draft assumes the JWT Bearer is a b= earer token. The assumption is that if a client has the assertion it has th= e right to present it. IOW. The JWT Bearer Draft is most definitively not a= JWT HoK Draft. :-) >>> =20 >>> Regardless, you are introducing a new profile which is undefined. >>> =20 >>> I think I see the point that you're making now, let me try to re-state i= t: >>> =20 >>> While the basics of "how to present a JWT as a client credential" is def= ined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.= section.2.2 , it's not completely specified in that it doesn't fully restric= t the signature secret source, the audience claim, and other things that the= AS would need to check and validate. Right? The dynamic registration draft c= an define those cases in greater detail if needed (though I think it does so= sufficiently as-is, I welcome more clarity). >>> =20 >>> I'd be OK with adding the SAML bit, going into greater detail on the JWT= bits, or dropping the JWT bits, if the WG wants to do any of those actions.= My objection is that the JWT stuff is already in use and functioning and it= 'd be a shame to leave it out. >>> =20 >>> I guess then the mistake the JWT Bearer and SAML Bearer drafts authors m= ade is they assumed everyone had the same definition of bearer token. To me= a bearer token opaque to the client. It therefore cannot do any signature w= ork with regards to the token itself. Now, that's= not to say a proof didn't occur between the client and the token issuer, bu= t when the client wields the token, it is handling an opaque string. >>> =20 >>> The concept of client_secret_jwt suggests an HoK profile. Therefore of c= ourse the bearer drafts are a little underspecified when it comes to HoK pro= files. >>> =20 >>> So for example, you need a draft like the MAC draft for this.=20 >>> =20 >>> I'm having trouble overall here. It seems the authn types suggest ONLY s= trong authentication for clients, yet during the registration process the cu= rrent draft isn't able to correlate multiple instances of the same software (= even in a self-asserted way). If you haven't authenticated the software at a= ll, why have strong client auth? >>> =20 >>> There is no authentication = method defined for "client_bearer_saml" or "client_bearer_jwt" or "client= _bearer_ref". Since the bearer specs say this is acceptable, the dynamic r= egistration spec should accept these. >>> =20 >>> I don't understand this bit -- where are these defined in RFC6750? I don= 't even know what client_bearer_ref would refer to. >>> =20 >>> 6750 says you can use a bearer a= ssertion (e.g. obtained from an IDP) and wield it as an authentication asser= tion. The client is NOT creating or modifying the assertion. The client is s= imply passing one it previously obtained. >>> =20 >>> What you are describing is not b= earer. It is holder of key. Very very different.=20 >>>=20 >>> A possible suggestion is to remove client_secret_jwt and private_key_jwt= and define those as register extensions since these profiles are not define= d. >>> =20 >>> That's possible, but they are in active use already.=20 >>> =20 >>> That may be true. But then you need to write another draft so the rest o= f us can implement it in an interoperable way. Me I prefer not to guess wha= t you are doing. >>> =20 >>> This much I agree with. >>> =20 >>> Justin, John, and I discussed this issue and agree with your suggestion,= Phil. Since they are not completely specified, we will remove the client_s= ecret_jwt and private_key_jwt methods from the specification and add a regis= try, enabling specification that do fully specify these and other token endp= oint authentication methods, including potential methods using SAML assertio= ns, to register them in the registry, rather than trying to bake them into t= he Dynamic Client Registration specification. >>> =20 >>> About "tos_uri" and "policy_uri" >>> =20 >>> The distinction between tos_uri and policy_uri is unclear. Can we clari= fy or combine them? >>> =20 >>> Terms of service and policy are two different documents. One is somethin= g that a user accepts (generally describing what the user will do), one is a= statement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for them= to be split. >>> =20 >>> Several developers were confused by this. In particular they couldn't fi= gure out which was used for what. Just passing along the feedback. >>> =20 >>> OK, the distinction that I see is that the TOS is contractual, the Polic= y is a statement. Re-reading the definitio= ns in there right now, that can be made much clearer. (It even looks like so= me OIDC text leaked into the definition of policy_uri and that hadn't been c= aught yet.) >>> =20 >>> I support clarifying the language on these definitions, and will work wi= th Justin to do so. >>> =20 >>> Also, aren't these really URIs or are they meant to be URLs? >>> =20 >>> There was already discussion about this on the list: The IETF is apparen= tly trying to deprecate URL in favor of URI in new specs. So in practice the= y'll nearly always be URLs, but since all URLs are URIs we're not = technically incorrect in following the new= policy. And it makes the IESG less = mad at us, which is a plus. >>> =20 >>> Arg. Nice. Then the text should say the value passed must resolve to a v= alid web page, document, whatever. >>> =20 >>> That's fair, and it's something that the AS can even check if it wants t= o. >>> =20 >>> Agreed on this clarification. >>> =20 >>> About "jwks_uri" >>> =20 >>> A normative reference for http://tools.ietf.org/html/draft-ietf-jose-jso= n-web-key-09 is needed.=20 >>> =20 >>> Yes, you're correct, I'll add that. >>> =20 >>> Should be URL instead of URI? >>> =20 >>> See above. :) >>> =20 >>> Agreed on adding this reference. >>> =20 >>> Section 2.1 >>> =20 >>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>> is missing. >>> =20 >>> It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80= =A6 ? >>> ' >>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>> =20 >>> Ah, that makes more sense. If the WG wants to add in SAML support to par= allel the JWT support, I'd be OK with that. >>> =20 >>> =E2=80=9CAs such, a server supporting these fields SHOULD take steps to e= nsure that a client cannot register itself into an inconsistent state.=E2=80= =9D >>>=20 >>> We may want to define more detailed HTTP error response. E.g. 400 status= code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)? >>> =20 >>> I'd be fine with defining a more explicit error state in this case. I th= ink it would help interop for the servers that want to enforce grant-type an= d response-type restrictions, but servers that can't or don't care about res= tricting grants types and whatnot don't have to do anything special. >>> =20 >>> I *think* that this goes away with the deletion of client_secret_jwt and= private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a consis= tency check and verify that w= hen the spec is updated accordingly. >>> =20 >>> Section 2.2 >>> =20 >>> May want to add: >>> =20 >>> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of =E2=80=9Cclient_= name#en=E2=80=9D) the OAuth server may use interpret the language used based= on server configuration or heuristics. >>> =20 >>> That seems inconsistent with what we already have: >>> =20 >>> If any human-readable field is sent without a language tag, parties usin= g it MUST NOT make any assumptions about the language, character set, or scr= ipt of the string value, and the string value MUST be used as-is wherever it= is presented in a user in= terface. >>> =20 >>> Which is to say, treat it as a = raw byte-value-string and don't try to get fancy. >>> =20 >>> I will discuss with our developers. I'm not sure the as-is works. =20 >>> =20 >>> Is it the intent that when the client has localized "client_name" for ex= ample, it should pass all language variations in a JSON array? >>> =20 >>> Or, should part of the registration be to indicate which interface langu= age the client wishes to use? Then it only passes a single value for that r= egistration? >>> =20 >>> =20 >>> No, the client should pass parameters as multiple separate values. Conne= ct has this in its example: >>> =20 >>> "client_name": "My Example", >>> "client_name#ja-Jpan-JP": >>> "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", >>> Should we add that to at least one of the examples in DynReg? (The langu= age tags are a late addition, so the examples don't reflect it.) >>> =20 >>> An example would definitely help. >>> If the client passes only a single unadorned field, the AS can't make an= y assumption about what language it is. Think of this as the internationaliz= ed value of the field while the language tags are the localized versions of t= he field. This is why we recommend that the bare-value always be sent by the= client, so that in the lack of anything more specific, the AS can at least d= o *something* with it. >>> =20 >>> Passing in a "default" language field (like default_locale or the like) i= s only going to lead to pain for implementors of both clients and servers, a= nd it's going to hurt the interoperability of the = human-readable fields.=20 >>> =20 >>> I think what I meant is since you are allowing each client to register d= ifferent things, AND the client likely already knows the user's preferred la= nguage, why wouldn't the client just pass text values in one language and an= other parameter indicating preferred language in the case of any service gen= erated text. >>> =20 >>> Is the reason you are passing multiple localizations is so that you can u= se the preferred language of the resource owner rather then the client user?= I wonder if that is correct. If the language preferences are in fact diffe= rent, what would the user of the client app expect? >>> =20 >>> ----> any multi-lingual people have any opinions here? >>> =20 >>> Without specific proposed text changes to review, it=E2=80=99s hard to k= now what to think about this comment. Unless a specific proposed text chang= e is sent to the list with clear rationale for why it=E2=80=99s better than w= hat=E2=80=99s there now and reviewed by the working group, I don=E2=80=99t b= elieve we should change the specification in response to this comment. >>> =20 >>> Section 3 >>> =20 >>> Existing text: >>>=20 >>> =E2=80=9CIn order to support open registration and facilitate wider inte= roperability, the Client Registration Endpoint SHOULD allow initial registra= tion requests with no authentication. These requests MAY be rate-limited or= otherwise limited to prevent a denial-of-service attack on the Client Regis= tration Endpoint.=E2=80=9D >>>=20 >>> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80=9C= MAY=E2=80=9D. In most cloud services, the first client is registered by a h= uman user. Then, other clients can be further used to automate other client r= egistration. So, t= he first request would typically come with an authenticated user identity.=20= >>> =20 >>> I think the weight of "SHOULD" is appropriate here, because I believe th= at turning off open registration at the AS (which is what this is talking ab= out) really ought to be the exce= ption rather than the rule.=20 >>> =20 >>> I think you are reading it wrong -- a double-negative issue. The end of t= he sentence is "no authentication". You are implying that NO Authentication= us what should normally be done. I think you intend anonymous authenticatio= n to be the exception rather than the rule don't you? >>> =20 >>> No, I think that anonymous authentication should be the rule. Open regis= tration should be default.=20 >>> =20 >>> I disagree. Again, the spec seems contradictory. It suggests strong cl= ient auth methods and at the same time anonymous registration. Yes you gain= uniqueness, but that's about it. >>>=20 >>> On the flip side, the earlier paragraph: >>>=20 >>> =E2=80=9CThe 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 pre= viously authorized parties. The method by which this access token is obtaine= d by the registrant is generally out-of-band and is out of scope of this spe= cification.=E2=80=9D >>>=20 >>> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D t= o =E2=80=9CSHOULD=E2=80=9D. >>>=20 >>> That access token would carry a h= uman user authenticated identity somehow. In some cases, it can be a pure au= thenticated user assertion token. >>> =20 >>> Again, disagree, for the same reasoning as above. >>> =20 >>> Same reasoning.=20 >>>=20 >>> I agree with Justin here. The default should be that open registrations= are enabled. The exception case is that specific permissions are required t= o perform dynamic client registration. >>>=20 >>> About section 4.3: >>> =20 >>> If the client does not exist on this server, the server MUST respond >>> with HTTP 401 Unauthorized, and the Registration Access Token used to= >>> make this request SHOULD be immediately revoked. >>> =20 >>> If the Client does not exist on this = server, shouldn't it return a "404 Not Found"? >>>=20 >>> If revoking the registration access token, is it bound to a single clien= t registration? This i= s not clear. What is the lifecycle around registration access token? Only h= int is in the Client Information Response in section 5.1. >>> =20 >>> The language about the 401 here (and in other nearby sections) is specif= ically so that you treat a missing client and a bad registration access toke= n the same way. You see, returning a 404 here actually indicates things were= in an inconsistent state. Namely, that the registration access token was st= ill valid but the client that the registration access token was attached to d= oesn't exist anymore. The registration access token in meant to be tied to a= client's instance (or registration), so it's actually more sensible to act a= s though the registration access token isn't valid anymore. In at least some= implementations (specifically ours at MITRE that's built on SECOAUTH in Jav= a), you'd never be able to reach the 404 state due to consistency checking w= ith the inbound token. >>> =20 >>> Since the intent of the registration = access token is that it's bound to a single instance, its lifecycle is g= enerally tied to the lifecycle begins at the issuance of a new client_id wit= h that instance. That token might be revoked and a new one issued on Read an= d Update requests to the Client Configuration Endpoint (and the client needs= to be prepared for that -- same as the client_secret), and it will be revok= ed when the client is deleted either with a Delete call to the Client Config= uration Endpoint or something happening out-of-band to kill the client.=20 >>> =20 >>> Should we add more explanatory text to the definition in the terminology= section? Elsewhere? I'm very open to concrete suggestions with this, since I= don't think it's as clear as we'd like. >>> =20 >>> I think we should look at it. >>>=20 >>> For security reasons, it=E2=80=99s generally not good to distinguish bet= ween =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors i= n responses, as that can provide the attacker an oracle to probe whether a p= articular entity exists I don=E2=80=99t think a change is called for here. >>>=20 >>> About section 5.1: >>> Is registration_access_token unique? Or is it shared by multiple instan= ces? If shared, then registration_access_token can't be revoked on delete o= f client. >>> =20 >>> The registration_access_token is unique to a registered client, in the R= FC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do work on =E2= =80=9Cclient instances=E2=80=9D, we need to recharter and take this distinct= work item up explicitly. >>>=20 >>> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_ex= pires_at=E2=80=9D,=20 >>>=20 >>> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D >>> =20 >>> While I do like the suggestion of changing these to client_secret_expire= s_at and client_id_issued_at, and I think these are more clear and readable,= >>>=20 >>>=20 >>> I don't want to change the syntax during last call unless there is a cle= ar need and a clear consensus for doing so. >>> =20 >>> That's why we are having last call. To confirm consensus on the draft.=20= >>> =20 >>> Same reasoning as earlier. You now have multiple tokens (registration ac= cess and client) in play. The spec needs to be clear which one it is talking= about. >>> =20 >>> I'm fine with the suggested change but I would like more feedback from o= ther people before moving forward with it. There's a lot of value in "just p= ick a name and ship it" as well though, and I don't = want to devolve into bike shedding. (I'm not accusing you of bike sh= edding quite yet, btw, just afraid of getting into a long debate on names.) >>> =20 >>> Again, this was a problem raised by people new to the specification. The= y found it confusing. I tend to agree. We're not talking about what colour t= o paint the shed. We're talking about whether the bike shed is a house. :-)= =20 >>> =20 >>> I'm not too fussed about whether you call it "cl_sec_expiry" or "client_= secret_expires_at".=20 >>>=20 >>> If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at= =E2=80=9D are unclear, we should clarify them. If you believe that this is t= he case Phil, can you supply proposed alternative definition text that is cl= earer? That being said, I believe that at this point we should stick with t= he existing protocol element names unless overwhelming working group sentime= nt emerges to change them. They are already working fine as-is in productio= n deployments. >>> =20 >>> Section 7 >>> =20 >>> When a client_secret expires is it the intent that clients do an update o= r refresh to get a new client secret? >>> =20 >>> Yes, the client is supposed to either call the read or update methods on= the client configuration endpoint to get its new secret. As discussed above= , I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this. >>> =20 >>> Either is a reasonable behavior on the behalf of clients, depending upon= context. I support adding text to clarify = this. >>> =20 >>> Again, thanks for the very thorough read through. Have you implemented a= ny of the spec yet, either as-is o= r with any of your suggested changes? >>> =20 >>> Yes. Much of the feedback is coming from our development community.=20 >>> =20 >>> Ah, very cool. Developer experience is the most valuable feedback, in my= opinion. If you can't actually build the blasted thing, what good is it? :)= >>> =20 >>> Glad to hear that you=E2=80=99re working with developers building the sp= ec. Please thank them for the feedback. >>> =20 >>> -- Justin >>> =20 >>> Best wishes,= >>> -- Mike >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-F0925781-684C-4B19-A316-7463B277CFBE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Phil

On 2013-05-= 20, at 8:35, Justin Richer <jricher@= mitre.org> wrote:

=20 =20 =20
On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you d= escribe is NOT anonymous but rather a profile not covered by the spec as the= re is no discussion of user authenticated registration. Implicitly or explic= itly. 

=46rom the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disa= gree. This spec fundamentally breaks the old definition and behavior from 67= 49. In the old way every instance of software shared a client_id. In this dr= aft, u throw that away without preserving the information. This is BAD!


A "client" is, conceptua= lly, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
&= lt;ph> but you are breaking other things and overloading client cred etc t= o pass in signed data. I don't want a hack for a solution. I want interop.&n= bsp;

  http://blue-button.github.io/blue-button-plus= -pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
=
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> wh= ere is this stated in charter?


As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as= within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<= ph> Two drafts to do registration is not the way to go. It implies comple= xity where there should be none. There is no technical reason for two drafts= . 

 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks= for the detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 I was pretty fully engaged a= t the European Identity Conference (where OAuth 2.0 won the award for best new standard<= span class=3D"Apple-converted-space"> J).  My feedback on the points raised is inline in green=E2=80=A6<= /o:p>
&= nbsp;
(Perha= ps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth= between Phil and Justin is already very difficult to follow.  Thanks.)
&= nbsp;
From:<= /b> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of&= nbsp;Phil Hunt
Sent:=  Thursday, May 16, 2013 12:54 PM
To:&n= bsp;Richer, Justin P.
Cc:&n= bsp;oauth@ietf.o= rg WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put= together some intro text, etc.
 
Phil
&nb= sp;
@indepen= dentid
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:<= /div>
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com><= o:p>
 wrote:
 <= /div>
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful indeed. 
&nb= sp;
My comments and responses to each point are inline. 
&= nbsp;
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracl= e.com> wrote:
 
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 =
Overa= ll  
-----------=
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.=
 =
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:=
 =
1.  Ho= w is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actuall= y assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 
 = ;
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time= a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.<= /div>
 
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This i= s very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I=E2=80=99m sympathetic to the OA= uth working group eventually doing work on differentiating between instances of an OAuth client, I=E2=80=99ll note that in RFC 67= 49 or RFC 6750 there is no such thing as a client instance.  There are only clients,= which are identified by client_id values. = ; If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We shoul= d not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It=E2=80=99s not= the right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (=C2=A74.2)= to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. = ;
Something like this should be in the draft.=
 
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the registration service?
 
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
 = ;
Something like this should be in the draft.<= /div>
 
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in =C2=A73. I'd welcome suggestions on which bits of this could be made clearer.
 
=
See the discussion on what the registration_access_token is in the thread =E2=80=9CClient Credential Expi= ry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. = ; I will work with Justin to apply these clarifications to the specification. = This may go into the proposed credential management overview section discussed above.
 
=
3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
&= nbsp;
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.=
 = ;
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an= update are clients expected to update /re-register or not?  I'm no= t sure this is a security consideration but more part of the whole change management function dynamic registration supports.
 
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  =
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as= an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it=E2=80=99s inappropriate to d= o so here.  We don=E2=80=99t need to boil the o= cean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that=E2=80=99= s the time for the working group to consider that possibility =E2=80=93 not as part of Dyna= mic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, whe= n is it changed? When is it deleted?
=
 
See the response above above and the definition in =C2=A71.2:&n= bsp;
 
Registratio= n Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.=
 = ;
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
  
Client Regi=
stration Endpoint: The OAuth 2.0 Endpoint through which
                                  
      a Client can request new registratio=
n.  The means of the Client

                                  
      obtaining the URL for this endpoint a=
re out of scope for this

                                  
      specification.
                                  
 

                                  
   o  Client Configuration Endpoint: The OAuth 2.0 E=
ndpoint through

                                  
      which a specific Client can manage i=
ts registration information,

                                  
      provided by the Authorization Server=
 to the Client.  This URL for

                                  
      this endpoint is communicated to the=
 client by the Authorization

                                  
      Server in the Client Information Res=
ponse.

                                  
 

                                  
   o  Registration Access Token: An OAuth 2.0 Bearer=
 Token issued by the

                                  
      Authorization Server through the Cli=
ent Registration Endpoint

                                  
      which is used by the Client to authe=
nticate itself during read,

                                  
      update, and delete operations. =
 This token is associated with a

                                  
      particular Client.=
 
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me i= s I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think= people tend to use as a dictionary rather than as protocol component description.  Maybe the= chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.=
&= nbsp;
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method"= be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 = ;
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the= first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 = ;
I haven't heard a reason justifying this parameter other then "it is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query= all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
&= nbsp;

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a= discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.<= /span>

 
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I=E2=80=99ll work with Ju= stin to make sure that this is as clear as possible in the specification.=
 
Finally, there seems to be an inconsistent style approach with draft-har= djono-oauth-resource-reg which uses ETags. Should this draft do so as well?<= /div>
&= nbsp;
That's= an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 = ;
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. =
 
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design= of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in =C2=A74.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
ETags seem like an unnecessary addition (and potential complication) to the specification.  It=E2=80= =99s already working fine as-is.
 
Specific items:
---------------= ------
"token_endpo= int_auth_method"
 
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter= to "token_endpoint_client_auth_meth= od"
&= nbsp;
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 = ;
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that yo= u are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
=
I agree with Justin here. = ; I=E2=80=99m fine clarifying the descriptio= n of this parameter to resolve the potential ambiguities that you cite, Phil.  I=E2=80=99m not OK revising th= e syntax without a compelling reason to do so.=
 
=
* Currently, the API only supports a single value instead of an array.  If th= e purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
&= nbsp;
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 = ;
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =C2=A72, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.
 = ;
This is the heart of my objection. This fuzziness is is going to lead to interop issues.
 
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it=E2=80=99s currently written= .  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That= should be explicitly out of scope.
 
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the =E2=80=9C= service documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2).  They can also learn= information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-c= onnect-discovery-1_0.html) and UMA Discovery (TBD).
=
 
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group=E2=80=99s set of deliverables.&nbs= p; I would support doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct= functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That=E2=80=99s a clean separation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean.=   It specified how to do one thing well in a simple, web-friendly manner.  We should do the same =E2=80=93 focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I=E2=80=99m sure that many of th= e current questions and confusions would not have arisen.  I think we=E2=80=99d assumed t= hat this was obvious, but from the current discussions, it=E2=80=99s apparent that it=E2=80= =99s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
Getting back to the specifics, the only useful purpose of a multi-valued =E2=80=9Ctoken_endpoint_clie= nt_auth_method=E2=80=9D member would be to enable the client= to discover information about the authentication methods supported by the AS after the registration had been performed. = But that is a discovery function, and so should be part of the discovery work =E2=80=93 n= ot this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile= topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
* There is no authn method for "client_secret_saml" or "private_key_saml".
&= nbsp;
Nobody= has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 = ;
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 =
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" an= d "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.=
 
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.
=
&nb= sp;
Actually= my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption= is that if a client has the assertion it has the right to present it.  IOW. The JWT Beare= r Draft is most definitively not a JWT HoK Draft.  :-)<= /div>
&nb= sp;
Regardle= ss, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:
 
While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draf= t-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.=
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?=
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs= say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
&= nbsp;
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
&nb= sp;
What you are describing is not bearer. It is holder of key. Very very different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.=
 
That's possible, but they are in active use already. 
&= nbsp;
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"<= /div>
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.
&nb= sp;
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Jus= t passing along the feedback.=
 
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.=
 
=
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.=
&nb= sp;
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
=
About "jwks_uri"
 
A normative reference for <= span class=3D"apple-style-span">http://tool= s.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 =
Should be URL instead of URI?=
 
See above. :)
 =
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:= params:oauth:grant-type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80=A6 ?
'
Sorry I meant: urn:= ietf:params:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
=E2=80=9CAs such,= a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (=E2=80=9Cinvalid_client_m= etadata=E2=80=9D)?
 =
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.=
 
I *thi= nk* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6&nbs= p; I=E2=80=99ll do a consistency check and verify that when the spec is updated accordingly.
&nb= sp;
Section 2.2=
 =
May want to add:<= /o:p>
 =
When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en= =E2=80=9D is missing in =E2=80=9Cclient_na= me=E2=80=9D, instead of =E2=80=9Cclient_na= me#en=E2=80=9D) the OAuth server may use interpret the language used based on= server configuration or heuristics.
 =
That seems inconsistent with what we already have:
 =
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.
 =
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.
&nb= sp;
I will discuss with our developers. I'm not sure the as-is works.  <= /o:p>
 = ;
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 = ;
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect has this in its example:
 
   "client_name": "My Example",
                                
   "client_name#ja-Jpan-JP":
                                
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D=
",

                                

                                  
Should we add
                                    that to at least one of the examples
                                    in DynReg? (The language tags are a
                                    late addition, so the examples don't
                                    reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. <= /div>
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it=E2=80=99s hard t= o know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it=E2=80=99s bette= r than what=E2=80=99s there now and reviewed= by the working group, I don=E2=80=99t believe= we should change the specification in response to this comment.
 
=
Section 3=
 
Existing text:

=E2=80=9CIn order to support open registration and facilitate wider interop= erability, the Client Registration Endpoint SHOU= LD allow initial registration = requests with no authentica= tion.  These requests MAY be rate-limit= ed or otherwise limited to prevent a denial-of-service attack on the Client&nb= sp;Registration Endpoint.=E2=80=9D=

I would suggest to change the first =E2=80=9CSHO= ULD=E2=80=9D to =E2=80=9CMAY=E2= =80=9D.   In most cloud services, the first client is registered= by a human user. Then, other clients= can be further used to automate othe= r client registration. = ; So, the first request= would typically come with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. <= /div>
&nb= sp;
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implyin= g that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registration should be default. =
 
I disagree.  Again,  the spec seems contradictor= y. It suggests strong client auth methods and at the same time anonymous registration.  Ye= s you gain uniqueness, but that's about it.=

On the flip side, the earlier paragraph:

=E2= =80=9CThe Client Registration Endpoint MAY accept an i= nitial authorization credential in the form of an OAuth 2.0 [RFC6749] access token in= order to limit registration t= o only previously authorized parties. The method by which this access token is obtained by the registrant is generall= y out-of-band and is out of scope of this specification.=E2=80= =9D

I tend to think it would be better to change this =E2=80=9CMAY=E2= =80=9D to =E2=80=9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity somehow.= In some cases, it can be a pure authenticated user assertion token.
&= nbsp;
Again,= disagree, for the same reasoning as above.
 = ;
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the s=
erver MUST respond
   with HTTP 401 Unauthorized, and the R=
egistration Access Token used to
   make this request SHOULD be immediat=
ely revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
&nb= sp;
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.
&nb= sp;
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. = ;
&nb= sp;
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 = ;
I think we should look at it.

For security reasons, it=E2=80=99s general= ly not good to distinguish between =E2=80=9Cnot found=E2=80=9D and =E2=80= =9Cunauthorized=E2=80=9D errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don=E2=80=99t think a c= hange is called for here.

About section 5.1:
Is registration_access_to= ken unique?  Or is it= shared by multiple instances?   If shared, then registration_access_to= ken can't be revoked on delete of client.
 <= /o:p>
The registration_access_= token is unique to a registered client, in the RFC 6749 sense of =E2=80=9Cclient=E2= =80=9D.  Again, if we want to do work on =E2=80=9Cclient instances=E2=80=9D, w= e need to recharter and take this distinct work item up explicitly.

Suggest rename =E2=80=9Cexpires_at=E2= =80=9D to =E2=80=9Cclient_secret= _expires_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at=E2=80= =9D to =E2=80=9Cid_issued_at=E2= =80=9D
&nb= sp;
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 = ;
That's why we are having last call. To confirm consensus on the draft. =
 
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
 
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_= at=E2=80=9D are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that a= t this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
Section 7=
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 =
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.
 <= /span>
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
 <= /span>
Again,= thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?
 = ;
Yes. Much of the feedback is coming from our development community. <= /div>
 
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you=E2=80=99= re working with developers building the spec.  Please thank them for the feedback.
 
=
 -- Justin<= span style=3D"color: rgb(31, 73, 125); ">
 
=
     =             &nbs= p;            &n= bsp;            =             &nbs= p;    Best wishes,
     =             &nbs= p;            &n= bsp;            =             &nbs= p;    -- Mike




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

=20
= --Apple-Mail-F0925781-684C-4B19-A316-7463B277CFBE-- From jricher@mitre.org Tue May 21 06:46:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6978A21F8F28 for ; Tue, 21 May 2013 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg2uOcxJpfGV for ; Tue, 21 May 2013 06:46:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C721F93BD for ; Tue, 21 May 2013 06:46:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1FEBF1F08CD; Tue, 21 May 2013 09:46:44 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C29D61F0794; Tue, 21 May 2013 09:46:43 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 09:46:42 -0400 Message-ID: <519B7AA5.3070908@mitre.org> Date: Tue, 21 May 2013 09:46:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> In-Reply-To: <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> Content-Type: multipart/alternative; boundary="------------050608060704090607070509" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 13:46:56 -0000 --------------050608060704090607070509 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 05/21/2013 02:01 AM, Phil Hunt wrote: > > > Phil > > On 2013-05-20, at 8:35, Justin Richer > wrote: > >> >> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>> Mike, >>> >>> Rather then embed comments in an extended thread, I'd like to open >>> up a specific discussion on the objective of dyn reg. >>> >>> I see limited to no value in having clients completely anonymously >>> registering and receiving tokens without any ability to correlate >>> applications between applications. >> >> I think that herein lies a very big disconnect in assumptions. I see >> a huge benefit in anonymously registered clients getting tokens >> because there is an end-user in the loop during the authorization >> phase (long after registration has happened). The arity of >> registrations to authorizations approaches 1:1 in these cases, and >> I'm just fine with that. > Then what you describe is NOT anonymous but rather a profile not > covered by the spec as there is no discussion of user authenticated > registration. Implicitly or explicitly. [JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!". The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth. >> >> From the RFC6749 perspective, a "client" is not a particular piece of >> code, it is a particular copy of a piece of code with a particular >> client_id from the vantage point of a particular authorization server. > actually, i disagree. This spec fundamentally breaks the old > definition and behavior from 6749. In the old way every instance of > software shared a client_id. In this draft, u throw that away without > preserving the information. This is BAD! [JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options. Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page. > > >> A "client" is, conceptually, a pairwise association between two >> running codebases. When you have a particular piece of code talking >> only to one auth server and being manually configured at said auth >> server with its client_id, this is fairly clear and straightforward >> and the arity is simple. Things get a bit muddy when you introduce >> dynamic registration, which is why I think that we need to have >> introductory text about this. Specifically: >> >> - a particular piece of code can be run on multiple devices and talk >> to the same auth server, each copy of that code getting its own >> client_id. >> - a particular copy of a particular piece of code can now be >> expected to talk to multiple auth servers, each auth server giving >> the piece of code its own client_id. >> >> Both of these are cases of what defines an "instance" in most >> people's heads, even though it's the same software, even sometimes >> the same running copy of the same software. But as far as RFC6749's >> definition of "client" is concerned, these are all completely >> separate "client"s with no way to tie them together out of the box. >> And that's fine. >> >>> >>> Associating client_id's with known client applications to allow >>> admins to know who is running what version of clients seems to be >>> the most fundamental part of the reason for dynamic reg. How can you >>> revoke access to particular client app types? As Justin already >>> talked about in his Blue Button+ scenario, there are often life and >>> death situations where particular sets of clients need to be revoked. >> While it's very useful, I wouldn't (and haven't) classified it quite >> like that. Nor would I say that the BB+ profile is a complete >> solution -- our Registry component does not actually push revocation >> notifications down to Providers (yet), so it's more like invalidating >> a root certificate and waiting for caches to time out for things to >> cascade. We've been talking about adding some form of callback to >> providers, but we don't want to boil that particular ocean right now. >> However, the BB+ profile makes use of a well-specified discovery and >> Registry set up, as well as data conveyed in structured, signed >> tokens (JWTs) at different points in the process. >> >>> >>> Or put another way. I believe this will be a critical operational >>> requirement going forwards. If the spec is published as is, it will >>> be quickly invalidated by one that does at least partially address >>> the problem. >> That's not true at all. BB+ addresses this scenario and still uses >> the Dynamic Registration spec as-is. I would encourage folks to read >> what we're doing, a work-in-progress found here: > but you are breaking other things and overloading client cred etc > to pass in signed data. I don't want a hack for a solution. I want > interop. [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network. So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them. If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case. >> >> http://blue-button.github.io/blue-button-plus-pull/ >> >> Just because you make something better doesn't mean you throw >> necessarily away everything you've done to date. >> >>> >>> We're ahead of schedule, lets talk through the requirement. >> I believe that the requirement of tying instances together is >> explicitly out of scope for the dynamic registration protocol. I >> intended to have text to that effect in the section I'm adding about >> the client lifecycle. > > where is this stated in charter? [JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this: And dynamic client registration will make it easier to broadly deploy OAuth clients (performing services to users). And: Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case. There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules. >> >>> >>> As I mentioned in my comments to the other thread. Let's say we >>> agree not do this now. Well, then the new draft that does solve it >>> would likely be 95% overlap. Thus I see this issue as within >>> charter and should be solved now rather then waiting for a V2 dyn >>> reg in the next charter. >> Why wouldn't the new draft just be the extra 5%? I personally think >> that it's a lot more than 5% once you have in all the assurance and >> safety mechanisms in place to avoid self-asserted values causing race >> conditions, and what not. > > Two drafts to do registration is not the way to go. It implies > complexity where there should be none. There is no technical reason > for two drafts. [JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today). >> >> -- Justin >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>> >>>> Thanks for the detailed feedback, Phil. Sorry for the delayed >>>> response – I was pretty fully engaged at the European Identity >>>> Conference (whereOAuth 2.0 won the award for best new standard >>>> J). My feedback on the points >>>> raised is inline in green… >>>> (Perhaps if any of you reply to this thread, you could also choose >>>> a distinctcolorfor your inline replies, so that it will be easily >>>> evident who said what. As it is, just the back-and-forth between >>>> Phil and Justin is already very difficult to follow. Thanks.) >>>> *From:*oauth-bounces@ietf.org >>>> [mailto:oauth-bounces@ietf.org]*On >>>> Behalf Of*Phil Hunt >>>> *Sent:*Thursday, May 16, 2013 12:54 PM >>>> *To:*Richer, Justin P. >>>> *Cc:*oauth@ietf.org WG >>>> *Subject:*Re: [OAUTH-WG] Last call review of >>>> draft-ietf-oauth-dyn-reg-10 >>>> Justin, >>>> Thanks for the discussion. More comments below... >>>> BTW. I'm happy to contribute text. Just want to get to some rough >>>> agreement first. For example, I think we need to have a away to >>>> recognize two pieces of software as being the same (even if >>>> self-asserted). Once defined, I can put together some intro text, etc. >>>> Phil >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>>> On May 15, 2013, at 10:30 PM, Phil Hunt >>> > >>>> wrote: >>>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>>> Phil, many thanks for the extremely thorough review! It is very >>>> useful indeed. >>>> My comments and responses to each point are inline. >>>> On May 15, 2013, at 4:30 PM, Phil Hunt >>> > wrote: >>>> It seems unfortunate that I have not gotten a chance to get into >>>> this level of detail much earlier. But then, I guess that's what LC >>>> review is for! My apologies for not getting many of these concerns >>>> to the WG much earlier. >>>> */Overall /* >>>> ----------- >>>> I think dynamic registration is a critical part of the OAuth >>>> framework now that we are starting to consider how individual >>>> client applications should operate when there is one or more >>>> deployments of a particular resource API. We've moved from the >>>> simple use case of a single API provider like Facebook or Flickr >>>> and moved on to standards based, open source based, and commercial >>>> based deployments where there are multiple service endpoints and >>>> many clients to manage. >>>> The dynamic registration spec is actually dealing with a couple of >>>> issues that I would like to see made more clear in early part of >>>> the spec: >>>> 1. How is a new client application recognized for the first time >>>> when deployed against a particular SP endpoint? Should clients >>>> actually assert an application_id UUID that never changes and >>>> possibly a version id that does change with versions? >>>> In the general case, why is any recognition required? If you're >>>> doing things as part of a larger protocol ecosystem, like Blue >>>> Button+ or a particular OpenID Connect provider, then you can >>>> define semantics for tying together classes of clients (see below >>>> for more discussion on this very point). But in general, a client >>>> is just going to show up as a new instance to the AS and get issued >>>> a new, unique client_id, and that's that. >>>> I think we have to define more clearly what an "instance" is. For >>>> me, there are applications and there are instances of that >>>> application. It is useful to understand that a client application >>>> represents a set of code that should behave in a consistent way. >>>> It seems to me the first time a new application shows up is very >>>> different from the subsequent instances that register. For example, >>>> after the first registration, subsequent instances don't need >>>> special review or approval to the same degree. >>>> But without other mechanisms to tie things together, there's no way >>>> for an authorization server to know if any client instance is tied >>>> to any other client instance. Therefore, from the perspective of an >>>> AS, the first instance of an application (i.e., particular >>>> configuration of a set of code) to register is no different to >>>> subsequent instances of that same application. How were you >>>> envisioning an AS knowing the difference between the first and >>>> subsequent instances of an application, specifically? If there's an >>>> "application_id" like you mention above, I think it raises more >>>> questions than it resolves: Who issues the application_id, some >>>> server or the application itself? Is it validated at all? Should it >>>> be considered secret? What happens when someone simply steals an >>>> application_id? Does an AS have to do anything to check with any >>>> other AS to see if the application_id has already been used elsewhere? >>>> I do agree that a discussion of "instance vs. application" would be >>>> helpful in clearing this up, I'll make a note to add text to that >>>> effect. (We had to do something similar for BB+) >>>> I think it is simple enough to at least add a self generated UUID >>>> for the application ID. Though I would allow for cases where the >>>> application ID is assigned when the client developer and the APIs >>>> owner do a formal assignment of application IDs. >>>> In a sense this is just a lower tech way of doing it than what you >>>> described as the initial client credential in Blue Button+ where >>>> you encoded extra claims into the initial app credential. >>>> What the UUID does is link multiple instances of a client app >>>> together as the same "thing" that should have similar >>>> heuristics/behaviours. This is very useful if you want to be able >>>> to revoke access to a set of clients identified by application id >>>> (or a version of that app). >>>> While I’m sympathetic to the OAuth working group eventually doing >>>> work on differentiating between instances of an OAuth client, I’ll >>>> note that in RFC 6749 or RFC 6750 there is no such thing as a >>>> client instance. There are only clients, which are identified by >>>> client_id values. If we want to do work on client instances, we >>>> should recharter to add this new work as a working group >>>> deliverable. We should not try to shoehorn bits and pieces of it >>>> into the Dynamic Registration spec, any more than we should have >>>> tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is >>>> there to register clients as defined in RFC 6749. It’s not the >>>> right place to extend what an OAuth client is in new ways. >>>> >>>> 2. How are client credentials managed. Are we assuming >>>> client credentials have a limited lifetime or rotation policy? >>>> The intent was that client_secret could be rotated, as >>>> indicated by the expires_at member of the response. If a >>>> client's secret expires, it calls the read operation on the >>>> Client Configuration Endpoint (§4.2) to get its new >>>> client_secret. If this is unclear in the current text >>>> (which I suspect it may be after multiple refactorings), >>>> then I welcome suggestions and specific text as to how to >>>> make that clear. >>>> >>>> Something like this should be in the draft. >>>> Should this be up in the introductory text, somewhere else, or >>>> have its own section? >>>> >>>> I'm starting to think credential management is a key part of the >>>> draft. It may be worth introducing a specific section outling the >>>> registration life-cycle, registration access token usage, and >>>> client token usage and bootstrapping. >>>> I think that adding a discussion on this would be fine, as it could >>>> help developers understand the workflow of registering, using, and >>>> updating registered clients. >>>> >>>> How does a client authenticate the first time and subsequent >>>> times to the registration service? >>>> This is a separate question all together, as it does not >>>> involve the client_secret or client_id at all. Rather, the >>>> first time the client shows up to the registration service, it >>>> may either: >>>> - Not authenticate at all (this is the true public, open >>>> registration, and it is recommended that servers do this) >>>> - Authenticate using an OAuth 2.0 token (which ATM means a >>>> bearer token). How the client gets that bearer token and what >>>> the bearer token means to the AS beyond "this client is >>>> authorized to register" is out of scope for the spec, by design. >>>> Subsequent times that the same registered client (by which we >>>> mean the same instance of a client with a particular client_id) >>>> shows up at the registration endpoint (actually, the Client >>>> Configuration Endpoint), it uses its Registration Access Token >>>> that it was issued on initial registration. This is an OAuth >>>> 2.0 Bearer token that is unique to the client instance. >>>> >>>> Something like this should be in the draft. >>>> OK, the definition of the registration access token can be >>>> expanded, but I think that the rest of it is already in there in >>>> §3. I'd welcome suggestions on which bits of this could be made >>>> clearer. >>>> See the discussion on what the registration_access_token is in the >>>> thread “Client Credential Expiry and new Registration Access Token >>>> - draft-ietf-oauth-dyn-reg-10”. I will work with Justin to apply >>>> these clarifications to the specification. This may go into the >>>> proposed credential management overview section discussed above. >>>> >>>> 3. How is versioning of clients managed? Should each new >>>> version of a client require a change in client registration >>>> including possibly changing client_id and authentication >>>> credential? I don't have a strong feeling, but it is >>>> something that implementors should consider. >>>> >>>> This is up to the AS, really, and I don't think that any global >>>> policy would ever fly here. Especially if you consider that the >>>> entire notion of "version" is more fluid these days than it >>>> ever has been. I wouldn't mind adding a discussion in the >>>> security considerations if it merits mentioning though, so that >>>> we can help both client developers and server developers >>>> institute reasonably good policy. >>>> >>>> I guess the issue is that when a client upgrades it may have access >>>> to the old credentials. What is the intent then of registration. >>>> Since you have an update are clients expected to update >>>> /re-register or not? I'm not sure this is a security consideration >>>> but more part of the whole change management function dynamic >>>> registration supports. >>>> If your upgraded version of the client still has access to its old >>>> credentials, why wouldn't it just use those? I don't see a reason >>>> for forcing a re-registration. Nor do I see any way that an AS >>>> would even be able to tell that a client had been upgraded. An >>>> upgraded client always has the *option* of re-registering itself >>>> and getting a new client_id. >>>> I think the concern here is that rotation of client credential is >>>> not something discussed before. Before we put it in the spec we >>>> should consider the reasons for doing it and what problems it solves. >>>> I think this may be just a case of letting people exchange >>>> credentials for whatever reason they feel is appropriate. The >>>> version upgrade thing suggests that when a client is upgraded it >>>> should go to the registration server to "re-register". Depending >>>> on the policy of the server, it may (or may not) receive a new >>>> client_id and/or new credential. >>>> One of the best benefits I can think of is if you discover a >>>> version of a client has a problem, being able to select a group of >>>> clients by software and version is important. Thus if client_id >>>> doesn't trace to a particular software and version, that makes it >>>> hard to do. I think you talked about this as an issue for Blue >>>> Button+ >>>> Again, RFC 6749 defines no client instances or groups of clients, >>>> therefore I believe that it’s inappropriate to do so here. We >>>> don’t need to boil the ocean. If a new charter item is approved to >>>> do work on client instances and protocol elements to use and >>>> express them, that’s the time for the working group to consider >>>> that possibility – not as part of Dynamic Client Registration. >>>> >>>> 4. What is the registration access token? Why is is used? What >>>> is its life-cycle? When is it issued, when is it changed? When >>>> is it deleted? >>>> See the response above above and the definition in §1.2: >>>> >>>> Registration Access Token: An OAuth 2.0 Bearer Token issued >>>> by the Authorization Server through the Client Registration >>>> Endpoint which is used by the Client to authenticate itself >>>> during read, update, and delete operations. This token is >>>> associated with a particular Client. >>>> >>>> If this can be clarified, I welcome text suggestions. >>>> >>>> The latter part of 1.2 didn't seem like terminology but rather >>>> architecture or part of the introduction that describes what the >>>> spec does. The third point doesn't seem to fit with the other two >>>> except to say that the dynamic registration endpoints use their own >>>> access tokens called registration access tokens. >>>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>>> a Client can request new registration. The means of the Client >>>> obtaining the URL for this endpoint are out of scope for this >>>> specification. >>>> >>>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>>> which a specific Client can manage its registration information, >>>> provided by the Authorization Server to the Client. This URL for >>>> this endpoint is communicated to the client by the Authorization >>>> Server in the Client Information Response. >>>> >>>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the >>>> Authorization Server through the Client Registration Endpoint >>>> which is used by the Client to authenticate itself during read, >>>> update, and delete operations. This token is associated with a >>>> particular Client. >>>> This section is meant to just introduce the new terms that are then >>>> explained in greater detail throughout the rest of the document. >>>> Yes, it's a bit architecture, but only in the sense that you need >>>> to define the terms that make up your architecture. How would you >>>> suggest that it change? >>>> Probably this is more a matter of style. But, what happened for me >>>> is I naturally skipped the terminology section, as I wasn't >>>> expecting protocol components to be there. "terminology" is >>>> something I think people tend to use as a dictionary rather than as >>>> protocol component description. Maybe the chairs can advise? >>>> >>>> If we distinguish between first time registration of a >>>> particular client software package, it is possible that >>>> somethings like authentication method can be negotiate in or >>>> out-of-band at that time. Subsequent registrations should only >>>> have parameters for items that could change per deployment >>>> (like tos_uri). I think token_endpoint_auth_method is one >>>> thing that should not be negotiated per instance. >>>> >>>> When subsequent instances register, I have to ask the >>>> question, for example when would things like >>>> "token_endpoint_auth_method" be negotiated or be different >>>> for the same client software? Should not all instances use >>>> the same authentication method. >>>> >>>> I'm confused by this -- as far as the dynamic registration spec >>>> is concerned, all instances are separate from each other. All >>>> parameters change per instance. And instance, you should keep >>>> in mind, is defined as any one copy of the client code >>>> connecting to any new authorization server. That pairing >>>> creates the client_id, and therefore the instance, and >>>> therefore the registration access token, and therefore the >>>> registration itself at a conceptual level. So there is no way >>>> other than per-instance for a client to ask for a particular >>>> token_endpoint_auth_method. Where else would the AS find out >>>> about it? >>>> >>>> We still disagree on this. It is my assertion that clients should >>>> NEVER ask for a particular token auth method. Since it is the AS >>>> that is authenticating the client, then it is the AS's right to set >>>> the authentication policy. The role of dynamic reg endpoint is to >>>> inform the client what it must do. My assumption is that during >>>> the first time a piece of software is registered (the first >>>> instance), there could be some OOB discussion by an administrator >>>> to approve the particular authentication type for the AS in question. >>>> I haven't heard a reason justifying this parameter other then "it >>>> is needed". Why? >>>> The role of the dynamic registration protocol is twofold: half of >>>> that is the server informing the client what it must do. But the >>>> other half is the client informing the server what it *can* do, or >>>> what it *wants* to do. >>>> And again, there's no way to distinguish a first instance from a >>>> subsequent instance unless you're doing something in addition. >>>> Nothing is stopping the same application from registering a new >>>> instance of itself for every single user or every single token that >>>> it wants to get access for. That's complicated and wasteful and not >>>> a great idea, sure, but there's no useful way to prevent that kind >>>> of behavior if you also want open registration of clients. >>>> I think we've discussed how recognizing subsequent instances is >>>> easily done. >>>> As I mentioned in the other thread, if a developer chooses to limit >>>> the capabilities of the client it must do so by looking to the >>>> developer or standard behind the API. Otherwise they are taking >>>> the chance. There's no way a developer can query all the potential >>>> deployers to ask what authn types will you use. As I said, the net >>>> effect in the absence of an API standard dictating what should be >>>> supported, the developer will have to implement all methods. >>>> My point here is that none of this is helped by the client app >>>> saying what it supports. A developer who takes the route of >>>> limiting implementation takes the chance that the server will not >>>> accept. So why negotiate within registration? >>>> >>>> And there's no way other than per-instance for the server to >>>> tell the client which token_endpoint_auth_method to use. All >>>> instances will probably ask for the same >>>> token_endpoint_auth_method from all auth servers they talk to, >>>> right? And each AS will tell each instance that registers with >>>> it to use a particular auth method. There is no way to tie >>>> together different instances across (or within) auth servers >>>> without specifying a significant amount of other machinery. >>>> >>>> Which is not to say that it's not useful in some circumstances >>>> to tie together different instances of the same code across (or >>>> within) auth servers. This is why, with Blue Button+, we >>>> specified a specific token format for the initial access token >>>> that the clients use to call the registration endpoint the >>>> first time, as well as a discovery protocol against a >>>> centralized server that handles pre-registration. All of this >>>> machinery is, in my opinion, a stupendous overkill for the >>>> general case, though if some folks find use for it outside of >>>> BB+ then it'd be a good thing to abstract out and make its own >>>> spec that extends the Dyn Reg spec in a fully compatible way. >>>> Furthermore, even in Blue Button+ we specify that all auth >>>> servers MUST also accept open registration, without an initial >>>> access token, where the client simply shows up and says "hey, >>>> here are my parameters." The auth server has no way to know in >>>> this case any kind of out-of-band negotiation for different >>>> things. In BB+ we are writing very specific policy guidelines >>>> about how to present the UX and things to the end user for all >>>> of these different cases. But again, all of this is specific to >>>> the BB+ use case, and I don't see value in dragging it in to >>>> the registration spec on its own. I believe it would be far too >>>> limiting. >>>> >>>> See my previous comments on differentiating client instances >>>> being out of scope without rechartering to do this new work and >>>> on what the registration_access_token is. In short, the >>>> registration_access_token is an RFC 6750 bearer token issued to >>>> the party registering the client, enabling it to subsequently >>>> retrieve information about the client registration and to >>>> potentially update the registration information for that >>>> registered client. Again, I’ll work with Justin to make sure >>>> that this is as clear as possible in the specification. >>>> >>>> Finally, there seems to be an inconsistent style approach with >>>> draft-hardjono-oauth-resource-reg >>>> which >>>> uses ETags. Should this draft do so as well? >>>> That's an individual submission, not a working group draft. >>>> Nobody has, until now, even mentioned the use of ETags here. >>>> UMA (where the resource registration draft comes from) uses >>>> ETags, hence their inclusion there. I personally don't see >>>> their utility here, though, and I wouldn't want to include a >>>> wholly new mechanism this late. >>>> >>>> Yes. Thomas' draft is not a WG document. But that doesn't mean he >>>> doesn't have a point. It's worth discussing. >>>> One could argue that the point of an ETag is that it is useful for >>>> change detection when there are multiple writers to a particular >>>> resource. In the design of dynamic registration endpoint, there >>>> should only be one writer -- the client. This is an important >>>> observation. >>>> There are other mechanisms that handle this -- namely, the >>>> registration access token and the client_id. Many instances include >>>> the client_id in some form in the client configuration endpoint's >>>> URL for sanity checking, as described in §4.1. >>>> If everyone agrees, I'm in agreement. But it will likely mean >>>> changes for the resource reg draft if adopted. >>>> ETags seem like an unnecessary addition (and potential >>>> complication) to the specification. It’s already working fine as-is. >>>> >>>> */Specific items:/* >>>> --------------------- >>>> *"token_endpoint_auth_method"* >>>> There is some confusion as to whether this applies to server or >>>> client authentication. Suggest renaming parameter to >>>> "token_endpoint_client_auth_method" >>>> This is the first I've heard of this particular confusion. I'm >>>> fine with either name but at this stage I don't want to make >>>> syntax changes without very, very compelling reasons to do so. >>>> >>>> The question was raised to me by some new developers. It seems >>>> obvious to us as experienced OAuth persons, but to new developers >>>> it seems unclear. Also, now that you are introducing registration >>>> authentication, the whole thing gets very confusing. So it is >>>> useful disambiguate all the parameters where possible. That said, >>>> I wouldn't mind shorter names (maybe not quite as short as the JOSE >>>> stuff ;-) >>>> Fair enough, but again, I only want to do syntax changes if the >>>> rest of the WG *really* wants to. >>>> I agree with Justin here. I’m fine clarifying the description of >>>> this parameter to resolve the potential ambiguities that you cite, >>>> Phil. I’m not OK revising the syntax without a compelling reason >>>> to do so. >>>> >>>> * Currently, the API only supports a single value instead of an >>>> array. If the purpose is to allow the client to know what auth >>>> methods it supports, this should be an array indicated what >>>> methods the client supports - or it should not be used. >>>> I would rather like this to be an array, personally, and >>>> brought it up with the OpenID Connect working group about six >>>> months ago. But there it was decided that a single value was >>>> simpler and sufficient for the purpose. The IETF draft has >>>> inherited this decision. I *believe* (though am not 100% >>>> positive) that I brought up this very issue in the WG here but >>>> didn't receive any traction on it, so single it remains. >>>> >>>> I can get behind multiple values. In this case, it changes the >>>> meaning of the parameter. Instead of the client forcing the server >>>> to use a particular method, the client is informing the server >>>> about what methods it can perform. This allows the server to assign >>>> the appropriate method based on its own policy. >>>> >>>> Also note that this field, like all others in §2, represents two >>>> things: the client telling the server "I want to use this value for >>>> this field", and the server telling the client "this is the value >>>> you have for this field". It's not exactly a negotiation, more like >>>> making a polite request to an absolute dictator who has the last >>>> word anyway. But at least this dictator is nice enough to tell you >>>> what their decision was instead of just decapitating you. >>>> This is the heart of my objection. This fuzziness is is going to >>>> lead to interop issues. >>>> There is no fuzziness that I can see here. It's parallelism between >>>> what goes in to the endpoint and what comes out of it. The >>>> semantics for the request and the response are different, and >>>> differentiable by the fact that one is a request and the other is a >>>> response. >>>> The inter-op issue I would like to point out is that the spec does >>>> not currently specify if particular input values are singular or >>>> multiple. If an implementer assumes singular and clients assume >>>> multiple, we have issues. >>>> The multiple/single discussion above gets to the heart of what I >>>> **do** believe is a deficiency in the specification, as it’s >>>> currently written. The authors, myself included, have failed to >>>> make it 100% clear that discovery of Authorization Server >>>> functionality is out of scope for this specification. I strongly >>>> believe that we need to add a clear statement to this effect in the >>>> introduction to the specification. >>>> The purpose of the Dynamic Client Registration specification is for >>>> the client to register with the Authorization Server and to inform >>>> it of properties of the client that the AS may want/need to be >>>> aware of. It **is not** the purpose of this specification for it >>>> to be used by clients in any manner to discover features of the >>>> Authorization Server. That should be explicitly out of scope. >>>> Currently, clients are instructed by RFC 6749 to discover >>>> information about Authorization Servers they interact with by >>>> consulting the “service documentation” (RFC 6749, Sections 3.1 and >>>> 3.2). They can also learn information about Authorization Servers >>>> in specific contexts through discovery protocols such as OpenID >>>> Connect Discovery >>>> (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA >>>> Discovery (TBD). >>>> I suspect that at some point, someone in the OAuth working group >>>> will propose developing a generic OAuth discovery mechanism, which >>>> will lead to a rechartering to include this work in the working >>>> group’s set of deliverables. I would support doing this work and >>>> the necessary rechartering to do so. >>>> That being said, I strongly oppose trying to shoehorn piecemeal >>>> aspects of discovery into the Dynamic Client Registration >>>> specification. It is distinct functionality and deserves >>>> first-class and separable treatment by the working group. >>>> Discovery is for potential clients to learn properties of the AS >>>> before registration. Registration is for potential clients to >>>> inform the AS of its properties, creating a registered client. >>>> Discovery sends information about the AS to the Client. >>>> Registration sends information about the Client to the AS. That’s >>>> a clean separation. We should strongly resist muddying the two >>>> functions. >>>> OAuth 2.0 is a success because it didn’t try to boil the ocean. It >>>> specified how to do one thing well in a simple, web-friendly >>>> manner. We should do the same – focusing on specifying >>>> interoperable dynamic client registration, while making it clear >>>> that this is distinct from discovery about Authorization Server >>>> properties, and making it clear that discovery is out of scope for >>>> this work. >>>> I apologize at this point on behalf of myself and the other spec >>>> editors for not being 100% clear that discovery functionality is >>>> explicitly out of scope for Dynamic Client Registration. If we had >>>> done so, I’m sure that many of the current questions and confusions >>>> would not have arisen. I think we’d assumed that this was obvious, >>>> but from the current discussions, it’s apparent that it’s not >>>> obvious. I will personally commit to clarifying the specification >>>> at this point to eliminate this potential point of confusion. >>>> Getting back to the specifics, the only useful purpose of a >>>> multi-valued “token_endpoint_client_auth_method” member would be to >>>> enable the client to discover information about the authentication >>>> methods supported by the AS after the registration had been >>>> performed. But that is a discovery function, and so should be part >>>> of the discovery work – not this specification. We should resist >>>> shoehorning in bits of discovery into this specification. It >>>> **is** a worthwhile topic, but deserves full consideration by the >>>> working group in its own right. Therefore, this member must remain >>>> single-valued, and be clearly specified as the method by which a >>>> client informs the AS which token endpoint authentication method it >>>> will use. Anything else would be scope creep, and result in an >>>> unnecessarily complicated specification and unnecessarily >>>> complicated clients. >>>> >>>> * There is no authn method for "client_secret_saml" or >>>> "private_key_saml". >>>> Nobody has really asked that these two be included or >>>> specified. The extension mechanism (using an absolute URI) >>>> would allow someone else to define these. Is the definition in >>>> the SAML Assertion draft sufficient for their use? >>>> >>>> I think this is coming from the fact that there is a JWT bearer >>>> draft and a SAML bearer draft. The truth is you are defining an >>>> authentication that isn't even defined. >>>> >>>> /There are no profiles referenced or defined for >>>> "client_secret_jwt" or "private_key_jwt". Neither of the >>>> JWT or SAML Bearer drafts referenced cover these types of >>>> flows. They only cover bearer flows. "client_secret_jwt" >>>> and "private_key_jwt" seem to have some meaning within >>>> OpenID Connect, but I note that OIDC does not fully define >>>> these either./ >>>> The JWT assertion draft does say how to use a JWT for >>>> client authentication, and the DynReg text differentiates >>>> between a client signing said JWT with its own secret >>>> symmetrically vs. a client using its own private key, >>>> asymmetrically. >>>> >>>> Actually my interpretation is the JWT draft assumes the JWT >>>> Bearer is a bearer token. The assumption is that if a client >>>> has the assertion it has the right to present it. IOW. The JWT >>>> Bearer Draft is most definitively not a JWT HoK Draft. :-) >>>> Regardless, you are introducing a new profile which is undefined. >>>> >>>> I think I see the point that you're making now, let me try to >>>> re-state it: >>>> While the basics of "how to present a JWT as a client credential" >>>> is defined here: >>>> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, >>>> it's not completely specified in that it doesn't fully restrict the >>>> signature secret source, the audience claim, and other things that >>>> the AS would need to check and validate. Right? The dynamic >>>> registration draft can define those cases in greater detail if >>>> needed (though I think it does so sufficiently as-is, I welcome >>>> more clarity). >>>> I'd be OK with adding the SAML bit, going into greater detail on >>>> the JWT bits, or dropping the JWT bits, if the WG wants to do any >>>> of those actions. My objection is that the JWT stuff is already in >>>> use and functioning and it'd be a shame to leave it out. >>>> I guess then the mistake the JWT Bearer and SAML Bearer drafts >>>> authors made is they assumed everyone had the same definition of >>>> bearer token. To me a bearer token opaque to the client. It >>>> therefore cannot do any signature work with regards to the token >>>> itself. Now, that's not to say a proof didn't occur between the >>>> client and the token issuer, but when the client wields the token, >>>> it is handling an opaque string. >>>> The concept of client_secret_jwt suggests an HoK profile. >>>> Therefore of course the bearer drafts are a little underspecified >>>> when it comes to HoK profiles. >>>> So for example, you need a draft like the MAC draft for this. >>>> I'm having trouble overall here. It seems the authn types suggest >>>> ONLY strong authentication for clients, yet during the registration >>>> process the current draft isn't able to correlate multiple >>>> instances of the same software (even in a self-asserted way). If >>>> you haven't authenticated the software at all, why have strong >>>> client auth? >>>> >>>> There is no authentication method defined for >>>> "client_bearer_saml" or "client_bearer_jwt" or >>>> "client_bearer_ref". Since the bearer specs say this >>>> is acceptable, the dynamic registration spec should >>>> accept these. >>>> I don't understand this bit -- where are these defined >>>> in RFC6750? I don't even know what client_bearer_ref >>>> would refer to. >>>> >>>> 6750 says you can use a bearer assertion (e.g. obtained >>>> from an IDP) and wield it as an authentication assertion. >>>> The client is NOT creating or modifying the assertion. The >>>> client is simply passing one it previously obtained. >>>> What you are describing is not bearer. It is holder of key. >>>> Very very different. >>>> >>>> A possible suggestion is to remove client_secret_jwt and >>>> private_key_jwt and define those as register extensions >>>> since these profiles are not defined. >>>> That's possible, but they are in active use already. >>>> That may be true. But then you need to write another draft >>>> so the rest of us can implement it in an interoperable way. >>>> Me I prefer not to guess what you are doing. >>>> >>>> This much I agree with. >>>> Justin, John, and I discussed this issue and agree with your >>>> suggestion, Phil. Since they are not completely specified, we >>>> will remove the client_secret_jwt and private_key_jwt methods >>>> from the specification and add a registry, enabling >>>> specification that do fully specify these and other token >>>> endpoint authentication methods, including potential methods >>>> using SAML assertions, to register them in the registry, rather >>>> than trying to bake them into the Dynamic Client Registration >>>> specification. >>>> >>>> *About "tos_uri" and "policy_uri"* >>>> The distinction between tos_uri and policy_uri is unclear. >>>> Can we clarify or combine them? >>>> Terms of service and policy are two different documents. >>>> One is something that a user accepts (generally describing >>>> what the user will do), one is a statement of what the >>>> service provider (in this case, the client) will do. More >>>> importantly, we used to have only one, and several people >>>> asked for them to be split. >>>> >>>> Several developers were confused by this. In particular they >>>> couldn't figure out which was used for what. Just passing >>>> along the feedback. >>>> OK, the distinction that I see is that the TOS is contractual, >>>> the Policy is a statement. Re-reading the definitions in there >>>> right now, that can be made much clearer. (It even looks like >>>> some OIDC text leaked into the definition of policy_uri and >>>> that hadn't been caught yet.) >>>> I support clarifying the language on these definitions, and >>>> will work with Justin to do so. >>>> >>>> Also, aren't these really URIs or are they meant to be URLs? >>>> There was already discussion about this on the list: The >>>> IETF is apparently trying to deprecate URL in favor of URI >>>> in new specs. So in practice they'll nearly always be URLs, >>>> but since all URLs are URIs we're not technically incorrect >>>> in following the new policy. And it makes the IESG less mad >>>> at us, which is a plus. >>>> >>>> Arg. Nice. Then the text should say the value passed must >>>> resolve to a valid web page, document, whatever. >>>> That's fair, and it's something that the AS can even check if >>>> it wants to. >>>> Agreed on this clarification. >>>> >>>> *About "jwks_uri"* >>>> A normative reference for >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is >>>> needed. >>>> Yes, you're correct, I'll add that. >>>> Should be URL instead of URI? >>>> See above. :) >>>> Agreed on adding this reference. >>>> *Section 2.1* >>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>> is missing. >>>> It's there in the copy of -10 I'm reading off ofietf.org >>>> right now … ? >>>> >>>> ' >>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>>> Ah, that makes more sense. If the WG wants to add in SAML >>>> support to parallel the JWT support, I'd be OK with that. >>>> >>>> “As such, a server supporting these fields SHOULD take >>>> steps to ensure that a client cannot register itself into >>>> an inconsistent state.” >>>> >>>> We may want to define more detailed HTTP error >>>> response. E.g. 400 status code + defined error code >>>> (“invalid_client_metadata”)? >>>> I'd be fine with defining a more explicit error state in >>>> this case. I think it would help interop for the servers >>>> that want to enforce grant-type and response-type >>>> restrictions, but servers that can't or don't care about >>>> restricting grants types and whatnot don't have to do >>>> anything special. >>>> I **think** that this goes away with the deletion of >>>> client_secret_jwt and private_key_jwt in favor of the >>>> registry… I’ll do a consistency check and verify that when >>>> the spec is updated accordingly. >>>> *Section 2.2* >>>> May want to add: >>>> When “#” language tag is missing, (e.g. “#en” is missing in >>>> “client_name”, instead of “client_name#en”) the OAuth >>>> server may use interpret the language used based on server >>>> configuration or heuristics. >>>> That seems inconsistent with what we already have: >>>> >>>> If any human-readable field is sent without a language >>>> tag, parties using it MUST NOT make any assumptions >>>> about the language, character set, or script of the >>>> string value, and the string value MUST be used as-is >>>> wherever it is presented in a user interface. >>>> >>>> Which is to say, treat it as a raw byte-value-string and >>>> don't try to get fancy. >>>> >>>> I will discuss with our developers. I'm not sure the as-is works. >>>> Is it the intent that when the client has localized >>>> "client_name" for example, it should pass all language >>>> variations in a JSON array? >>>> Or, should part of the registration be to indicate which >>>> interface language the client wishes to use? Then it only >>>> passes a single value for that registration? >>>> No, the client should pass parameters as multiple separate >>>> values. Connect has this in its example: >>>> >>>> "client_name": "My Example", >>>> >>>> "client_name#ja-Jpan-JP": >>>> >>>> "クライアント名", >>>> >>>> Should we add that to at least one of the examples in DynReg? >>>> (The language tags are a late addition, so the examples don't >>>> reflect it.) >>>> >>>> An example would definitely help. >>>> >>>> If the client passes only a single unadorned field, the AS >>>> can't make any assumption about what language it is. Think of >>>> this as the internationalized value of the field while the >>>> language tags are the localized versions of the field. This is >>>> why we recommend that the bare-value always be sent by the >>>> client, so that in the lack of anything more specific, the AS >>>> can at least do *something* with it. >>>> Passing in a "default" language field (like default_locale or >>>> the like) is only going to lead to pain for implementors of >>>> both clients and servers, and it's going to hurt the >>>> interoperability of the human-readable fields. >>>> >>>> I think what I meant is since you are allowing each client to >>>> register different things, AND the client likely already knows the >>>> user's preferred language, why wouldn't the client just pass text >>>> values in one language and another parameter indicating preferred >>>> language in the case of any service generated text. >>>> Is the reason you are passing multiple localizations is so that you >>>> can use the preferred language of the resource owner rather then >>>> the client user? I wonder if that is correct. If the language >>>> preferences are in fact different, what would the user of the >>>> client app expect? >>>> ----> any multi-lingual people have any opinions here? >>>> >>>> Without specific proposed text changes to review, it’s hard to >>>> know what to think about this comment. Unless a specific >>>> proposed text change is sent to the list with clear rationale >>>> for why it’s better than what’s there now and reviewed by the >>>> working group, I don’t believe we should change the >>>> specification in response to this comment. >>>> >>>> *Section 3* >>>> Existing text: >>>> >>>> “In order to support open registration and facilitate >>>> wider interoperability, the Client Registration >>>> Endpoint SHOULD allow initial registration requests with >>>> no authentication. These requests MAY be rate-limited or >>>> otherwise limited to prevent a denial-of-service attack on >>>> the Client Registration Endpoint.” >>>> >>>> I would suggest to change the first “SHOULD” to “MAY”. In >>>> most cloud services, the first client is registered by a >>>> human user. Then, other clients can be further used to >>>> automate other client registration. So, the first request >>>> would typically come with an authenticated user identity. >>>> I think the weight of "SHOULD" is appropriate here, because >>>> I believe that turning off open registration at the AS >>>> (which is what this is talking about) really ought to be >>>> the exception rather than the rule. >>>> >>>> I think you are reading it wrong -- a double-negative issue. >>>> The end of the sentence is "no authentication". You are >>>> implying that NO Authentication us what should normally be >>>> done. I think you intend anonymous authentication to be the >>>> exception rather than the rule don't you? >>>> No, I think that anonymous authentication should be the rule. >>>> Open registration should be default. >>>> >>>> I disagree. Again, the spec seems contradictory. It suggests >>>> strong client auth methods and at the same time anonymous >>>> registration. Yes you gain uniqueness, but that's about it. >>>> >>>> >>>> On the flip side, the earlier paragraph: >>>> >>>> “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.” >>>> >>>> I tend to think it would be better to change this “MAY” to >>>> “SHOULD”. >>>> >>>> That access token would carry a human user >>>> authenticated identity somehow. In some cases, it can be a pure >>>> authenticated user assertion token. >>>> Again, disagree, for the same reasoning as above. >>>> >>>> Same reasoning. >>>> >>>> I agree with Justin here. The default should be that open >>>> registrations are enabled. The exception case is that specific >>>> permissions are required to perform dynamic client registration. >>>> >>>> *About section 4.3:* >>>> If the client does not exist on this server, the server MUST respond >>>> with HTTP 401 Unauthorized, and the Registration Access Token used to >>>> make this request SHOULD be immediately revoked. >>>> If the Client does not exist on this server, shouldn't it return a >>>> "404 Not Found"? >>>> >>>> If revoking the registration access token, is it bound to a single >>>> client registration? This is not clear. What is the lifecycle >>>> around registration access token? Only hint is in the Client >>>> Information Response in section 5.1. >>>> The language about the 401 here (and in other nearby sections) is >>>> specifically so that you treat a missing client and a bad >>>> registration access token the same way. You see, returning a 404 >>>> here actually indicates things were in an inconsistent state. >>>> Namely, that the registration access token was still valid but the >>>> client that the registration access token was attached to doesn't >>>> exist anymore. The registration access token in meant to be tied to >>>> a client's instance (or registration), so it's actually more >>>> sensible to act as though the registration access token isn't valid >>>> anymore. In at least some implementations (specifically ours at >>>> MITRE that's built on SECOAUTH in Java), you'd never be able to >>>> reach the 404 state due to consistency checking with the inbound token. >>>> Since the intent of the registration access token is that it's >>>> bound to a single instance, its lifecycle is generally tied to the >>>> lifecycle begins at the issuance of a new client_id with that >>>> instance. That token might be revoked and a new one issued on Read >>>> and Update requests to the Client Configuration Endpoint (and the >>>> client needs to be prepared for that -- same as the client_secret), >>>> and it will be revoked when the client is deleted either with a >>>> Delete call to the Client Configuration Endpoint or something >>>> happening out-of-band to kill the client. >>>> Should we add more explanatory text to the definition in the >>>> terminology section? Elsewhere? I'm very open to concrete >>>> suggestions with this, since I don't think it's as clear as we'd like. >>>> I think we should look at it. >>>> >>>> For security reasons, it’s generally not good to distinguish >>>> between “not found” and “unauthorized” errors in responses, as that >>>> can provide the attacker an oracle to probe whether a particular >>>> entity exists I don’t think a change is called for here. >>>> >>>> *About section 5.1:* >>>> Is registration_access_token unique? Or is it shared by multiple >>>> instances? If shared, then registration_access_token can't be >>>> revoked on delete of client. >>>> The registration_access_token is unique to a registered client, in >>>> the RFC 6749 sense of “client”. Again, if we want to do work on >>>> “client instances”, we need to recharter and take this distinct >>>> work item up explicitly. >>>> >>>> Suggest rename “expires_at” to “client_secret_expires_at”, >>>> >>>> Suggest to rename “issued_at” to “id_issued_at” >>>> While I do like the suggestion of changing these to >>>> client_secret_expires_at and client_id_issued_at, and I think these >>>> are more clear and readable, >>>> >>>> >>>> I don't want to change the syntax during last call unless there is >>>> a clear need and a clear consensus for doing so. >>>> That's why we are having last call. To confirm consensus on the draft. >>>> Same reasoning as earlier. You now have multiple tokens >>>> (registration access and client) in play. The spec needs to be >>>> clear which one it is talking about. >>>> I'm fine with the suggested change but I would like more feedback >>>> from other people before moving forward with it. There's a lot of >>>> value in "just pick a name and ship it" as well though, and I don't >>>> want to devolve into bike shedding. (I'm not accusing you of bike >>>> shedding quite yet, btw, just afraid of getting into a long debate >>>> on names.) >>>> Again, this was a problem raised by people new to the >>>> specification. They found it confusing. I tend to agree. We're not >>>> talking about what colour to paint the shed. We're talking about >>>> whether the bike shed is a house. :-) >>>> I'm not too fussed about whether you call it "cl_sec_expiry" or >>>> "client_secret_expires_at". >>>> >>>> If the definitions of “expires_at” or “issued_at” are unclear, we >>>> should clarify them. If you believe that this is the case Phil, >>>> can you supply proposed alternative definition text that is >>>> clearer? That being said, I believe that at this point we should >>>> stick with the existing protocol element names unless overwhelming >>>> working group sentiment emerges to change them. They are already >>>> working fine as-is in production deployments. >>>> >>>> *Section 7* >>>> When a client_secret expires is it the intent that clients do >>>> an update or refresh to get a new client secret? >>>> Yes, the client is supposed to either call the read or update >>>> methods on the client configuration endpoint to get its new >>>> secret. As discussed above, I'm not sure that's as clear as it >>>> needs to be, and I welcome suggestions on how to clarify this. >>>> Either is a reasonable behavior on the behalf of clients, >>>> depending upon context. I support adding text to clarify this. >>>> Again, thanks for the very thorough read through. Have you >>>> implemented any of the spec yet, either as-is or with any of >>>> your suggested changes? >>>> >>>> Yes. Much of the feedback is coming from our development community. >>>> Ah, very cool. Developer experience is the most valuable feedback, >>>> in my opinion. If you can't actually build the blasted thing, what >>>> good is it? :) >>>> Glad to hear that you’re working with developers building the >>>> spec. Please thank them for the feedback. >>>> -- Justin >>>> Best wishes, >>>> -- Mike >>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> --------------050608060704090607070509 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case.


  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:

And dynamic client registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case.

There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.
[JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…
 
(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.
 
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the registration service?
 
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.
 
3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.
 
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?
 
See the response above above and the definition in §1.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.
 
   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.
 
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.
 
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
* There is no authn method for "client_secret_saml" or "private_key_saml".
 
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.
 
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:
 
While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.
 
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant-type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect has this in its example:
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.
 
Section 3
 
Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.
 
The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. 
 
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
 
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.
 
 -- Justin
 
                                                            Best wishes,
                                                            -- Mike




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


--------------050608060704090607070509-- From jricher@mitre.org Tue May 21 06:52:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCD621F85E0 for ; Tue, 21 May 2013 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4ANgMl4juTQ for ; Tue, 21 May 2013 06:52:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C427E21F9715 for ; Tue, 21 May 2013 06:52:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3DA781F076A; Tue, 21 May 2013 09:52:05 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 22EBC1F091E; Tue, 21 May 2013 09:52:05 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 09:52:04 -0400 Message-ID: <519B7BE7.1090501@mitre.org> Date: Tue, 21 May 2013 09:51:35 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Bradley References: <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com> <519A4512.9080905@mitre.org> <17A3EEC1-AA53-44F4-AC17-58DA46D8AF6D@oracle.com> <51E8ECDF-9EFE-4E40-A5CD-DDBF4966AD65@ve7jtb.com> In-Reply-To: <51E8ECDF-9EFE-4E40-A5CD-DDBF4966AD65@ve7jtb.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 13:52:24 -0000 John, what you've described is more or less manual registration as it stands today. But with Dynamic Registration and an open registration endpoint, a smartphone client (for instance) actually *can* be a confidential client now. It can store runtime secrets, and can therefore protect a client_secret and a registration_access_token. It would just be the case that each copy would register itself and therefore get its own client_id (and client_secret) and not be directly tied to other instances. This is the case that Phil is having trouble with, I believe. Phil would like to see a mechanism for tying together all of these copies of the client at each AS. And I agree with John's statement below: in order to tie together multiple instances, you *can* use the initial authorization to the registration endpoint (which is in turn tied back to a developer), but that requires much more specification in order to make it usable and secure. -- Justin On 05/20/2013 10:51 PM, John Bradley wrote: > Dynamic registration provides: > 1 A client_id > 2 (Optionally) a client secret that is used at the token endpoint per OAuth. to authenticate the associated client_id > 3 a URI that can be used to update the client_id (this is a REST concept and may be thought of as a instance of client_id rather than the generic registration URI that takes a POST to create a client instance and assign it a resource identifier (registration_client_uri) , Name (client_id) , client_secret and registration_access_token(access the new resource) . From the API point of view this is a new new resource that is a instance of client and NOT a new instance of a particular client. > 4 a registration_access_token used by a developer or client to access the new resource via registration_client_uri. > > So we are being more REST like than OAuth and that may be confusing some developers. Mike and I had concerns about that, but I think creating a specific resource for each client_id is likely the correct thing in the long term. > > One slightly slipper part of this is that in some cases it may be the client that is using this and in others it may be a developer. > > Lets not forget one of the main current uses of OAuth in Phone apps. These are not confidential clients even if they are using the code flow. > > Typically a developer would use the dynamic registration API to create a client at the AS. They would then take the client_id and bake that into there distributed code. (this is super common now) > > They would not get a client_secret and hold on to the registration_client_uri and registration_access_token to be able to update settings for the deployed client instances and to be able to revoke them possibly at some point in the future. All client instances have the same client_id and client_secret (some people like to use it even if it is not a real secret), the AS has no way to differentiate between client instances. Perhaps that is a bad thing but that is OAuth. We are not going to change the fundamental logic of OAuth in registration. > > One thing we did leave room for in the spec was building something on top of Dynamic registration using a bearer token provided out of band to the developer. > That token might constrain or provide defaults for clients registered with it. This however needs to be defined as a part of another spec. We discussed possibilities for dynamically creating client_id and secrets for native apps so that a code generated form phone A could not be intercepted by an attacker and used to get a access/refresh token. > > This is perhaps instance management from a high level but still conforming OAuth from the perspective of the AS and the flows. > > Looking at the wording we may not be doing a good enough job describing that out of access token provisioned out of band for use at the dynamic client registration endpoint which is described as "OAuth 2.0 [RFC6749] access token" in Sec 3 as opposed to registration_access_token which is used in Sec 4.2, 4.3, and 4.4 to access the "Client Configuration Endpoint". > > > John B. > > > > > On 2013-05-20, at 12:36 PM, Phil Hunt wrote: > >> >> Phil >> >> On 2013-05-20, at 8:45, Justin Richer wrote: >> >>> On 05/17/2013 07:29 PM, Phil Hunt wrote: >>>> He's saying every client gets a registration token and a client token. >>> What's a "client token", exactly? There are three potential places for OAuth tokens in and around dynamic registration, and none of them are called "client token". >> i meant client credential. Client token is obviously a type of client cred. >>> 1) The registration access token, which binds a "client" (or "instance of a client", if you will) to a set of registration information at a specific authorization server. The client uses this to call its Client Information Endpoint to do updates, refreshes, and potentially delete itself. This token is *only* good at this Client Information Endpoint, and nowhere else. This token is specific to the registration it represents. >> This is not apparent at all. No more than binding the registration to the client credential since the implication is one reg -> one client cred and one reg token. >> >> John Bradley has brought up seemingly other scenarios that would not bind but rather associates a dev or an admin to a reg. i may be wrong. I have not had time to consider his explanations yet. >> >> What seems clear is that there is confusion as to the purpose and role for this token and what the use cases are for registration. >> >> My plan is to review and suggest clarifying text and changes if necessary this week. >>> 2) The (optional) initial token used to authenticate to the Client Registration Endpoint. This is *not* the registration access token, and it is *not* used to access the Client Information Endpoint. How the client or developer get this token is out of scope. How the registration server validates this token is out of scope. The structure and contents of this token are out of scope. >>> >>> 3) The access/refresh tokens that a registered client eventually gets from the Token Endpoint and uses with protected resources. These tokens aren't used at the Client Registration Endpoint or at the Client Information Endpoint. >>> >>> There are also a couple of related concepts that aren't tokens at all: >>> >>> 4) The client_id, which is issued to a "client" (or "client instance") by the authorization server. This must be unique at the auth server for each client instance. The client uses this client_id at the Authorization Endpoint and the Token Endpoint in normal OAuth flows. >>> >>> 5) The client_secret, which is issued to a "client" (or "client instance") by the auth server, for confidential clients (ie: clients that can protect their client_secret). This is used by the client to authenticate to the Token Endpoint and nowhere else. >>> >>> >>> Which of these do you mean by a "client token"? >>> >>> -- Justin From phil.hunt@oracle.com Tue May 21 07:26:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBB121F97D2 for ; Tue, 21 May 2013 07:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9Y3exfwTchY for ; Tue, 21 May 2013 07:26:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6286B21F97D7 for ; Tue, 21 May 2013 07:26:37 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4LEQXNt020992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 14:26:34 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LEQYDl001722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 14:26:34 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LEQXZF023186; Tue, 21 May 2013 14:26:34 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 May 2013 07:26:25 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519B7AA5.3070908@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-AE4E88D8-635F-4B8C-A012-F8D96D3AD939 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 21 May 2013 07:26:20 -0700 To: Justin Richer X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 14:26:46 -0000 --Apple-Mail-AE4E88D8-635F-4B8C-A012-F8D96D3AD939 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Justin, Please re-consider what I was saying. You are not cnsidering what was known w= ithout reg and what is known after dyn reg.=20 In public clients, you are changing the meaning of client_id.=20 You are throwing away what was shared among all public clients (a client id)= running the same software.=20 When you issue a separate id you need to retain what was known before which w= as critically important-a set of clients share the same software and thus be= have in certain ways.=20 Gaining a unique cred while losing information about what the software is ma= kes dyn reg's value dramatically reduced.=20 Phil On 2013-05-21, at 6:46, Justin Richer wrote: >=20 > On 05/21/2013 02:01 AM, Phil Hunt wrote: >>=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 8:35, Justin Richer wrote: >>=20 >>>=20 >>> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>>> Mike, >>>>=20 >>>> Rather then embed comments in an extended thread, I'd like to open up a= specific discussion on the objective of dyn reg. >>>>=20 >>>> I see limited to no value in having clients completely anonymously regi= stering and receiving tokens without any ability to correlate applications b= etween applications.=20 >>>=20 >>> I think that herein lies a very big disconnect in assumptions. I see a h= uge benefit in anonymously registered clients getting tokens because there i= s an end-user in the loop during the authorization phase (long after registr= ation has happened). The arity of registrations to authorizations approaches= 1:1 in these cases, and I'm just fine with that. >> Then what you describe is NOT anonymous but rather a profile not cove= red by the spec as there is no discussion of user authenticated registration= . Implicitly or explicitly. >=20 > [JR] I think you misunderstand what I said, let me try to be more explicit= : the user is not authenticating the registration. The user is not involved i= n the registration. The user might not even know that a registration happene= d. The registration is (normally) completely anonymous and open, the client j= ust shows up and says "Hi, I'm a client!".=20 >=20 > The "authorization" that I mentioned happens later and is a normal OAuth a= uthorization, which has a user involved like usual. The authorization step i= n OAuth depends on *some* kind of registration happening beforehand, dynamic= or otherwise. This is all perfectly within the model of OAuth.=20 >=20 >>>=20 >>> =46rom the RFC6749 perspective, a "client" is not a particular piece of c= ode, it is a particular copy of a piece of code with a particular client_id f= rom the vantage point of a particular authorization server. >> actually, i disagree. This spec fundamentally breaks the old definit= ion and behavior from 6749. In the old way every instance of software shared= a client_id. In this draft, u throw that away without preserving the inform= ation. This is BAD! > [JR] No, we're not throwing that away at all. The concept is the same, but= when you add new functionality, the mechanics change a bit. A "client_id" w= as always pairwise between a client and an AS. If a client had to talk to tw= o AS's before, it would have two client_ids. That's still the case. If there= were multiple copies of a confidential client, you need to get a client_id a= nd client_secret to each copy. That's still the case. What's different is th= at we've made it *easier* for a particular piece of code to get differen= t client_ids when it's talking to the same or a different auth server, at ru= ntime. When you have to manually register every client, you're going to just= do it once. If you can do it dynamically, you have more options.=20 >=20 > Note that you can *still* have a public client with a known client_id if y= ou want to. You don't even need to use dynamic registration for that. Heck, y= ou don't need to use dynamic registration for any kind of client if you don'= t want to, since most services will probably still offer manual registration= through some portal kind of page. >=20 >>=20 >>=20 >>> A "client" is, conceptually, a pairwise association between two running c= odebases. When you have a particular piece of code talking only to one auth s= erver and being manually configured at said auth server with its client_id, t= his is fairly clear and straightforward and the arity is simple. Things get a= bit muddy when you introduce dynamic registration, which is why I think tha= t we need to have introductory text about this. Specifically: >>>=20 >>> - a particular piece of code can be run on multiple devices and talk to= the same auth server, each copy of that code getting its own client_id.=20 >>> - a particular copy of a particular piece of code can now be expected t= o talk to multiple auth servers, each auth server giving the piece of code i= ts own client_id.=20 >>>=20 >>> Both of these are cases of what defines an "instance" in most people's h= eads, even though it's the same software, even sometimes the same running co= py of the same software. But as far as RFC6749's definition of "client" is c= oncerned, these are all completely separate "client"s with no way to tie the= m together out of the box. And that's fine. >>>=20 >>>>=20 >>>> Associating client_id's with known client applications to allow admins t= o know who is running what version of clients seems to be the most fundament= al part of the reason for dynamic reg. How can you revoke access to particul= ar client app types? As Justin already talked about in his Blue Button+ sce= nario, there are often life and death situations where particular sets of cl= ients need to be revoked.=20 >>> While it's very useful, I wouldn't (and haven't) classified it quite lik= e that. Nor would I say that the BB+ profile is a complete solution -- our R= egistry component does not actually push revocation notifications down to Pr= oviders (yet), so it's more like invalidating a root certificate and waiting= for caches to time out for things to cascade. We've been talking about addi= ng some form of callback to providers, but we don't want to boil that partic= ular ocean right now. However, the BB+ profile makes use of a well-specified= discovery and Registry set up, as well as data conveyed in structured, sign= ed tokens (JWTs) at different points in the process. >>>=20 >>>>=20 >>>> Or put another way. I believe this will be a critical operational requi= rement going forwards. If the spec is published as is, it will be quickly in= validated by one that does at least partially address the problem. >>> That's not true at all. BB+ addresses this scenario and still uses the D= ynamic Registration spec as-is. I would encourage folks to read what we're d= oing, a work-in-progress found here: >> but you are breaking other things and overloading client cred etc to= pass in signed data. I don't want a hack for a solution. I want interop. > [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks c= ompatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix= there. It is our intent to be fully compatible with OAuth Dyn Reg, and we a= re even explicitly calling for open registration as mandatory to impleme= nt for authorization servers within BB+, even though we have additional mech= anisms as well for what we're calling "trusted registrations". For those tru= sted registrations, we're not using the client *credentials* to pass in sign= ed data, we're using the initial *registration authentication* mechanism (wh= ich is to say, an OAuth token) for its intended purpose: authorizing the hol= der of this token access to the registration endpoint. In BB+, we're profili= ng exactly what that means. To wit, we define the content of the token (whic= h is fully compatible with DynReg which doesn't care what's in the token) an= d how the AS can verify it (which DynReg doesn't care how it happens) and we= 've added some additional rules and policies that allow us to tie together i= nstances of the client across the distributed network.=20 >=20 > So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge am= ount of very specific machinery (signed tokens with known formats and fi= elds, a Registry with manual pre-registration, a three-tiered discovery serv= ice with information about clients and service providers rooted at the Regis= try, trust frameworks and network enforcement policies that all players have= to agree to before playing, etc.), and it's not really doing just registrat= ion anymore. In BB+, we needed the Registry and Discovery services to do oth= er functions as well apart from just registration, and so it makes sense to r= e-use them.=20 >=20 > If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced tha= t a good solution for managing client instances across a network requires a l= ot more thought and consideration, and I believe that having a fully specifi= ed discovery service will help this case, like it has helped in BB+. But I t= hink that it's a complex enough problem that it needs its own set of conside= rations. With DynReg, we need to leave things open for that work in the futu= re, and I believe we have, but we shouldn't kill the simple, general case fo= r want of a special case.=20 >=20 >>>=20 >>> http://blue-button.github.io/blue-button-plus-pull/ >>>=20 >>> Just because you make something better doesn't mean you throw necessaril= y away everything you've done to date. >>>=20 >>>>=20 >>>> We're ahead of schedule, lets talk through the requirement. >>> I believe that the requirement of tying instances together is explicitly= out of scope for the dynamic registration protocol. I intended to have text= to that effect in the section I'm adding about the client lifecycle. >>=20 >> where is this stated in charter? > [JR] The charter for the working states what's in scope, not what's out of= scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abou= t registration is this: >=20 > And dynamic client registration will make > it easier to broadly deploy OAuth clients (performing services to > users). >=20 > And:=20 >=20 > Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG f= or consideration as a Proposed Standard > There's nothing in there at all about tying together client instances. I h= ave not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client r= egistration. It sounds very likely to me that it *is* required for your u= se case, but that doesn't make it required for everybody's use case.=20 >=20 > There are other important pieces of functionality that the WG isn't pickin= g up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for those= to be separate modules. >=20 >>>=20 >>>>=20 >>>> As I mentioned in my comments to the other thread. Let's say we agree n= ot do this now. Well, then the new draft that does solve it would likely be 9= 5% overlap. Thus I see this issue as within charter and should be solved no= w rather then waiting for a V2 dyn reg in the next charter. >>> Why wouldn't the new draft just be the extra 5%? I personally think that= it's a lot more than 5% once you have in all the assurance and safety mecha= nisms in place to avoid self-asserted values causing race conditions, and wh= at not. >>=20 >> Two drafts to do registration is not the way to go. It implies compl= exity where there should be none. There is no technical reason for two draft= s. > [JR] There is a need when there's a special case that requires a large amo= unt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today).=20 >=20 >>>=20 >>> -- Justin >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>>>=20 >>>>> Thanks for the detailed feedback, Phil. Sorry for the delayed respons= e =E2=80=93 I was pretty fully engaged at the European Identity Conference (= where OAuth 2.0 won the award for best new standard J). My feedback on the p= oints raised is inline in green=E2=80=A6 >>>>> =20 >>>>> (Perhaps if any of you reply to this thread, you could also choose a d= istinct color for your inline replies, so that it will be easily evident who= said what. As it is, just the back-and-forth between Phil and Justin is al= ready very difficult to follow. Thanks.) >>>>> =20 >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of Phil Hunt >>>>> Sent: Thursday, May 16, 2013 12:54 PM >>>>> To: Richer, Justin P. >>>>> Cc: oauth@ietf.org WG >>>>> Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-1= 0 >>>>> =20 >>>>> Justin, >>>>> =20 >>>>> Thanks for the discussion. More comments below... >>>>> =20 >>>>> BTW. I'm happy to contribute text. Just want to get to some rough agre= ement first. For example, I think we need to have a away to recognize two p= ieces of software as being the same (even if self-asserted). Once defined, I= can put together some intro text, etc. >>>>> =20 >>>>> Phil >>>>> =20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> =20 >>>>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>>>> =20 >>>>> On May 15, 2013, at 10:30 PM, Phil Hunt >>>>> wrote: >>>>> =20 >>>>> On 2013-05-15, at 5:53 PM, = Richer, Justin P. wrote: >>>>> =20 >>>>> Phil, many thanks for the extremely thorough review! It is very useful= indeed.=20 >>>>> =20 >>>>> My comments and responses to each point are inline.=20 >>>>> =20 >>>>> On May 15, 2013, at 4:30 PM, = Phil Hunt wrote: >>>>> =20 >>>>> It seems unfortunate that I have not gotten a chance to get into this l= evel of detail much earlier. But then, I guess that's what LC review = is for! My apologies for no= t getting many of these concerns to the WG much earlier. >>>>> =20 >>>>> Overall =20 >>>>> ----------- >>>>> I think dynamic registration is a critical part of the OAuth framework= now that we are starting to consider how individual client applications sho= uld operate when there is one or more deployments of a particular resource A= PI. We've moved from the simple use case of a single API provider like Faceb= ook or Flickr and moved on to standards based, open source based, and commer= cial based deployments = where there are multiple service endpoints and many clients to manage. >>>>> =20 >>>>> The dynamic registration spec is actually dealing with a couple of iss= ues that I would like to see made more clear in early part of the spec: >>>>> =20 >>>>> 1. How is a new client application recognized for the first time when= deployed against a particular SP endpoint? Should clients actually assert a= n application_id UUID that never changes and possibly a version id that does= change with versions? >>>>> =20 >>>>> In the general case, why is any recognition required? If you're = doing things as part of a larg= er protocol ecosystem, like Blue Button+ or a particular OpenID = Connect provider, then you can defin= e semantics for tying together classes of clients (see below for more discus= sion on this very point). But in general, a client is just going to show up a= s a new instance to the AS = and get issued a new, unique client_id, and that's that.=20 >>>>> =20 >>>>> I think we have to define more = clearly what an "instance" is. For me, there are applications and there a= re instances of that application. It is useful to understand that a client a= pplication represents a set of code that should behave in a consistent way. = It seems to me the first time a new application shows up is very different f= rom the subsequent instances that register. For example, after the first reg= istration, subsequent instances don't need special review or approval to the= same degree. >>>>> =20 >>>>> But without other mechanisms to tie things together, there's no way fo= r an authorization server to know if any client instance is tied to any othe= r client instance. Therefore, from the perspective of an AS, the first insta= nce of an application (i.e., particular configuration of a set of code) to r= egister is no different to subsequent instances of that same application. Ho= w were you envisioning an AS knowing the = difference between the first and subsequent instances of an = application, specifically? If there's an "applicati= on_id" like you mention above, I think= it raises more questions than it resolves: Who issues the application_id, s= ome server or the application itself? Is it validated at all? Should it be c= onsidered secret? What happens when someone simply steals an application_id?= Does an AS have to do anything to check with any other AS to see if the app= lication_id has already been used elsewhere? >>>>> =20 >>>>> I do agree that a discussion of "instance vs. application" would be he= lpful in clearing this up, I'll make a note to add text to that effect. (We h= ad to do something similar for BB+) >>>>> =20 >>>>> I think it is simple enough to at least add a self generated UUID for t= he application ID. Though I would allow for cases where the application ID i= s assigned when the client developer and the APIs owner do a formal assignme= nt of application IDs. >>>>> =20 >>>>> In a sense this is just a lower tech way of doing it than what = you described as the initial client credential in= Blue Button+ where you encoded extra claims into the initial app credential= . >>>>> =20 >>>>> What the UUID does is link multiple instances of a client app together= as the same "thing" that should have similar heuristics/behaviours. This i= s very useful if you want to be able to revoke access to a set of clients id= entified by application id (or a version of that app). >>>>> =20 >>>>> While I=E2=80=99m sympathetic to the OAuth working group eventually do= ing work on differentiating between instances of an OAuth client, I=E2=80=99= ll note that in RFC 6749 or RFC 6750 there is no such thing as a client inst= ance. There are only clients, which are identified by client_id values. If= we want to do work on client instances, we should recharter to add this new= work as a working group deliverable. We should not try to shoehorn bits an= d pieces of it into the Dynamic Registration spec, any more than we should h= ave tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is there t= o register clients as defined in RFC 6749. It=E2=80=99s not the right place= to extend what an OAuth client is in new ways. >>>>> =20 >>>>> 2. How are client credentials managed. Are we assuming client credent= ials have a limited lifetime or rotation policy? >>>>> =20 >>>>> The intent was that client_secret could be rotated, as indicated by th= e expires_at member of the r= esponse. If a client's secret expires, it calls the read operation on the Cl= ient Configuration Endpoint (=C2=A74.2) to get its new client_secret. If thi= s is unclear in the current text (which I suspect it may be after multiple r= efactorings), then I welcome suggestions and specific text as to how to make= that clear.=20 >>>>> Something like this should be in the draft. >>>>> =20 >>>>> Should this be up in the introductory text, somewhere else, or have it= s own section? >>>>> =20 >>>>> I'm starting to think credential management is a key part of the draft= . It may be worth introducing a specific section outling the registration li= fe-cycle, registration access token usage, and client token usage and bootst= rapping. >>>>> =20 >>>>> I think that adding a discussion on this would be fine, as it could he= lp developers understand the workflow of registering, using, and updating re= gistered clients. >>>>> =20 >>>>> How does a client authenticate the first time and = subsequent times to the registration service= ? >>>>> =20 >>>>> This is a separate question all = together, as it does not involve the client_secret or client_id a= t all. Rather, the first time the client shows up to the registration servic= e, it may either: >>>>> - Not authenticate at all (this is the true public, open registratio= n, and it is recommended that servers do this) >>>>> - Authenticate using an OAuth 2.0 token (which ATM means a bearer tok= en). How the client gets that bearer token and what the bearer token means t= o the AS beyond "this clie= nt is authorized to register" is out of scope for the spec, by design. >>>>> =20 >>>>> Subsequent times that the same registered client (by which we mean the= same instance of a client with a particular client_id) shows up at the regi= stration endpoint (actually, the Client Configuration Endpoint), it uses its= Registration Access Token that it was issued on initial registration. This i= s an OAuth 2.0 Bearer token that is unique to the client instance. >>>>> =20 >>>>> Something like this should be in the draft. >>>>> =20 >>>>> OK, the definition of the registration access token can be expanded, b= ut I think that the rest of it is already in there in =C2=A73. I'd welcome s= uggestions on which bits of this could be made clearer. >>>>> =20 >>>>> See the discussion on what the registration_access_token is in the thr= ead =E2=80=9CClient Credential Expiry and new Registration Access Token - dr= aft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin to apply these c= larifications to the specification. This may go into the proposed credentia= l management overview section discussed above. >>>>> =20 >>>>> 3. How is versioning of clients managed? Should each new version of a= client require a change= in client registration including possibly changing client_id = and authentication credential? I don't= have a strong feeling, but it is something that implementors should conside= r. >>>>> =20 >>>>> This is up to the AS, really, = and I don't think that any global policy would ever fly here. Especi= ally if you consider that the entire notion of "version" is more fluid these= days than it ever has been. I wouldn't mind adding a discussion in the secu= rity considerations if it merits mentioning though, so that we can help both= client developers and server developers institute reasonably good policy. >>>>> =20 >>>>> I guess the issue is that when a = client upgrades it may have access to the old credentials. What is the i= ntent then of registration. Since you have an update are clients expected t= o update /re-register or not? I'm not sure this is a security consideration= but more part of the whole change management function dynamic registration s= upports. >>>>> =20 >>>>> If your upgraded version of the c= lient still has access to its old credentials, why wouldn't it just use thos= e? I don't see a reason for forcing a re-registration. Nor do I see any way t= hat an AS would even be able to tell that a client had been upgraded. An upg= raded client always has the *option* of re-registering itself and getting a n= ew client_id.=20 >>>>> I think the concern here is that rotation of client credential is not s= omething discussed before. Before we put it in the spec we should consider t= he reasons for doing it and what problems it solves. >>>>> =20 >>>>> I think this may be just a case of letting people exchange credentials= for whatever reason they feel is appropriate. The version upgrade thing su= ggests that when a client is upgraded it should go to the registration serve= r to "re-register". Depending on the policy of the = server, it may (or may not) receive a new client_id and/or new cre= dential. =20 >>>>> =20 >>>>> One of the best benefits I can think of is if you discover a version o= f a client has a problem, being able to select a group of clients by softwar= e and version is important. Thus if client_id doesn't trace to a particular s= oftware and version, that makes it hard to do. I think you talked about th= is as an issue for Blue Button+ >>>>> =20 >>>>> Again, RFC 6749 defines no client instances or groups of clients, ther= efore I believe that it=E2=80=99s inappropriate to do so here. We don=E2=80= =99t need to boil the ocean. If a new charter item is approved to do work o= n client instances and protocol elements to use and express them, that=E2=80= =99s the time for the working group to consider that possibility =E2=80=93 n= ot as part of Dynamic Client Registration. >>>>> =20 >>>>> 4. What is the registration access token? Why is is used? What is its= life-cycle? When is it issued, when is it changed? When is it deleted? >>>>> =20 >>>>> See the response above above = and the definition in =C2=A71.2:=20 >>>>> =20 >>>>> Registration Access Token: An OAuth 2.0 Bearer Token issued by the Aut= horization Server through the Client Registration Endpoint which is used by t= he Client to authenticate itself during read, update, and delete operations.= This token is associa= ted with a particular Client. >>>>> =20 >>>>> If this can be clarified, I welcome text suggestions. >>>>> =20 >>>>> The latter part of 1.2 didn't seem like terminology but rather archite= cture or part of the introduction that describes what the spec does. The thi= rd point doesn't seem to fit with the other two except to say that the dynam= ic registration endpoints use their own access = tokens called registration access tokens. >>>>> =20 >>>>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>>>> a Client can request new registration. The means of the Client >>>>> obtaining the URL for this endpoint are out of scope for this >>>>> specification. >>>>> =20 >>>>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>>>> which a specific Client can manage its registration information,= >>>>> provided by the Authorization Server to the Client. This URL fo= r >>>>> this endpoint is communicated to the client by the Authorization= >>>>> Server in the Client Information Response. >>>>> =20 >>>>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by t= he >>>>> Authorization Server through the Client Registration Endpoint >>>>> which is used by the Client to authenticate itself during read, >>>>> update, and delete operations. This token is associated with a >>>>> particular Client. >>>>> =20 >>>>> This section is meant to just introduce the new terms that are then ex= plained in greater detail throughout the rest of the = document. Yes, it's a bit architecture, but only in the sense= that you need to define the terms that make up your architecture. How would= you suggest that it change? >>>>> =20 >>>>> Probably this is more a matter of style. But, what happened for me is= I naturally skipped the terminology section, as I wasn't expecting protocol= components to be there. "terminology" is something I think people tend to u= se as a dictionary rather than as protocol component description. Maybe the= chairs can advise? >>>>> =20 >>>>> If we distinguish between first time registration of a particular clie= nt software package, it is possible that somethings like authentication meth= od can be negotiate in or out-of-band at that time. Subsequent registrations= should only have parameters for items that could change per deployment (lik= e tos_uri). I think token_endpoint_auth_method is one thing that should not= be negotiated per instance. >>>>> =20 >>>>> When subsequent instances = register, I have to ask the question, for example when would thing= s like "token_endpoint_auth_method" be negotiated or be different for the sa= me client software? Sh= ould not all instances use the same authentication method. >>>>> =20 >>>>> I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change pe= r instance. And instance, you should keep in mind, is defined as any one cop= y of the client code connecting to any new authorization server. That pairin= g creates the client_id, and therefore the = instance, and therefore the registration access token, and th= erefore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_au= th_method. Where else would the AS find out about it? >>>>> =20 >>>>> We still disagree on this. It is my assertion that clients should NEVE= R ask for a particular token auth method. Since it is the AS that is authent= icating the client, then it is the AS's right to set the authentication poli= cy. The role of dynamic reg endpoint = is to inform the client what it must do. My assumption is that during= the first time a piece of software is registered (the first instance), ther= e could be some OOB discussion by an = administrator to approve the = particular authentication type for the AS in question. >>>>> =20 >>>>> I haven't heard a reason justifying this parameter other then "it is n= eeded". Why? >>>>> =20 >>>>> The role of the dynamic registration protocol is twofold: half of that= is the server informing the client what it must do. But the other half is t= he client informing the server what it= *can* do, or what it *wants* to do.=20 >>>>> =20 >>>>> And again, there's no way to distinguish a first instance from a subse= quent instance unless you're doing something in addition. Nothing is stoppin= g the same application from registering a new instance of itself for every s= ingle user or every single token that it wants to get access for. That's com= plicated and wasteful and not a great idea, sure, but there's no useful way= to prevent that kind of behavior if you also want open registration of clie= nts.=20 >>>>> =20 >>>>> I think we've discussed how recognizing subsequent instances is easily= done. >>>>> =20 >>>>> As I mentioned in the other thread, if a developer chooses to limit th= e capabilities of the client it must do so by looking to the developer or st= andard behind the API. Otherwise they are taking the chance. There's no wa= y a developer can query all the potential deployers to ask what authn types w= ill you use. As I said, the net effect in the absence of an API standard dic= tating what should be supported, the developer will have to implement all me= thods. >>>>> =20 >>>>> My point here is that none of this is helped by the client app saying w= hat it supports. A developer who takes the route of limiting implementation t= akes the chance that the server will not accept. So why negotiate within re= gistration? >>>>> =20 >>>>> And there's no way other than per-instance for the server to tell the c= lient which token_endpoint_auth_method to use. All instances will probably a= sk for the same token_endpoint_auth_method from all auth servers they talk t= o, right? And each AS will tell each instance that registers with it to use a= particular auth method. There is no way to tie together different instances= across (or within) auth servers without specifying a significant amount of o= ther machinery. >>>>> =20 >>>>> Which is not to say that it's = not useful in some circumstances to tie together different instances= of the same code across (or within) auth servers. This is why, with Blue Bu= tton+, we specified a specific token format for the initial access token tha= t the clients use to call the registration endpoint the first time, as well= as a discovery protocol against a centralized server that handles pre-regis= tration. All of this machinery is, in my opinion, a stupendous overkill for t= he general case, though if some folks find use for it outside of BB+ then it= 'd be a good thing to abstract out and make its own spec that extends the Dy= n Reg spec in a fully compat= ible way. Furthermore, even in Blue Button+ we specify that all auth servers= MUST also accept open registration, without an initial access token, where t= he client simply shows up and says "hey, here are my parameters." The auth s= erver has no way to know in this case any kind of out-of-band negotiation fo= r different things. In BB+ w= e are writing very specific policy guidelines about how to present the UX an= d things to the end user for= all of these different cases. But again, all of this is specific to the BB+= use case, and I don't see value in dragging it in to the registration spec o= n its own. I believe it would be far too limiting. >>>>> =20 >>>>> See my previous comments on differentiating client instances being out= of scope without rechartering to do this new work and on what the registrat= ion_access_token is. In short, the registration_access_token is an RFC 6750= bearer token issued to the party registering the client, enabling it to sub= sequently retrieve informa= tion about the client registration and to potentially update the registratio= n information for that registered client. Again, I=E2=80=99ll work with Jus= tin to make sure that this is as clear as possible in the specification. >>>>> =20 >>>>> Finally, there seems to be an inconsistent style approach with draft-h= ardjono-oauth-resource-reg which uses ETags. Should this draft do so as well= ? >>>>> =20 >>>>> That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource r= egistration draft comes from) uses ETags, hence their inclusion there. I per= sonally don't see their utility here, though, and I wouldn't want to include= a wholly new mechanism this late. >>>>> =20 >>>>> Yes. Thomas' draft is not a WG document. But that doesn't = mean he doesn't have a point. It's worth discu= ssing.=20 >>>>> =20 >>>>> One could argue that the point of an ETag is that it is useful for cha= nge detection when there are multiple writers to a particular resource. In t= he design of dynamic registration e= ndpoint, there should only be one w= riter -- the client. This is an important observation. >>>>> =20 >>>>> There are other mechanisms that handle this -- namely, the registratio= n access token and the client_id. Many instances include the client_id in so= me form in the client configuration endpoint's URL for sanity checking, as d= escribed in =C2=A74.1.=20 >>>>> =20 >>>>> If everyone agrees, I'm in agreement. But it will likely mean changes f= or the resource reg draft if adopted. >>>>> =20 >>>>> ETags seem like an unnecessary addition (and potential complication) t= o the specification. It=E2=80=99s already working fine as-is. >>>>> =20 >>>>> Specific items: >>>>> --------------------- >>>>> "token_endpoint_auth_method" >>>>> =20 >>>>> There is some confusion as to = whether this applies to server or client authentication. Suggest r= enaming parameter to "token_endpoint_client_auth_method" >>>>> =20 >>>>> This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes without= very, very compelling reaso= ns to do so. >>>>> =20 >>>>> The question was raised to me by some new developers. It seems obvious= to us as experienced OAuth persons, but to new developers it seems unclear.= Also, now that you are introducing registration authentication, the whole t= hing gets very confusing. So it is useful disambiguate all the parameters wh= ere possible. That said, I wouldn't mind shorter names (maybe not quite as s= hort as the JOSE stuff ;-) >>>>> =20 >>>>> Fair enough, but again, I only want to do syntax changes if the rest o= f the WG *really* wants to. >>>>> =20 >>>>> I agree with Justin here. I=E2=80=99m fine clarifying the description= of this parameter to resolve the potential ambiguities that you cite, Phil.= I=E2=80=99m not OK revising the syntax without a compelling reason to do s= o. >>>>> =20 >>>>> * Currently, the API only supports a single value instead of an array.= If the purpose is to allow the client to know what auth methods it = supports, this should be an array= indicated what methods the client supports - or it should not be used. >>>>> =20 >>>>> I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it wa= s decided that a single value was simpler and sufficient for the purpose. Th= e IETF draft has inherited this decision. I *believe* (though am not 100% po= sitive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. >>>>> =20 >>>>> I can get behind multiple values. In this case, it changes the meaning= of the parameter. Instead of the client forcing the server to use a particu= lar method, the client is informing the server about what methods it can per= form. This allows the server to as= sign the appropriate method based on its own policy. >>>>>=20 >>>>> Also note that this field, like all others in =C2=A72, represents two t= hings: the client telling the server "I want to use this value for this fiel= d", and the server telling the client "this = is the value you have for this field". It's not exactly a nego= tiation, more like making a polite request to an absolute dictator who has t= he last word anyway. But at least this dictator is nice enough to tell you w= hat their decision was instead= of just decapitating you. >>>>> =20 >>>>> This is the heart of my objection. This fuzziness is is going to lead t= o interop issues. >>>>> =20 >>>>> There is no fuzziness that I can see here. It's parallelism between wh= at goes in to the endpoint and what comes out of it. The semantics for the r= equest and the response are different, and differentiable by the fact that o= ne is a request and the other is a response.=20 >>>>> =20 >>>>> The inter-op issue I would like to point out is that the spec does not= currently specify if particular input values are singular or multiple. If a= n implementer assumes singular and clients assume multiple, we have issues. >>>>> =20 >>>>> The multiple/single discussion above gets to the heart of what I *do* b= elieve is a deficiency in the specification, as it=E2=80=99s currently writt= en. The authors, myself included, have failed to make it 100% clear that di= scovery of Authorization Server functionality is out of scope for this speci= fication. I strongly believe that we need to add a clear statement to this e= ffect in the introduction to the specification. >>>>> =20 >>>>> The purpose of the Dynamic Client Registration specification is for th= e client to register with the Authorization Server and to inform it of prope= rties of the client that the AS may want/need to be aware of. It *is = not* the purpose of this specification for it t= o be used by clients in any manner to discover features of the Authorization= Server. That should be explicitly out of scope. >>>>> =20 >>>>> Currently, clients are instructed by RFC 6749 to discover information a= bout Authorization Servers they interact with by consulting the =E2=80=9Cser= vice documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2). They can also= learn information about Authorization Servers in specific contexts through d= iscovery protocols such as OpenID Connect Discovery (http://openid.net/specs= /openid-connect-discovery-1_0.html) and UMA Discovery (TBD). >>>>> =20 >>>>> I suspect that at some point, someone in the OAuth working group will p= ropose developing a generic OAuth discovery mechanism, which will lead to a r= echartering to include this work in the working group=E2=80=99s set of deliv= erables. I would support doing this work and the necessary rechartering to d= o so. >>>>> =20 >>>>> That being said, I strongly oppose trying to shoehorn piecemeal aspect= s of discovery into the Dynamic Client Registration specification. It is di= stinct functionality and deserves first-class and separable treatment by the= working group. Discovery is for potential clients to learn properties of t= he AS before registration. Registration is for potential clients to inform t= he AS of its properties, creating a registered client. Discovery sends info= rmation about the AS to the Client. Registration sends information about th= e Client to the AS. That=E2=80=99s a clean separation. We should strongly r= esist muddying the two functions. >>>>> =20 >>>>> OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean= . It specified how to do one thing well in a simple, web-friendly manner. W= e should do the same =E2=80=93 focusing on specifying interoperable dynamic c= lient registration, while making it clear that this is distinct from discove= ry about Authorization Server properties, and making it clear that discovery= is out of scope for this work. >>>>> =20 >>>>> I apologize at this point on behalf of myself and the other spec edito= rs for not being 100% clear that discovery functionality is explicitly out o= f scope for Dynamic Client Registration. If we had done so, I=E2=80=99m sur= e that many of the current questions and confusions would not have arisen. I= think we=E2=80=99d assumed that this was obvious, but from the current disc= ussions, it=E2=80=99s apparent that it=E2=80=99s not obvious. I will person= ally commit to clarifying the specification at this point to eliminate this p= otential point of confusion. >>>>> =20 >>>>> Getting back to the specifics, the only useful purpose of a multi-valu= ed =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member would be to en= able the client to discover information about the authentication methods sup= ported by the AS after the registration had been performed. But that is a d= iscovery function, and so should be part of the discovery work =E2=80=93 not= this specification. We should resist shoehorning in bits of discovery into= this specification. It *is* a worthwhile topic, but deserves full consider= ation by the working group in its own right. = Therefore, this member must remain sin= gle-valued, and be clearly specified as the method by which a client informs= the AS which token endpoint authentication method it will = use. Anything else would be scope creep, and result in an u= nnecessarily complicated specification and= unnecessarily complicated clients. >>>>> =20 >>>>> * There is no authn method for "client_secret_saml" or "private_key_sa= ml". >>>>> =20 >>>>> Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an= absolute URI) would allow someone else to define these. Is the definition i= n the SAML Assertion draft sufficient for their use? >>>>> =20 >>>>> I think this is coming from the = fact that there is a JWT bearer draft and a SAML bearer draft. The trut= h is you are defining an authentication that isn't even defined. >>>>> =20 >>>>> There are no profiles referenced or defined for "client_secret_jwt" or= "private_key_jwt". Neither of the JWT or SAML Bearer = drafts referenced cover these types of flows= . They only cover bearer flows. "client_secret_jwt" and "private_key_jwt" s= eem to have some meaning within OpenID Connect, but I note that OIDC does no= t fully define these either. >>>>> =20 >>>>> The JWT assertion draft does say how to use a JWT = for client authentication, and the DynReg text= differentiates between a client signing said JWT with its own secret symmet= rically vs. a client using its own private key, asymmetrically. >>>>> =20 >>>>> Actually my interpretation is the JWT draft assumes the JWT Bearer is a= bearer token. The assumption is that if a client has the assertion it has t= he right to present it. IOW. The JWT Bearer Draft is most definitively not a= JWT HoK Draft. :-) >>>>> =20 >>>>> Regardless, you are introducing a new profile which is undefined. >>>>> =20 >>>>> I think I see the point that you're making now, let me try to re-state= it: >>>>> =20 >>>>> While the basics of "how to present a JWT as a client credential" is d= efined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rf= c.section.2.2 , it's not completely specified in that it doesn't fully restr= ict the signature secret source, the audience claim, and other things that t= he AS would need to check and validate. Right? The dynamic registration draf= t can define those cases in greater detail if needed (though I think it does= so sufficiently as-is, I welcome more clarity). >>>>> =20 >>>>> I'd be OK with adding the SAML bit, going into greater detail on the J= WT bits, or dropping the JWT bits, if the WG wants to do any of those action= s. My objection is that the JWT stuff is already in use and functioning and i= t'd be a shame to leave it out. >>>>> =20 >>>>> I guess then the mistake the JWT Bearer and SAML Bearer drafts authors= made is they assumed everyone had the same definition of bearer token. To m= e a bearer token opaque to the client. It therefore cannot do any signature w= ork with regards to the token itself. Now, that's not to say a proof didn't= occur between the client and the token issuer, but when the client wields t= he token, it is handling an opaque string. >>>>> =20 >>>>> The concept of client_secret_jwt suggests an HoK profile. Therefore o= f course the bearer drafts are a little underspecified when it comes to HoK p= rofiles. >>>>> =20 >>>>> So for example, you need a draft like the MAC draft for this.=20 >>>>> =20 >>>>> I'm having trouble overall here. It seems the authn types suggest ONLY= strong authentication for clients, yet during the registration process the c= urrent draft isn't able to correlate multiple instances of the same software= (even in a self-asserted way). If you haven't authenticated the software a= t all, why have strong client auth? >>>>> =20 >>>>> There is no authentication = method defined for "client_bearer_saml" or "client_bearer_jwt" or= "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration sp= ec should accept these. >>>>> =20 >>>>> I don't understand this bit -- where are these defined in RFC6750? I d= on't even know what client_bearer_ref would refer to. >>>>> =20 >>>>> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) a= nd wield it as an authentication assertion. The client is NOT creating or m= odifying the assertion. The client is simply passing one it previously obtai= ned. >>>>> =20 >>>>> What you are describing is not bearer. It is holder of key. Very very d= ifferent.=20 >>>>>=20 >>>>> A possible suggestion is to remove client_secret_jwt and private_key_j= wt and define those as register extensions since these profiles are not defi= ned. >>>>> =20 >>>>> That's possible, but they are = in active use already.=20 >>>>> =20 >>>>> That may be true. But then you need to write another draft so the rest= of us can implement it in an interoperable way. Me I prefer not to guess w= hat you are doing. >>>>> =20 >>>>> This much I agree with. >>>>> =20 >>>>> Justin, John, and I discussed this issue and agree with your suggestio= n, Phil. Since they are not completely specified, we will remove the client= _secret_jwt and private_key_jwt methods from the specification and add a reg= istry, enabling specification that do fully specify these and other token en= dpoint authentication methods, including potential methods using SAML assert= ions, to register them in the registry, rather than trying to bake them into= the Dynamic Client Registration specification. >>>>> =20 >>>>> About "tos_uri" and "policy_uri" >>>>> =20 >>>>> The distinction between tos_uri and policy_uri is unclear. Can we cla= rify or combine them? >>>>> =20 >>>>> Terms of service and policy are two different documents. One is someth= ing that a user accepts (generally describing what the user will do), one is= a statement of what the service provider = (in this case, the client) will do. More importantly, we use= d to have only one, and several people asked for them to be split. >>>>> =20 >>>>> Several developers were confused by this. In particular they couldn't f= igure out which was used for what. Just passing along the feedback. >>>>> =20 >>>>> OK, the distinction that I see is that the TOS is contractual, the Pol= icy is a statement. Re-reading the definitions in there right now, that can b= e made much clearer. (It even looks like some OIDC text leaked into the defi= nition of policy_uri and that hadn't been caught yet.) >>>>> =20 >>>>> I support clarifying the language on these definitions, and will work w= ith Justin to do so. >>>>> =20 >>>>> Also, aren't these really URIs or are they meant to be URLs? >>>>> =20 >>>>> There was already discussion about this on the = list: The IETF is apparently trying to deprecate U= RL in favor of URI in new specs. So in practice they'll nearly always be URL= s, but since all URLs are URIs we're not = technically incorrect in following the new policy. And it mak= es the IESG less mad at us, which is a plus. >>>>> =20 >>>>> Arg. Nice. Then the text should say the value passed must resolve to a= valid web page, document, whatever. >>>>> =20 >>>>> That's fair, and it's something that the AS can even check if it wants= to. >>>>> =20 >>>>> Agreed on this clarification. >>>>> =20 >>>>> About "jwks_uri" >>>>> =20 >>>>> A normative reference for http://tools.ietf.org/html/draft-ietf-jose-j= son-web-key-09 is needed.=20 >>>>> =20 >>>>> Yes, you're correct, I'll add that. >>>>> =20 >>>>> Should be URL instead of URI? >>>>> =20 >>>>> See above. :) >>>>> =20 >>>>> Agreed on adding this reference. >>>>> =20 >>>>> Section 2.1 >>>>> =20 >>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>>> is missing. >>>>> =20 >>>>> It's there in the copy of -10 I'm reading off of ietf.org right now =E2= =80=A6 ? >>>>> ' >>>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>>>> =20 >>>>> Ah, that makes more sense. If the WG wants to add in SAML support to p= arallel the JWT support, I'd be OK with that. >>>>> =20 >>>>> =E2=80=9CAs such, a server supporting these fields SHOULD take steps t= o ensure that a client cannot register itself into an inconsistent state.=E2= =80=9D >>>>>=20 >>>>> We may want to define more detailed HTTP error = response. E.g. 400 status code + defined er= ror code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)? >>>>> =20 >>>>> I'd be fine with defining a more explicit error state in this case. I t= hink it would help interop for the servers that want to enforce grant-type a= nd response-type restrictions, but servers that can't or don't care about re= stricting grants types and whatnot don't have to do anything special. >>>>> =20 >>>>> I *think* that this goes away with the deletion of client_secret_jwt a= nd private_key_jwt in favor of the = registry=E2=80=A6 I=E2=80=99ll do a consistency check and veri= fy that when the spec is updated accordingly. >>>>> =20 >>>>> Section 2.2 >>>>> =20 >>>>> May want to add: >>>>> =20 >>>>> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2= =80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, = instead of =E2=80=9Cclient_name#en=E2=80=9D= ) the OAuth server may use interpret the language used based on server confi= guration or heuristics. >>>>> =20 >>>>> That seems inconsistent with what we already have: >>>>> =20 >>>>> If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make = any assumptions about the language, character set, or script of the string v= alue, and the string value MUST be used as-is wherever it is presented in a u= ser interface. >>>>> =20 >>>>> Which is to say, treat it as a raw byte-value-string and don't try to g= et fancy. >>>>> =20 >>>>> I will discuss with our developers. I'm not sure the as-is works. =20 >>>>> =20 >>>>> Is it the intent that when the client has localized "client_name" for e= xample, it should pass all language variations in a JSON array? >>>>> =20 >>>>> Or, should part of the registration be to indicate which interface lan= guage the client wishes to use? Then it only passes a single value for that= registration? >>>>> =20 >>>>> =20 >>>>> No, the client should pass parameters as multiple separate values. Con= nect has this in its example: >>>>> =20 >>>>> "client_name": "My Example", >>>>> "client_name#ja-Jpan-JP": >>>>> "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D"= , >>>>> Should we add that to at least one of the examples in DynReg? (The lan= guage tags are a late addition, so the examples don't reflect it.) >>>>> =20 >>>>> An example would definitely help. >>>>> If the client passes only a single unadorned field, the AS can't make a= ny assumption about what language it is. Think of this as the internationali= zed value of the field while the language tags are the localized versions of= the field. This is why we recommend that the bare-value always be sent by t= he client, so that in the lack of anything more specific, the AS can at leas= t do *something* with it. >>>>> =20 >>>>> Passing in a "default" language field (like default_locale or the like= ) is only going to lead to pain for implementors of both clients and servers= , and it's going to hurt the interoperability of the human-readable fields.=20= >>>>> =20 >>>>> I think what I meant is since you are allowing each client to = register different things, AND the client likely a= lready knows the user's preferred language, why wouldn't the client just pas= s text values in one language and another parameter indicating preferred lan= guage in the case of any service generated text. >>>>> =20 >>>>> Is the reason you are passing multiple localizations is so that you ca= n use the preferred language of the resource owner rather then the client us= er? I wonder if that is correct. If the language preferences are in fact di= fferent, what would the user of the client app expect? >>>>> =20 >>>>> ----> any multi-lingual people have any opinions here? >>>>> =20 >>>>> Without specific proposed text changes to review, it=E2=80=99s hard to= know what to think about this comment. Unless a specific proposed text cha= nge is sent to the list with clear rationale for why it=E2=80=99s better tha= n what=E2=80=99s there now and reviewed by the working group, I don=E2=80=99= t believe we should change the specification in response to this comment. >>>>> =20 >>>>> Section 3 >>>>> =20 >>>>> Existing text: >>>>>=20 >>>>> =E2=80=9CIn order to support open = registration and facilitate = wider interoperability, the Client Registrat= ion Endpoint SHOULD allow = initial registration requests with no authentication. These request= s MAY be rate-limited or otherwise limited to prevent a denial-of-service at= tack on the Client Registration = Endpoint.=E2=80=9D >>>>>=20 >>>>> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80= =9CMAY=E2=80=9D. In = most cloud services, the first client is registered by a human user. The= n, other clients can be further used to automate other client registration. = So, the first request would typically come with an authenticated user ident= ity.=20 >>>>> =20 >>>>> I think the weight of "SHOULD" is appropriate here, because I believe t= hat turning off open registration at the AS (which is what this is talking a= bout) really ought to be the exception rather than the rule.=20 >>>>> =20 >>>>> I think you are reading it wrong -- a double-negative issue. The end o= f the sentence is "no authentication". You are implying that NO Authenticat= ion us what should normally be done. I = think you intend anonymous authentication to be the exception rather t= han the rule don't you? >>>>> =20 >>>>> No, I think that anonymous authentication should be the rule. Open reg= istration should be default.=20 >>>>> =20 >>>>> I disagree. Again, the spec seems contradictory. It suggests strong c= lient auth methods and at the same time anonymous registration. Yes you gai= n uniqueness, but that's about it. >>>>>=20 >>>>> On the flip side, the earlier paragraph: >>>>>=20 >>>>> =E2=80=9CThe Client Registration Endpoint MAY accept an initial author= ization credential in the form of an OAuth 2.0 [RFC6749] access token in ord= er to limit registration to only previously authorized parties. The method b= y which this access token is obtained by the registrant is generally out-of-= band and is out of scope of this specification.=E2=80=9D >>>>>=20 >>>>> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D= to =E2=80=9CSHOULD=E2=80=9D. >>>>>=20 >>>>> That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion token. >>>>> =20 >>>>> Again, disagree, for the same reasoning as above. >>>>> =20 >>>>> Same reasoning.=20 >>>>>=20 >>>>> I agree with Justin here. The default = should be that open registrations are enabled. The exception c= ase is that specific permissions are required to perform dynamic client regi= stration. >>>>>=20 >>>>> About section 4.3: >>>>> =20 >>>>> If the client does not exist on this server, the server MUST respond >>>>> with HTTP 401 Unauthorized, and the Registration Access Token used t= o >>>>> make this request SHOULD be immediately revoked. >>>>> =20 >>>>> If the Client does not exist on this server, shouldn't it return a "40= 4 Not Found"? >>>>>=20 >>>>> If revoking the registration access token, is it bound to a single cli= ent registration? This is not clear. What is the lifecycle around registra= tion access token? Only hint is in the Client Information Response in sectio= n 5.1. >>>>> =20 >>>>> The language about the 401 = here (and in other nearby sections) is specifically so that you treat a m= issing client and a bad registration access token the same way. You see, ret= urning a 404 here actually indicates things were in an inconsistent state. N= amely, that the registration access token was still valid but the client tha= t the registration access token was attached to doesn't exist anymore. The r= egistration access token in meant to be tied to a client's instance (or regi= stration), so it's actually more sensible to act as though the registration a= ccess token isn't valid anymore. In at least some implementations (specifica= lly ours at MITRE that's built on SECOAUTH in Java), you'd never be able to r= each the 404 state due to consistency checking with the inbound token. >>>>> =20 >>>>> Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begins= at the issuance of a new client_id with that instance. That token might be r= evoked and a new one issued on Read and Update = requests to the Client Configuration Endpoint (and the clie= nt needs to be prepared for that -- same as the client_secret), and it will b= e revoked when the client is deleted either with a Delete call to the Client= Configuration Endpoint or something happening out-of-band to kill the clien= t.=20 >>>>> =20 >>>>> Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sinc= e I don't think it's as clear as we'd like. >>>>> =20 >>>>> I think we should look at it. >>>>>=20 >>>>> For security reasons, it=E2=80=99s generally not good to distinguish b= etween =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors= in responses, as that can provide the attacker an oracle to probe whether a= particular entity exists I don= =E2=80=99t think a change is called for here. >>>>>=20 >>>>> About section 5.1: >>>>> Is registration_access_token unique? Or is it shared by multiple inst= ances? If shared, then registration_access_token can't be revoked on delet= e of client. >>>>> =20 >>>>> The registration_access_token is unique to a registered client, in the= RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do work o= n =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up= explicitly. >>>>>=20 >>>>> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_= expires_at=E2=80=9D,=20 >>>>>=20 >>>>> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at= =E2=80=9D >>>>> =20 >>>>> While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readabl= e, >>>>>=20 >>>>>=20 >>>>> I don't want to change the syntax during last call unless there is a c= lear need and a clear consensus for doing so. >>>>> =20 >>>>> That's why we are having last call. To confirm consensus on the draft.= =20 >>>>> =20 >>>>> Same reasoning as earlier. You now have multiple tokens (registration a= ccess and client) in play. The spec needs to be clear which one it is talkin= g about. >>>>> =20 >>>>> I'm fine with the suggested change but I would like more feedback from= other people before moving forward with it. There's a lot of value in "just= pick a name and ship it" as well though, and I don't want to devolve into b= ike shedding. (I'm not accusing you of bike shedding quite yet, btw, just af= raid of getting into a long debate on names.) >>>>> =20 >>>>> Again, this was a problem raised by people new to the specification. T= hey found it confusing. I tend to agree. We're not talking about what colour= to paint the shed. We're talking about whether the bike shed is a house. := -)=20 >>>>> =20 >>>>> I'm not too fussed about whether you call it "cl_sec_expiry" or "clien= t_secret_expires_at".=20 >>>>>=20 >>>>> If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_= at=E2=80=9D are unclear, we should clarify them. If you believe that this i= s the case Phil, can you supply proposed alternative definition text that is= clearer? That being said, I believe that at this point we should stick wit= h the existing protocol element names unless overwhelming working group sent= iment emerges to change them. They are already working fine as-is in produc= tion deployments. >>>>> =20 >>>>> Section 7 >>>>> =20 >>>>> When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret? >>>>> =20 >>>>> Yes, the client is supposed to either call the read or update methods o= n the client configuration endpoint to get = its new secret. As discussed above, I'm not sure that's= as clear as it needs to be, and I welcome suggestions on how = to clarify this. >>>>> =20 >>>>> Either is a reasonable behavior on the behalf of clients, depending up= on context. I support adding text to clarify this. >>>>> =20 >>>>> Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either = as-is or with any of your suggested changes? >>>>> =20 >>>>> Yes. Much of the feedback is coming from our development = community.=20 >>>>> =20 >>>>> Ah, very cool. Developer experience is the most valuable feedback, in m= y opinion. If you can't actually build the blasted thing, what good is it? := ) >>>>> =20 >>>>> Glad to hear that you=E2=80=99re working with developers building the s= pec. Please thank them for the feedback. >>>>> =20 >>>>> -- Justin >>>>> =20 >>>>> = Best wishes, >>>>> = -- Mike >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-AE4E88D8-635F-4B8C-A012-F8D96D3AD939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Justin,

Pleas= e re-consider what I was saying. You are not cnsidering what was known witho= ut reg and what is known after dyn reg. 

In pu= blic clients, you are changing the meaning of client_id. 
You are throwing away what was shared among all public clients (= a client id) running the same software. 

When y= ou issue a separate id you need to retain what was known before which was cr= itically important-a set of clients share the same software and thus behave i= n certain ways. 

Gaining a unique cred while l= osing information about what the software is makes dyn reg's value dramatica= lly reduced. 

Phil

On 2013-05-21= , at 6:46, Justin Richer <jricher@mi= tre.org> wrote:

=20 =20 =20
On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


=46rom the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be= expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
=
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case.


  http://blue-bu= tton.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:

And dynamic client registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case.

There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.
[JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 I was pretty fully engaged at= the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green=E2=80=A6
 
(Perhaps if any of you reply to this thread, you could also choose a distinct=  color for your inline replies, so that it will be easily evident who said what.  As i= t is, just the back-and-forth between Phil and Justin is already very difficult to follow. = ; Thanks.)
 
From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I thin= k we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put= together some intro text, etc.
 
 <= /div>
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.h= unt@oracle.com>
 wrot= e:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
&= nbsp;
Phil, many thanks for the extremely thorough review! It is very useful indeed. <= /div>
 
My comments and responses to each point are inline. 
 =
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt= @oracle.com> wrote:
 =
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall=  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:=
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should= clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. <= /o:p>
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first tim= e a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.<= /o:p>
 = ;
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 = ;
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)<= /div>
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I=E2=80=99= m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I=E2=80=99ll note that i= n RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If= we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It=E2=80=99s not the right p= lace to extend what an OAuth client is in new ways.
 
2.  How ar= e client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 =
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (=C2=A74.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. =
Something like this should be in the draft.
&nb= sp;
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 =
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 =
How does a client authenticate the first time and subsequent times to the registration service?
 =
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 =
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
=
 
Someth= ing like this should be in the draft.
 = ;
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in =C2=A73. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread =E2=80=9CClient Credentia= l Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D= .  I will work with Justin to apply these clarifications to the specification.  This may go int= o the proposed credential management overview section discussed above.
 
3.  How is= versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 =
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.=
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have= an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.<= /div>
 = ;
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  = ;
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I=  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it=E2=80=99s inappropriate t= o do so here.  We don=E2=80=99t need t= o boil the ocean.  If a new charter item i= s approved to do work on client instances and protocol elements to use and express them, that=E2=80=99s the= time for the working group to consider that possibility =E2=80=93 not a= s part of Dynamic Client Registration.
 
4.  What= is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?=
 
See the response above above and the definition in =C2=A71.2: =
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.<= /div>
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
&= nbsp;
Client=
 Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new regist=
ration.  The means of the Client
      obtaining the URL for this endp=
oint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2=
.0 Endpoint through
      which a specific Client can man=
age its registration information,
      provided by the Authorization S=
erver to the Client.  This URL for
      this endpoint is communicated t=
o the client by the Authorization
      Server in the Client Informatio=
n Response.
 
   o  Registration Access Token: An OAuth 2.0 B=
earer Token issued by the
      Authorization Server through th=
e Client Registration Endpoint
      which is used by the Client to a=
uthenticate itself during read,
      update, and delete operations.&=
nbsp; This token is associated with a
      particular Client.
 = ;
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I= think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method= is one thing that should not be negotiated per instance.
=
 =
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_m= ethod" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 =
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The= role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?<= /o:p>
 = ;
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 = ;
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent= that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So wh= y negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.<= /div>
 =

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery= protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 <= /span>
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I=E2=80=99ll work w= ith Justin to make sure that this is as clear as possible in the specification.<= /span>
 
Finally, there seems to be an inconsistent style approach with dra= ft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 =
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. <= /o:p>
&= nbsp;
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In th= e design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.<= /o:p>
 = ;
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in =C2=A74.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
=
ETags seem like an unnecessary addition (and potential complication) to the specification.  It=E2=80=99s already working fine as-is.
 
=
Specific items:
-----------------= ----
"token_endpoin= t_auth_method"
 =
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_aut= h_method"
 =
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind= shorter names (maybe not quite as short as the JOSE stuff ;-)
 = ;
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I=E2=80=99m fine clarify= ing the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I=E2=80=99m not OK revis= ing the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 =
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =C2=A72, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.=
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.=
 = ;
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
=
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it=E2=80=99s currently written.  The a= uthors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification. = I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
=
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *= is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server. = ; That should be explicitly out of scope.
 
=
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the =E2=80=9Cse= rvice documentation=E2=80=9D (RFC 6749, Sections 3= .1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/s= pecs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).=
 
=
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group=E2=80=99s set of deliverables. = I would support doing this work and the necessary rechartering to do so.
 
=
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is= for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That=E2=80=99s a clean separatio= n.  We should strongly resist muddying the two functions.
 
=
OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same =E2=80= =93 focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
=
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I=E2= =80=99m sure that many of the current questions and confusions would not have arisen.  I think we=E2=80=99d as= sumed that this was obvious, but from the current discussions, it=E2=80=99s apparent= that it=E2=80=99s not obvious.  I wil= l personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
=
Getting back to the specifics, the only useful purpose of a multi-valued =E2=80=9Ctoken_endpo= int_client_auth_method=E2=80=9D member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But= that is a discovery function, and so should be part of the discovery work =E2=80= =93 not this specification.  We should resist shoehorning in bits of discovery into this specification.  I= t *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
=
* There is no authn method for "client_secret_saml" or "private_key_saml".
 =
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_j= wt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.=
 =
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.=
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that i= f a client has the assertion it has the right to present it.  IOW. The JWT= Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 = ;
I think I see the point that you're making now, let me try to re-state it:
 = ;
While the basics of "how to present a JWT as a client credential" is defined here: http:/= /tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 = ;
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the beare= r drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer= specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 =
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is= NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. = ;

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 =
That's possible, but they are in active use already. <= /div>
 =
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
&nb= sp;
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"<= /o:p>
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 =
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.=
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.=
&nb= sp;
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 =
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.<= /o:p>
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
&nb= sp;
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http:= //tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. =
 =
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?=
 =
See above. :)
 
Agreed on adding this reference.
 <= /span>
Section 2.1
 
In the table urn= :ietf:params:oauth:grant-type:jwt-bearer
is missing.
 =
It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80=A6 ?
'
Sorry I meant: urn:ietf:params:oaut= h:grant-type:saml-bearer
&nb= sp;
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
=E2= =80=9CAs such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (=E2=80=9Cinvalid_cl= ient_metadata=E2=80=9D)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6 = ; I=E2=80=99ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2=
 =
May want to add:<= /o:p>
 =
When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en= =E2=80=9D is missing in =E2=80=9Cclient_na= me=E2=80=9D, instead of =E2=80=9Cclient_na= me#en=E2=80=9D) the OAuth server may use interpret the language used based on= server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.=
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.<= /div>
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passe= s a single value for that registration?
&nb= sp;
&nb= sp;
No, the client should pass parameters as multiple separate values. Connect has this in its example:
&nb= sp;
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=
=90=8D",
Should= we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.<= /o:p>
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
&= nbsp;
Passin= g in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. <= /o:p>
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  I= f the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?<= /div>
 
Without specific proposed text changes to review, it=E2=80=99s= hard to know what to think about this comment.  Unless a specifi= c proposed text change is sent to the list with clear rationale for why it=E2=80=99s better than wha= t=E2=80=99s there now and reviewed by the working group, I don=E2=80=99t belie= ve we should change the specification in response to this comment.
 
Section 3=
 
Existing text:

=E2=80=9CIn order to support open registration and facilitate wider interop= erability, the Client Registration Endpoint SHOU= LD allow initial registration = requests with no authentica= tion.  These requests MAY be rate-limit= ed or otherwise limited to prevent a denial-of-service attack on the Client&nb= sp;Registration Endpoint.=E2=80=9D=

I would suggest to change the first =E2=80=9CSHO= ULD=E2=80=9D to =E2=80=9CMAY=E2= =80=9D.   In most cloud services, the first client is registered= by a human user. Then, other clients= can be further used to automate othe= r client registration. = ; So, the first request= would typically come with an authenticated user identity. 
 =
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. =
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
=
&nb= sp;
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

=E2=80=9CThe Client Registration Endpoint MAY accep= t 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.=E2=80=9D=

I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D to =E2=80= =9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 =
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled. = The exception case is that specific permissions are required to perform dynamic client registration.<= /span>

About section 4.3:
=
 
<=
span style=3D"font-size: 12pt; ">If the client does not exist on this server=
, the server MUST respond
<=
span style=3D"font-size: 12pt; ">   with HTTP 401 Unauthorized, an=
d the Registration Access Token used to
<=
span style=3D"font-size: 12pt; ">   make this request SHOULD be im=
mediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.<= /o:p>
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here= actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.<= /div>
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it=E2=80=99s generally n= ot good to distinguish between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D e= rrors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I= don=E2=80=99t think a change is called for here.

About section 5.1:
=
Is registration_acces= s_token unique?  Or i= s it shared by multiple instances?   If shared, then registration_acces= s_token can't be revoked on delete of client.=
 = ;
The registration_acces= s_token is unique to a registered client, in the RFC 6749 sense of =E2=80=9Cclient= =E2=80=9D.  Again, if we want to do work on =E2=80=9Cclient instances=E2=80=9D= , we need to recharter and take this distinct work item up explicitly.

Suggest rename =E2=80=9Cexpires_a= t=E2=80=9D to =E2=80=9Cclient_se= cret_expires_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at= =E2=80=9D to =E2=80=9Cid_issued= _at=E2=80=9D
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,=


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's= why we are having last call. To confirm consensus on the draft. 
&= nbsp;
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
=
 = ;
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Ci= ssued_at=E2=80=9D are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
=
Section 7=
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.<= /span>
&nb= sp;
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
&nb= sp;
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?=
 
Yes. Much of the feedback is coming from our development community. 
 = ;
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you=E2=80=99= re working with developers building the spec.  Please thank them fo= r the feedback.
 
 -- Justin
=
 
     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;    Best wishes,
=
     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;    -- Mike




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


=20
= --Apple-Mail-AE4E88D8-635F-4B8C-A012-F8D96D3AD939-- From phil.hunt@oracle.com Tue May 21 08:00:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90C221F9859 for ; Tue, 21 May 2013 08:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7e9cAhxhvj for ; Tue, 21 May 2013 08:00:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12321F97C4 for ; Tue, 21 May 2013 08:00:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4LF0j7n012114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 15:00:46 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LF0ioB011758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 15:00:44 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LF0hOq004979; Tue, 21 May 2013 15:00:43 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 May 2013 08:00:34 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519B7AA5.3070908@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-C953F08C-71C1-4A15-9C49-1BE868B37EC9 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 21 May 2013 08:00:29 -0700 To: Justin Richer X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 15:00:49 -0000 --Apple-Mail-C953F08C-71C1-4A15-9C49-1BE868B37EC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding charter.=20 The charter is a one-liner. To say associating clients is not in the charter= while saying every other 'new' thing that is in the spec (eg client auth ty= pe) is in is laughable. After all the entire draft is new functionality.=20 The item i have asked for is not new. It preserves information that was avai= lable without reg. Namely a way to recognize multiple clients as a common pu= blic client as in 6749 they share a client_id. The draft throws this inform= ation away preventing security admins from making any judgements since all c= lients are now anonymized. Where in the charter does it say you can anonymize the clients?=20 Phil On 2013-05-21, at 6:46, Justin Richer wrote: >=20 > On 05/21/2013 02:01 AM, Phil Hunt wrote: >>=20 >>=20 >> Phil >>=20 >> On 2013-05-20, at 8:35, Justin Richer wrote: >>=20 >>>=20 >>> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>>> Mike, >>>>=20 >>>> Rather then embed comments in an extended thread, I'd like to open up a= specific discussion on the objective of dyn reg. >>>>=20 >>>> I see limited to no value in having clients completely anonymously regi= stering and receiving tokens without any ability to correlate applications b= etween applications.=20 >>>=20 >>> I think that herein lies a very big disconnect in assumptions. I see a h= uge benefit in anonymously registered clients getting tokens because there i= s an end-user in the loop during the authorization phase (long after registr= ation has happened). The arity of registrations to authorizations approaches= 1:1 in these cases, and I'm just fine with that. >> Then what you describe is NOT anonymous but rather a profile not cove= red by the spec as there is no discussion of user authenticated registration= . Implicitly or explicitly. >=20 > [JR] I think you misunderstand what I said, let me try to be more explicit= : the user is not authenticating the registration. The user is not involved i= n the registration. The user might not even know that a registration happene= d. The registration is (normally) completely anonymous and open, the client j= ust shows up and says "Hi, I'm a client!".=20 >=20 > The "authorization" that I mentioned happens later and is a normal OAuth a= uthorization, which has a user involved like usual. The authorization step i= n OAuth depends on *some* kind of registration happening beforehand, dynamic= or otherwise. This is all perfectly within the model of OAuth.=20 >=20 >>>=20 >>> =46rom the RFC6749 perspective, a "client" is not a particular piece of c= ode, it is a particular copy of a piece of code with a particular client_id f= rom the vantage point of a particular authorization server. >> actually, i disagree. This spec fundamentally breaks the old definit= ion and behavior from 6749. In the old way every instance of software shared= a client_id. In this draft, u throw that away without preserving the inform= ation. This is BAD! > [JR] No, we're not throwing that away at all. The concept is the same, but= when you add new functionality, the mechanics change a bit. A "client_id" w= as always pairwise between a client and an AS. If a client had to talk to tw= o AS's before, it would have two client_ids. That's still the case. If there= were multiple copies of a confidential client, you need to get a client_id a= nd client_secret to each copy. That's still the case. What's different is th= at we've made it *easier* for a particular piece of code to get differen= t client_ids when it's talking to the same or a different auth server, at ru= ntime. When you have to manually register every client, you're going to just= do it once. If you can do it dynamically, you have more options.=20 >=20 > Note that you can *still* have a public client with a known client_id if y= ou want to. You don't even need to use dynamic registration for that. Heck, y= ou don't need to use dynamic registration for any kind of client if you don'= t want to, since most services will probably still offer manual registration= through some portal kind of page. >=20 >>=20 >>=20 >>> A "client" is, conceptually, a pairwise association between two running c= odebases. When you have a particular piece of code talking only to one auth s= erver and being manually configured at said auth server with its client_id, t= his is fairly clear and straightforward and the arity is simple. Things get a= bit muddy when you introduce dynamic registration, which is why I think tha= t we need to have introductory text about this. Specifically: >>>=20 >>> - a particular piece of code can be run on multiple devices and talk to= the same auth server, each copy of that code getting its own client_id.=20 >>> - a particular copy of a particular piece of code can now be expected t= o talk to multiple auth servers, each auth server giving the piece of code i= ts own client_id.=20 >>>=20 >>> Both of these are cases of what defines an "instance" in most people's h= eads, even though it's the same software, even sometimes the same running co= py of the same software. But as far as RFC6749's definition of "client" is c= oncerned, these are all completely separate "client"s with no way to tie the= m together out of the box. And that's fine. >>>=20 >>>>=20 >>>> Associating client_id's with known client applications to allow admins t= o know who is running what version of clients seems to be the most fundament= al part of the reason for dynamic reg. How can you revoke access to particul= ar client app types? As Justin already talked about in his Blue Button+ sce= nario, there are often life and death situations where particular sets of cl= ients need to be revoked.=20 >>> While it's very useful, I wouldn't (and haven't) classified it quite lik= e that. Nor would I say that the BB+ profile is a complete solution -- our R= egistry component does not actually push revocation notifications down to Pr= oviders (yet), so it's more like invalidating a root certificate and waiting= for caches to time out for things to cascade. We've been talking about addi= ng some form of callback to providers, but we don't want to boil that partic= ular ocean right now. However, the BB+ profile makes use of a well-specified= discovery and Registry set up, as well as data conveyed in structured, sign= ed tokens (JWTs) at different points in the process. >>>=20 >>>>=20 >>>> Or put another way. I believe this will be a critical operational requi= rement going forwards. If the spec is published as is, it will be quickly in= validated by one that does at least partially address the problem. >>> That's not true at all. BB+ addresses this scenario and still uses the D= ynamic Registration spec as-is. I would encourage folks to read what we're d= oing, a work-in-progress found here: >> but you are breaking other things and overloading client cred etc to= pass in signed data. I don't want a hack for a solution. I want interop. > [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks c= ompatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix= there. It is our intent to be fully compatible with OAuth Dyn Reg, and we a= re even explicitly calling for open registration as mandatory to impleme= nt for authorization servers within BB+, even though we have additional mech= anisms as well for what we're calling "trusted registrations". For those tru= sted registrations, we're not using the client *credentials* to pass in sign= ed data, we're using the initial *registration authentication* mechanism (wh= ich is to say, an OAuth token) for its intended purpose: authorizing the hol= der of this token access to the registration endpoint. In BB+, we're profili= ng exactly what that means. To wit, we define the content of the token (whic= h is fully compatible with DynReg which doesn't care what's in the token) an= d how the AS can verify it (which DynReg doesn't care how it happens) and we= 've added some additional rules and policies that allow us to tie together i= nstances of the client across the distributed network.=20 >=20 > So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge am= ount of very specific machinery (signed tokens with known formats and fi= elds, a Registry with manual pre-registration, a three-tiered discovery serv= ice with information about clients and service providers rooted at the Regis= try, trust frameworks and network enforcement policies that all players have= to agree to before playing, etc.), and it's not really doing just registrat= ion anymore. In BB+, we needed the Registry and Discovery services to do oth= er functions as well apart from just registration, and so it makes sense to r= e-use them.=20 >=20 > If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced tha= t a good solution for managing client instances across a network requires a l= ot more thought and consideration, and I believe that having a fully specifi= ed discovery service will help this case, like it has helped in BB+. But I t= hink that it's a complex enough problem that it needs its own set of conside= rations. With DynReg, we need to leave things open for that work in the futu= re, and I believe we have, but we shouldn't kill the simple, general case fo= r want of a special case.=20 >=20 >>>=20 >>> http://blue-button.github.io/blue-button-plus-pull/ >>>=20 >>> Just because you make something better doesn't mean you throw necessaril= y away everything you've done to date. >>>=20 >>>>=20 >>>> We're ahead of schedule, lets talk through the requirement. >>> I believe that the requirement of tying instances together is explicitly= out of scope for the dynamic registration protocol. I intended to have text= to that effect in the section I'm adding about the client lifecycle. >>=20 >> where is this stated in charter? > [JR] The charter for the working states what's in scope, not what's out of= scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abou= t registration is this: >=20 > And dynamic client registration will make > it easier to broadly deploy OAuth clients (performing services to > users). >=20 > And:=20 >=20 > Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG f= or consideration as a Proposed Standard > There's nothing in there at all about tying together client instances. I h= ave not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client r= egistration. It sounds very likely to me that it *is* required for your u= se case, but that doesn't make it required for everybody's use case.=20 >=20 > There are other important pieces of functionality that the WG isn't pickin= g up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for those= to be separate modules. >=20 >>>=20 >>>>=20 >>>> As I mentioned in my comments to the other thread. Let's say we agree n= ot do this now. Well, then the new draft that does solve it would likely be 9= 5% overlap. Thus I see this issue as within charter and should be solved no= w rather then waiting for a V2 dyn reg in the next charter. >>> Why wouldn't the new draft just be the extra 5%? I personally think that= it's a lot more than 5% once you have in all the assurance and safety mecha= nisms in place to avoid self-asserted values causing race conditions, and wh= at not. >>=20 >> Two drafts to do registration is not the way to go. It implies compl= exity where there should be none. There is no technical reason for two draft= s. > [JR] There is a need when there's a special case that requires a large amo= unt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today).=20 >=20 >>>=20 >>> -- Justin >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>>>=20 >>>>> Thanks for the detailed feedback, Phil. Sorry for the delayed respons= e =E2=80=93 I was pretty fully engaged at the European Identity Conference (= where OAuth 2.0 won the award for best new standard J). My feedback on the p= oints raised is inline in green=E2=80=A6 >>>>> =20 >>>>> (Perhaps if any of you reply to this thread, you could also choose a d= istinct color for your inline replies, so that it will be easily evident who= said what. As it is, just the back-and-forth between Phil and Justin is al= ready very difficult to follow. Thanks.) >>>>> =20 >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of Phil Hunt >>>>> Sent: Thursday, May 16, 2013 12:54 PM >>>>> To: Richer, Justin P. >>>>> Cc: oauth@ietf.org WG >>>>> Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-1= 0 >>>>> =20 >>>>> Justin, >>>>> =20 >>>>> Thanks for the discussion. More comments below... >>>>> =20 >>>>> BTW. I'm happy to contribute text. Just want to get to some rough agre= ement first. For example, I think we need to have a away to recognize two p= ieces of software as being the same (even if self-asserted). Once defined, I= can put together some intro text, etc. >>>>> =20 >>>>> Phil >>>>> =20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> =20 >>>>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>>>> =20 >>>>> On May 15, 2013, at 10:30 PM, Phil Hunt >>>>> wrote: >>>>> =20 >>>>> On 2013-05-15, at 5:53 PM, = Richer, Justin P. wrote: >>>>> =20 >>>>> Phil, many thanks for the extremely thorough review! It is very useful= indeed.=20 >>>>> =20 >>>>> My comments and responses to each point are inline.=20 >>>>> =20 >>>>> On May 15, 2013, at 4:30 PM, = Phil Hunt wrote: >>>>> =20 >>>>> It seems unfortunate that I have not gotten a chance to get into this l= evel of detail much earlier. But then, I guess that's what LC review = is for! My apologies for no= t getting many of these concerns to the WG much earlier. >>>>> =20 >>>>> Overall =20 >>>>> ----------- >>>>> I think dynamic registration is a critical part of the OAuth framework= now that we are starting to consider how individual client applications sho= uld operate when there is one or more deployments of a particular resource A= PI. We've moved from the simple use case of a single API provider like Faceb= ook or Flickr and moved on to standards based, open source based, and commer= cial based deployments = where there are multiple service endpoints and many clients to manage. >>>>> =20 >>>>> The dynamic registration spec is actually dealing with a couple of iss= ues that I would like to see made more clear in early part of the spec: >>>>> =20 >>>>> 1. How is a new client application recognized for the first time when= deployed against a particular SP endpoint? Should clients actually assert a= n application_id UUID that never changes and possibly a version id that does= change with versions? >>>>> =20 >>>>> In the general case, why is any recognition required? If you're = doing things as part of a larg= er protocol ecosystem, like Blue Button+ or a particular OpenID = Connect provider, then you can defin= e semantics for tying together classes of clients (see below for more discus= sion on this very point). But in general, a client is just going to show up a= s a new instance to the AS = and get issued a new, unique client_id, and that's that.=20 >>>>> =20 >>>>> I think we have to define more = clearly what an "instance" is. For me, there are applications and there a= re instances of that application. It is useful to understand that a client a= pplication represents a set of code that should behave in a consistent way. = It seems to me the first time a new application shows up is very different f= rom the subsequent instances that register. For example, after the first reg= istration, subsequent instances don't need special review or approval to the= same degree. >>>>> =20 >>>>> But without other mechanisms to tie things together, there's no way fo= r an authorization server to know if any client instance is tied to any othe= r client instance. Therefore, from the perspective of an AS, the first insta= nce of an application (i.e., particular configuration of a set of code) to r= egister is no different to subsequent instances of that same application. Ho= w were you envisioning an AS knowing the = difference between the first and subsequent instances of an = application, specifically? If there's an "applicati= on_id" like you mention above, I think= it raises more questions than it resolves: Who issues the application_id, s= ome server or the application itself? Is it validated at all? Should it be c= onsidered secret? What happens when someone simply steals an application_id?= Does an AS have to do anything to check with any other AS to see if the app= lication_id has already been used elsewhere? >>>>> =20 >>>>> I do agree that a discussion of "instance vs. application" would be he= lpful in clearing this up, I'll make a note to add text to that effect. (We h= ad to do something similar for BB+) >>>>> =20 >>>>> I think it is simple enough to at least add a self generated UUID for t= he application ID. Though I would allow for cases where the application ID i= s assigned when the client developer and the APIs owner do a formal assignme= nt of application IDs. >>>>> =20 >>>>> In a sense this is just a lower tech way of doing it than what = you described as the initial client credential in= Blue Button+ where you encoded extra claims into the initial app credential= . >>>>> =20 >>>>> What the UUID does is link multiple instances of a client app together= as the same "thing" that should have similar heuristics/behaviours. This i= s very useful if you want to be able to revoke access to a set of clients id= entified by application id (or a version of that app). >>>>> =20 >>>>> While I=E2=80=99m sympathetic to the OAuth working group eventually do= ing work on differentiating between instances of an OAuth client, I=E2=80=99= ll note that in RFC 6749 or RFC 6750 there is no such thing as a client inst= ance. There are only clients, which are identified by client_id values. If= we want to do work on client instances, we should recharter to add this new= work as a working group deliverable. We should not try to shoehorn bits an= d pieces of it into the Dynamic Registration spec, any more than we should h= ave tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is there t= o register clients as defined in RFC 6749. It=E2=80=99s not the right place= to extend what an OAuth client is in new ways. >>>>> =20 >>>>> 2. How are client credentials managed. Are we assuming client credent= ials have a limited lifetime or rotation policy? >>>>> =20 >>>>> The intent was that client_secret could be rotated, as indicated by th= e expires_at member of the r= esponse. If a client's secret expires, it calls the read operation on the Cl= ient Configuration Endpoint (=C2=A74.2) to get its new client_secret. If thi= s is unclear in the current text (which I suspect it may be after multiple r= efactorings), then I welcome suggestions and specific text as to how to make= that clear.=20 >>>>> Something like this should be in the draft. >>>>> =20 >>>>> Should this be up in the introductory text, somewhere else, or have it= s own section? >>>>> =20 >>>>> I'm starting to think credential management is a key part of the draft= . It may be worth introducing a specific section outling the registration li= fe-cycle, registration access token usage, and client token usage and bootst= rapping. >>>>> =20 >>>>> I think that adding a discussion on this would be fine, as it could he= lp developers understand the workflow of registering, using, and updating re= gistered clients. >>>>> =20 >>>>> How does a client authenticate the first time and = subsequent times to the registration service= ? >>>>> =20 >>>>> This is a separate question all = together, as it does not involve the client_secret or client_id a= t all. Rather, the first time the client shows up to the registration servic= e, it may either: >>>>> - Not authenticate at all (this is the true public, open registratio= n, and it is recommended that servers do this) >>>>> - Authenticate using an OAuth 2.0 token (which ATM means a bearer tok= en). How the client gets that bearer token and what the bearer token means t= o the AS beyond "this clie= nt is authorized to register" is out of scope for the spec, by design. >>>>> =20 >>>>> Subsequent times that the same registered client (by which we mean the= same instance of a client with a particular client_id) shows up at the regi= stration endpoint (actually, the Client Configuration Endpoint), it uses its= Registration Access Token that it was issued on initial registration. This i= s an OAuth 2.0 Bearer token that is unique to the client instance. >>>>> =20 >>>>> Something like this should be in the draft. >>>>> =20 >>>>> OK, the definition of the registration access token can be expanded, b= ut I think that the rest of it is already in there in =C2=A73. I'd welcome s= uggestions on which bits of this could be made clearer. >>>>> =20 >>>>> See the discussion on what the registration_access_token is in the thr= ead =E2=80=9CClient Credential Expiry and new Registration Access Token - dr= aft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin to apply these c= larifications to the specification. This may go into the proposed credentia= l management overview section discussed above. >>>>> =20 >>>>> 3. How is versioning of clients managed? Should each new version of a= client require a change= in client registration including possibly changing client_id = and authentication credential? I don't= have a strong feeling, but it is something that implementors should conside= r. >>>>> =20 >>>>> This is up to the AS, really, = and I don't think that any global policy would ever fly here. Especi= ally if you consider that the entire notion of "version" is more fluid these= days than it ever has been. I wouldn't mind adding a discussion in the secu= rity considerations if it merits mentioning though, so that we can help both= client developers and server developers institute reasonably good policy. >>>>> =20 >>>>> I guess the issue is that when a = client upgrades it may have access to the old credentials. What is the i= ntent then of registration. Since you have an update are clients expected t= o update /re-register or not? I'm not sure this is a security consideration= but more part of the whole change management function dynamic registration s= upports. >>>>> =20 >>>>> If your upgraded version of the c= lient still has access to its old credentials, why wouldn't it just use thos= e? I don't see a reason for forcing a re-registration. Nor do I see any way t= hat an AS would even be able to tell that a client had been upgraded. An upg= raded client always has the *option* of re-registering itself and getting a n= ew client_id.=20 >>>>> I think the concern here is that rotation of client credential is not s= omething discussed before. Before we put it in the spec we should consider t= he reasons for doing it and what problems it solves. >>>>> =20 >>>>> I think this may be just a case of letting people exchange credentials= for whatever reason they feel is appropriate. The version upgrade thing su= ggests that when a client is upgraded it should go to the registration serve= r to "re-register". Depending on the policy of the = server, it may (or may not) receive a new client_id and/or new cre= dential. =20 >>>>> =20 >>>>> One of the best benefits I can think of is if you discover a version o= f a client has a problem, being able to select a group of clients by softwar= e and version is important. Thus if client_id doesn't trace to a particular s= oftware and version, that makes it hard to do. I think you talked about th= is as an issue for Blue Button+ >>>>> =20 >>>>> Again, RFC 6749 defines no client instances or groups of clients, ther= efore I believe that it=E2=80=99s inappropriate to do so here. We don=E2=80= =99t need to boil the ocean. If a new charter item is approved to do work o= n client instances and protocol elements to use and express them, that=E2=80= =99s the time for the working group to consider that possibility =E2=80=93 n= ot as part of Dynamic Client Registration. >>>>> =20 >>>>> 4. What is the registration access token? Why is is used? What is its= life-cycle? When is it issued, when is it changed? When is it deleted? >>>>> =20 >>>>> See the response above above = and the definition in =C2=A71.2:=20 >>>>> =20 >>>>> Registration Access Token: An OAuth 2.0 Bearer Token issued by the Aut= horization Server through the Client Registration Endpoint which is used by t= he Client to authenticate itself during read, update, and delete operations.= This token is associa= ted with a particular Client. >>>>> =20 >>>>> If this can be clarified, I welcome text suggestions. >>>>> =20 >>>>> The latter part of 1.2 didn't seem like terminology but rather archite= cture or part of the introduction that describes what the spec does. The thi= rd point doesn't seem to fit with the other two except to say that the dynam= ic registration endpoints use their own access = tokens called registration access tokens. >>>>> =20 >>>>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>>>> a Client can request new registration. The means of the Client >>>>> obtaining the URL for this endpoint are out of scope for this >>>>> specification. >>>>> =20 >>>>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>>>> which a specific Client can manage its registration information,= >>>>> provided by the Authorization Server to the Client. This URL fo= r >>>>> this endpoint is communicated to the client by the Authorization= >>>>> Server in the Client Information Response. >>>>> =20 >>>>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by t= he >>>>> Authorization Server through the Client Registration Endpoint >>>>> which is used by the Client to authenticate itself during read, >>>>> update, and delete operations. This token is associated with a >>>>> particular Client. >>>>> =20 >>>>> This section is meant to just introduce the new terms that are then ex= plained in greater detail throughout the rest of the = document. Yes, it's a bit architecture, but only in the sense= that you need to define the terms that make up your architecture. How would= you suggest that it change? >>>>> =20 >>>>> Probably this is more a matter of style. But, what happened for me is= I naturally skipped the terminology section, as I wasn't expecting protocol= components to be there. "terminology" is something I think people tend to u= se as a dictionary rather than as protocol component description. Maybe the= chairs can advise? >>>>> =20 >>>>> If we distinguish between first time registration of a particular clie= nt software package, it is possible that somethings like authentication meth= od can be negotiate in or out-of-band at that time. Subsequent registrations= should only have parameters for items that could change per deployment (lik= e tos_uri). I think token_endpoint_auth_method is one thing that should not= be negotiated per instance. >>>>> =20 >>>>> When subsequent instances = register, I have to ask the question, for example when would thing= s like "token_endpoint_auth_method" be negotiated or be different for the sa= me client software? Sh= ould not all instances use the same authentication method. >>>>> =20 >>>>> I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change pe= r instance. And instance, you should keep in mind, is defined as any one cop= y of the client code connecting to any new authorization server. That pairin= g creates the client_id, and therefore the = instance, and therefore the registration access token, and th= erefore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_au= th_method. Where else would the AS find out about it? >>>>> =20 >>>>> We still disagree on this. It is my assertion that clients should NEVE= R ask for a particular token auth method. Since it is the AS that is authent= icating the client, then it is the AS's right to set the authentication poli= cy. The role of dynamic reg endpoint = is to inform the client what it must do. My assumption is that during= the first time a piece of software is registered (the first instance), ther= e could be some OOB discussion by an = administrator to approve the = particular authentication type for the AS in question. >>>>> =20 >>>>> I haven't heard a reason justifying this parameter other then "it is n= eeded". Why? >>>>> =20 >>>>> The role of the dynamic registration protocol is twofold: half of that= is the server informing the client what it must do. But the other half is t= he client informing the server what it= *can* do, or what it *wants* to do.=20 >>>>> =20 >>>>> And again, there's no way to distinguish a first instance from a subse= quent instance unless you're doing something in addition. Nothing is stoppin= g the same application from registering a new instance of itself for every s= ingle user or every single token that it wants to get access for. That's com= plicated and wasteful and not a great idea, sure, but there's no useful way= to prevent that kind of behavior if you also want open registration of clie= nts.=20 >>>>> =20 >>>>> I think we've discussed how recognizing subsequent instances is easily= done. >>>>> =20 >>>>> As I mentioned in the other thread, if a developer chooses to limit th= e capabilities of the client it must do so by looking to the developer or st= andard behind the API. Otherwise they are taking the chance. There's no wa= y a developer can query all the potential deployers to ask what authn types w= ill you use. As I said, the net effect in the absence of an API standard dic= tating what should be supported, the developer will have to implement all me= thods. >>>>> =20 >>>>> My point here is that none of this is helped by the client app saying w= hat it supports. A developer who takes the route of limiting implementation t= akes the chance that the server will not accept. So why negotiate within re= gistration? >>>>> =20 >>>>> And there's no way other than per-instance for the server to tell the c= lient which token_endpoint_auth_method to use. All instances will probably a= sk for the same token_endpoint_auth_method from all auth servers they talk t= o, right? And each AS will tell each instance that registers with it to use a= particular auth method. There is no way to tie together different instances= across (or within) auth servers without specifying a significant amount of o= ther machinery. >>>>> =20 >>>>> Which is not to say that it's = not useful in some circumstances to tie together different instances= of the same code across (or within) auth servers. This is why, with Blue Bu= tton+, we specified a specific token format for the initial access token tha= t the clients use to call the registration endpoint the first time, as well= as a discovery protocol against a centralized server that handles pre-regis= tration. All of this machinery is, in my opinion, a stupendous overkill for t= he general case, though if some folks find use for it outside of BB+ then it= 'd be a good thing to abstract out and make its own spec that extends the Dy= n Reg spec in a fully compat= ible way. Furthermore, even in Blue Button+ we specify that all auth servers= MUST also accept open registration, without an initial access token, where t= he client simply shows up and says "hey, here are my parameters." The auth s= erver has no way to know in this case any kind of out-of-band negotiation fo= r different things. In BB+ w= e are writing very specific policy guidelines about how to present the UX an= d things to the end user for= all of these different cases. But again, all of this is specific to the BB+= use case, and I don't see value in dragging it in to the registration spec o= n its own. I believe it would be far too limiting. >>>>> =20 >>>>> See my previous comments on differentiating client instances being out= of scope without rechartering to do this new work and on what the registrat= ion_access_token is. In short, the registration_access_token is an RFC 6750= bearer token issued to the party registering the client, enabling it to sub= sequently retrieve informa= tion about the client registration and to potentially update the registratio= n information for that registered client. Again, I=E2=80=99ll work with Jus= tin to make sure that this is as clear as possible in the specification. >>>>> =20 >>>>> Finally, there seems to be an inconsistent style approach with draft-h= ardjono-oauth-resource-reg which uses ETags. Should this draft do so as well= ? >>>>> =20 >>>>> That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource r= egistration draft comes from) uses ETags, hence their inclusion there. I per= sonally don't see their utility here, though, and I wouldn't want to include= a wholly new mechanism this late. >>>>> =20 >>>>> Yes. Thomas' draft is not a WG document. But that doesn't = mean he doesn't have a point. It's worth discu= ssing.=20 >>>>> =20 >>>>> One could argue that the point of an ETag is that it is useful for cha= nge detection when there are multiple writers to a particular resource. In t= he design of dynamic registration e= ndpoint, there should only be one w= riter -- the client. This is an important observation. >>>>> =20 >>>>> There are other mechanisms that handle this -- namely, the registratio= n access token and the client_id. Many instances include the client_id in so= me form in the client configuration endpoint's URL for sanity checking, as d= escribed in =C2=A74.1.=20 >>>>> =20 >>>>> If everyone agrees, I'm in agreement. But it will likely mean changes f= or the resource reg draft if adopted. >>>>> =20 >>>>> ETags seem like an unnecessary addition (and potential complication) t= o the specification. It=E2=80=99s already working fine as-is. >>>>> =20 >>>>> Specific items: >>>>> --------------------- >>>>> "token_endpoint_auth_method" >>>>> =20 >>>>> There is some confusion as to = whether this applies to server or client authentication. Suggest r= enaming parameter to "token_endpoint_client_auth_method" >>>>> =20 >>>>> This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes without= very, very compelling reaso= ns to do so. >>>>> =20 >>>>> The question was raised to me by some new developers. It seems obvious= to us as experienced OAuth persons, but to new developers it seems unclear.= Also, now that you are introducing registration authentication, the whole t= hing gets very confusing. So it is useful disambiguate all the parameters wh= ere possible. That said, I wouldn't mind shorter names (maybe not quite as s= hort as the JOSE stuff ;-) >>>>> =20 >>>>> Fair enough, but again, I only want to do syntax changes if the rest o= f the WG *really* wants to. >>>>> =20 >>>>> I agree with Justin here. I=E2=80=99m fine clarifying the description= of this parameter to resolve the potential ambiguities that you cite, Phil.= I=E2=80=99m not OK revising the syntax without a compelling reason to do s= o. >>>>> =20 >>>>> * Currently, the API only supports a single value instead of an array.= If the purpose is to allow the client to know what auth methods it = supports, this should be an array= indicated what methods the client supports - or it should not be used. >>>>> =20 >>>>> I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it wa= s decided that a single value was simpler and sufficient for the purpose. Th= e IETF draft has inherited this decision. I *believe* (though am not 100% po= sitive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. >>>>> =20 >>>>> I can get behind multiple values. In this case, it changes the meaning= of the parameter. Instead of the client forcing the server to use a particu= lar method, the client is informing the server about what methods it can per= form. This allows the server to as= sign the appropriate method based on its own policy. >>>>>=20 >>>>> Also note that this field, like all others in =C2=A72, represents two t= hings: the client telling the server "I want to use this value for this fiel= d", and the server telling the client "this = is the value you have for this field". It's not exactly a nego= tiation, more like making a polite request to an absolute dictator who has t= he last word anyway. But at least this dictator is nice enough to tell you w= hat their decision was instead= of just decapitating you. >>>>> =20 >>>>> This is the heart of my objection. This fuzziness is is going to lead t= o interop issues. >>>>> =20 >>>>> There is no fuzziness that I can see here. It's parallelism between wh= at goes in to the endpoint and what comes out of it. The semantics for the r= equest and the response are different, and differentiable by the fact that o= ne is a request and the other is a response.=20 >>>>> =20 >>>>> The inter-op issue I would like to point out is that the spec does not= currently specify if particular input values are singular or multiple. If a= n implementer assumes singular and clients assume multiple, we have issues. >>>>> =20 >>>>> The multiple/single discussion above gets to the heart of what I *do* b= elieve is a deficiency in the specification, as it=E2=80=99s currently writt= en. The authors, myself included, have failed to make it 100% clear that di= scovery of Authorization Server functionality is out of scope for this speci= fication. I strongly believe that we need to add a clear statement to this e= ffect in the introduction to the specification. >>>>> =20 >>>>> The purpose of the Dynamic Client Registration specification is for th= e client to register with the Authorization Server and to inform it of prope= rties of the client that the AS may want/need to be aware of. It *is = not* the purpose of this specification for it t= o be used by clients in any manner to discover features of the Authorization= Server. That should be explicitly out of scope. >>>>> =20 >>>>> Currently, clients are instructed by RFC 6749 to discover information a= bout Authorization Servers they interact with by consulting the =E2=80=9Cser= vice documentation=E2=80=9D (RFC 6749, Sections 3.1 and 3.2). They can also= learn information about Authorization Servers in specific contexts through d= iscovery protocols such as OpenID Connect Discovery (http://openid.net/specs= /openid-connect-discovery-1_0.html) and UMA Discovery (TBD). >>>>> =20 >>>>> I suspect that at some point, someone in the OAuth working group will p= ropose developing a generic OAuth discovery mechanism, which will lead to a r= echartering to include this work in the working group=E2=80=99s set of deliv= erables. I would support doing this work and the necessary rechartering to d= o so. >>>>> =20 >>>>> That being said, I strongly oppose trying to shoehorn piecemeal aspect= s of discovery into the Dynamic Client Registration specification. It is di= stinct functionality and deserves first-class and separable treatment by the= working group. Discovery is for potential clients to learn properties of t= he AS before registration. Registration is for potential clients to inform t= he AS of its properties, creating a registered client. Discovery sends info= rmation about the AS to the Client. Registration sends information about th= e Client to the AS. That=E2=80=99s a clean separation. We should strongly r= esist muddying the two functions. >>>>> =20 >>>>> OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean= . It specified how to do one thing well in a simple, web-friendly manner. W= e should do the same =E2=80=93 focusing on specifying interoperable dynamic c= lient registration, while making it clear that this is distinct from discove= ry about Authorization Server properties, and making it clear that discovery= is out of scope for this work. >>>>> =20 >>>>> I apologize at this point on behalf of myself and the other spec edito= rs for not being 100% clear that discovery functionality is explicitly out o= f scope for Dynamic Client Registration. If we had done so, I=E2=80=99m sur= e that many of the current questions and confusions would not have arisen. I= think we=E2=80=99d assumed that this was obvious, but from the current disc= ussions, it=E2=80=99s apparent that it=E2=80=99s not obvious. I will person= ally commit to clarifying the specification at this point to eliminate this p= otential point of confusion. >>>>> =20 >>>>> Getting back to the specifics, the only useful purpose of a multi-valu= ed =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member would be to en= able the client to discover information about the authentication methods sup= ported by the AS after the registration had been performed. But that is a d= iscovery function, and so should be part of the discovery work =E2=80=93 not= this specification. We should resist shoehorning in bits of discovery into= this specification. It *is* a worthwhile topic, but deserves full consider= ation by the working group in its own right. = Therefore, this member must remain sin= gle-valued, and be clearly specified as the method by which a client informs= the AS which token endpoint authentication method it will = use. Anything else would be scope creep, and result in an u= nnecessarily complicated specification and= unnecessarily complicated clients. >>>>> =20 >>>>> * There is no authn method for "client_secret_saml" or "private_key_sa= ml". >>>>> =20 >>>>> Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an= absolute URI) would allow someone else to define these. Is the definition i= n the SAML Assertion draft sufficient for their use? >>>>> =20 >>>>> I think this is coming from the = fact that there is a JWT bearer draft and a SAML bearer draft. The trut= h is you are defining an authentication that isn't even defined. >>>>> =20 >>>>> There are no profiles referenced or defined for "client_secret_jwt" or= "private_key_jwt". Neither of the JWT or SAML Bearer = drafts referenced cover these types of flows= . They only cover bearer flows. "client_secret_jwt" and "private_key_jwt" s= eem to have some meaning within OpenID Connect, but I note that OIDC does no= t fully define these either. >>>>> =20 >>>>> The JWT assertion draft does say how to use a JWT = for client authentication, and the DynReg text= differentiates between a client signing said JWT with its own secret symmet= rically vs. a client using its own private key, asymmetrically. >>>>> =20 >>>>> Actually my interpretation is the JWT draft assumes the JWT Bearer is a= bearer token. The assumption is that if a client has the assertion it has t= he right to present it. IOW. The JWT Bearer Draft is most definitively not a= JWT HoK Draft. :-) >>>>> =20 >>>>> Regardless, you are introducing a new profile which is undefined. >>>>> =20 >>>>> I think I see the point that you're making now, let me try to re-state= it: >>>>> =20 >>>>> While the basics of "how to present a JWT as a client credential" is d= efined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rf= c.section.2.2 , it's not completely specified in that it doesn't fully restr= ict the signature secret source, the audience claim, and other things that t= he AS would need to check and validate. Right? The dynamic registration draf= t can define those cases in greater detail if needed (though I think it does= so sufficiently as-is, I welcome more clarity). >>>>> =20 >>>>> I'd be OK with adding the SAML bit, going into greater detail on the J= WT bits, or dropping the JWT bits, if the WG wants to do any of those action= s. My objection is that the JWT stuff is already in use and functioning and i= t'd be a shame to leave it out. >>>>> =20 >>>>> I guess then the mistake the JWT Bearer and SAML Bearer drafts authors= made is they assumed everyone had the same definition of bearer token. To m= e a bearer token opaque to the client. It therefore cannot do any signature w= ork with regards to the token itself. Now, that's not to say a proof didn't= occur between the client and the token issuer, but when the client wields t= he token, it is handling an opaque string. >>>>> =20 >>>>> The concept of client_secret_jwt suggests an HoK profile. Therefore o= f course the bearer drafts are a little underspecified when it comes to HoK p= rofiles. >>>>> =20 >>>>> So for example, you need a draft like the MAC draft for this.=20 >>>>> =20 >>>>> I'm having trouble overall here. It seems the authn types suggest ONLY= strong authentication for clients, yet during the registration process the c= urrent draft isn't able to correlate multiple instances of the same software= (even in a self-asserted way). If you haven't authenticated the software a= t all, why have strong client auth? >>>>> =20 >>>>> There is no authentication = method defined for "client_bearer_saml" or "client_bearer_jwt" or= "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration sp= ec should accept these. >>>>> =20 >>>>> I don't understand this bit -- where are these defined in RFC6750? I d= on't even know what client_bearer_ref would refer to. >>>>> =20 >>>>> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) a= nd wield it as an authentication assertion. The client is NOT creating or m= odifying the assertion. The client is simply passing one it previously obtai= ned. >>>>> =20 >>>>> What you are describing is not bearer. It is holder of key. Very very d= ifferent.=20 >>>>>=20 >>>>> A possible suggestion is to remove client_secret_jwt and private_key_j= wt and define those as register extensions since these profiles are not defi= ned. >>>>> =20 >>>>> That's possible, but they are = in active use already.=20 >>>>> =20 >>>>> That may be true. But then you need to write another draft so the rest= of us can implement it in an interoperable way. Me I prefer not to guess w= hat you are doing. >>>>> =20 >>>>> This much I agree with. >>>>> =20 >>>>> Justin, John, and I discussed this issue and agree with your suggestio= n, Phil. Since they are not completely specified, we will remove the client= _secret_jwt and private_key_jwt methods from the specification and add a reg= istry, enabling specification that do fully specify these and other token en= dpoint authentication methods, including potential methods using SAML assert= ions, to register them in the registry, rather than trying to bake them into= the Dynamic Client Registration specification. >>>>> =20 >>>>> About "tos_uri" and "policy_uri" >>>>> =20 >>>>> The distinction between tos_uri and policy_uri is unclear. Can we cla= rify or combine them? >>>>> =20 >>>>> Terms of service and policy are two different documents. One is someth= ing that a user accepts (generally describing what the user will do), one is= a statement of what the service provider = (in this case, the client) will do. More importantly, we use= d to have only one, and several people asked for them to be split. >>>>> =20 >>>>> Several developers were confused by this. In particular they couldn't f= igure out which was used for what. Just passing along the feedback. >>>>> =20 >>>>> OK, the distinction that I see is that the TOS is contractual, the Pol= icy is a statement. Re-reading the definitions in there right now, that can b= e made much clearer. (It even looks like some OIDC text leaked into the defi= nition of policy_uri and that hadn't been caught yet.) >>>>> =20 >>>>> I support clarifying the language on these definitions, and will work w= ith Justin to do so. >>>>> =20 >>>>> Also, aren't these really URIs or are they meant to be URLs? >>>>> =20 >>>>> There was already discussion about this on the = list: The IETF is apparently trying to deprecate U= RL in favor of URI in new specs. So in practice they'll nearly always be URL= s, but since all URLs are URIs we're not = technically incorrect in following the new policy. And it mak= es the IESG less mad at us, which is a plus. >>>>> =20 >>>>> Arg. Nice. Then the text should say the value passed must resolve to a= valid web page, document, whatever. >>>>> =20 >>>>> That's fair, and it's something that the AS can even check if it wants= to. >>>>> =20 >>>>> Agreed on this clarification. >>>>> =20 >>>>> About "jwks_uri" >>>>> =20 >>>>> A normative reference for http://tools.ietf.org/html/draft-ietf-jose-j= son-web-key-09 is needed.=20 >>>>> =20 >>>>> Yes, you're correct, I'll add that. >>>>> =20 >>>>> Should be URL instead of URI? >>>>> =20 >>>>> See above. :) >>>>> =20 >>>>> Agreed on adding this reference. >>>>> =20 >>>>> Section 2.1 >>>>> =20 >>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>>> is missing. >>>>> =20 >>>>> It's there in the copy of -10 I'm reading off of ietf.org right now =E2= =80=A6 ? >>>>> ' >>>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>>>> =20 >>>>> Ah, that makes more sense. If the WG wants to add in SAML support to p= arallel the JWT support, I'd be OK with that. >>>>> =20 >>>>> =E2=80=9CAs such, a server supporting these fields SHOULD take steps t= o ensure that a client cannot register itself into an inconsistent state.=E2= =80=9D >>>>>=20 >>>>> We may want to define more detailed HTTP error = response. E.g. 400 status code + defined er= ror code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)? >>>>> =20 >>>>> I'd be fine with defining a more explicit error state in this case. I t= hink it would help interop for the servers that want to enforce grant-type a= nd response-type restrictions, but servers that can't or don't care about re= stricting grants types and whatnot don't have to do anything special. >>>>> =20 >>>>> I *think* that this goes away with the deletion of client_secret_jwt a= nd private_key_jwt in favor of the = registry=E2=80=A6 I=E2=80=99ll do a consistency check and veri= fy that when the spec is updated accordingly. >>>>> =20 >>>>> Section 2.2 >>>>> =20 >>>>> May want to add: >>>>> =20 >>>>> When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2= =80=9D is missing in =E2=80=9Cclient_name=E2=80=9D, = instead of =E2=80=9Cclient_name#en=E2=80=9D= ) the OAuth server may use interpret the language used based on server confi= guration or heuristics. >>>>> =20 >>>>> That seems inconsistent with what we already have: >>>>> =20 >>>>> If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make = any assumptions about the language, character set, or script of the string v= alue, and the string value MUST be used as-is wherever it is presented in a u= ser interface. >>>>> =20 >>>>> Which is to say, treat it as a raw byte-value-string and don't try to g= et fancy. >>>>> =20 >>>>> I will discuss with our developers. I'm not sure the as-is works. =20 >>>>> =20 >>>>> Is it the intent that when the client has localized "client_name" for e= xample, it should pass all language variations in a JSON array? >>>>> =20 >>>>> Or, should part of the registration be to indicate which interface lan= guage the client wishes to use? Then it only passes a single value for that= registration? >>>>> =20 >>>>> =20 >>>>> No, the client should pass parameters as multiple separate values. Con= nect has this in its example: >>>>> =20 >>>>> "client_name": "My Example", >>>>> "client_name#ja-Jpan-JP": >>>>> "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D"= , >>>>> Should we add that to at least one of the examples in DynReg? (The lan= guage tags are a late addition, so the examples don't reflect it.) >>>>> =20 >>>>> An example would definitely help. >>>>> If the client passes only a single unadorned field, the AS can't make a= ny assumption about what language it is. Think of this as the internationali= zed value of the field while the language tags are the localized versions of= the field. This is why we recommend that the bare-value always be sent by t= he client, so that in the lack of anything more specific, the AS can at leas= t do *something* with it. >>>>> =20 >>>>> Passing in a "default" language field (like default_locale or the like= ) is only going to lead to pain for implementors of both clients and servers= , and it's going to hurt the interoperability of the human-readable fields.=20= >>>>> =20 >>>>> I think what I meant is since you are allowing each client to = register different things, AND the client likely a= lready knows the user's preferred language, why wouldn't the client just pas= s text values in one language and another parameter indicating preferred lan= guage in the case of any service generated text. >>>>> =20 >>>>> Is the reason you are passing multiple localizations is so that you ca= n use the preferred language of the resource owner rather then the client us= er? I wonder if that is correct. If the language preferences are in fact di= fferent, what would the user of the client app expect? >>>>> =20 >>>>> ----> any multi-lingual people have any opinions here? >>>>> =20 >>>>> Without specific proposed text changes to review, it=E2=80=99s hard to= know what to think about this comment. Unless a specific proposed text cha= nge is sent to the list with clear rationale for why it=E2=80=99s better tha= n what=E2=80=99s there now and reviewed by the working group, I don=E2=80=99= t believe we should change the specification in response to this comment. >>>>> =20 >>>>> Section 3 >>>>> =20 >>>>> Existing text: >>>>>=20 >>>>> =E2=80=9CIn order to support open = registration and facilitate = wider interoperability, the Client Registrat= ion Endpoint SHOULD allow = initial registration requests with no authentication. These request= s MAY be rate-limited or otherwise limited to prevent a denial-of-service at= tack on the Client Registration = Endpoint.=E2=80=9D >>>>>=20 >>>>> I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to =E2=80= =9CMAY=E2=80=9D. In = most cloud services, the first client is registered by a human user. The= n, other clients can be further used to automate other client registration. = So, the first request would typically come with an authenticated user ident= ity.=20 >>>>> =20 >>>>> I think the weight of "SHOULD" is appropriate here, because I believe t= hat turning off open registration at the AS (which is what this is talking a= bout) really ought to be the exception rather than the rule.=20 >>>>> =20 >>>>> I think you are reading it wrong -- a double-negative issue. The end o= f the sentence is "no authentication". You are implying that NO Authenticat= ion us what should normally be done. I = think you intend anonymous authentication to be the exception rather t= han the rule don't you? >>>>> =20 >>>>> No, I think that anonymous authentication should be the rule. Open reg= istration should be default.=20 >>>>> =20 >>>>> I disagree. Again, the spec seems contradictory. It suggests strong c= lient auth methods and at the same time anonymous registration. Yes you gai= n uniqueness, but that's about it. >>>>>=20 >>>>> On the flip side, the earlier paragraph: >>>>>=20 >>>>> =E2=80=9CThe Client Registration Endpoint MAY accept an initial author= ization credential in the form of an OAuth 2.0 [RFC6749] access token in ord= er to limit registration to only previously authorized parties. The method b= y which this access token is obtained by the registrant is generally out-of-= band and is out of scope of this specification.=E2=80=9D >>>>>=20 >>>>> I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D= to =E2=80=9CSHOULD=E2=80=9D. >>>>>=20 >>>>> That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion token. >>>>> =20 >>>>> Again, disagree, for the same reasoning as above. >>>>> =20 >>>>> Same reasoning.=20 >>>>>=20 >>>>> I agree with Justin here. The default = should be that open registrations are enabled. The exception c= ase is that specific permissions are required to perform dynamic client regi= stration. >>>>>=20 >>>>> About section 4.3: >>>>> =20 >>>>> If the client does not exist on this server, the server MUST respond >>>>> with HTTP 401 Unauthorized, and the Registration Access Token used t= o >>>>> make this request SHOULD be immediately revoked. >>>>> =20 >>>>> If the Client does not exist on this server, shouldn't it return a "40= 4 Not Found"? >>>>>=20 >>>>> If revoking the registration access token, is it bound to a single cli= ent registration? This is not clear. What is the lifecycle around registra= tion access token? Only hint is in the Client Information Response in sectio= n 5.1. >>>>> =20 >>>>> The language about the 401 = here (and in other nearby sections) is specifically so that you treat a m= issing client and a bad registration access token the same way. You see, ret= urning a 404 here actually indicates things were in an inconsistent state. N= amely, that the registration access token was still valid but the client tha= t the registration access token was attached to doesn't exist anymore. The r= egistration access token in meant to be tied to a client's instance (or regi= stration), so it's actually more sensible to act as though the registration a= ccess token isn't valid anymore. In at least some implementations (specifica= lly ours at MITRE that's built on SECOAUTH in Java), you'd never be able to r= each the 404 state due to consistency checking with the inbound token. >>>>> =20 >>>>> Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begins= at the issuance of a new client_id with that instance. That token might be r= evoked and a new one issued on Read and Update = requests to the Client Configuration Endpoint (and the clie= nt needs to be prepared for that -- same as the client_secret), and it will b= e revoked when the client is deleted either with a Delete call to the Client= Configuration Endpoint or something happening out-of-band to kill the clien= t.=20 >>>>> =20 >>>>> Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sinc= e I don't think it's as clear as we'd like. >>>>> =20 >>>>> I think we should look at it. >>>>>=20 >>>>> For security reasons, it=E2=80=99s generally not good to distinguish b= etween =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D errors= in responses, as that can provide the attacker an oracle to probe whether a= particular entity exists I don= =E2=80=99t think a change is called for here. >>>>>=20 >>>>> About section 5.1: >>>>> Is registration_access_token unique? Or is it shared by multiple inst= ances? If shared, then registration_access_token can't be revoked on delet= e of client. >>>>> =20 >>>>> The registration_access_token is unique to a registered client, in the= RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do work o= n =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up= explicitly. >>>>>=20 >>>>> Suggest rename =E2=80=9Cexpires_at=E2=80=9D to =E2=80=9Cclient_secret_= expires_at=E2=80=9D,=20 >>>>>=20 >>>>> Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at= =E2=80=9D >>>>> =20 >>>>> While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readabl= e, >>>>>=20 >>>>>=20 >>>>> I don't want to change the syntax during last call unless there is a c= lear need and a clear consensus for doing so. >>>>> =20 >>>>> That's why we are having last call. To confirm consensus on the draft.= =20 >>>>> =20 >>>>> Same reasoning as earlier. You now have multiple tokens (registration a= ccess and client) in play. The spec needs to be clear which one it is talkin= g about. >>>>> =20 >>>>> I'm fine with the suggested change but I would like more feedback from= other people before moving forward with it. There's a lot of value in "just= pick a name and ship it" as well though, and I don't want to devolve into b= ike shedding. (I'm not accusing you of bike shedding quite yet, btw, just af= raid of getting into a long debate on names.) >>>>> =20 >>>>> Again, this was a problem raised by people new to the specification. T= hey found it confusing. I tend to agree. We're not talking about what colour= to paint the shed. We're talking about whether the bike shed is a house. := -)=20 >>>>> =20 >>>>> I'm not too fussed about whether you call it "cl_sec_expiry" or "clien= t_secret_expires_at".=20 >>>>>=20 >>>>> If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_= at=E2=80=9D are unclear, we should clarify them. If you believe that this i= s the case Phil, can you supply proposed alternative definition text that is= clearer? That being said, I believe that at this point we should stick wit= h the existing protocol element names unless overwhelming working group sent= iment emerges to change them. They are already working fine as-is in produc= tion deployments. >>>>> =20 >>>>> Section 7 >>>>> =20 >>>>> When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret? >>>>> =20 >>>>> Yes, the client is supposed to either call the read or update methods o= n the client configuration endpoint to get = its new secret. As discussed above, I'm not sure that's= as clear as it needs to be, and I welcome suggestions on how = to clarify this. >>>>> =20 >>>>> Either is a reasonable behavior on the behalf of clients, depending up= on context. I support adding text to clarify this. >>>>> =20 >>>>> Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either = as-is or with any of your suggested changes? >>>>> =20 >>>>> Yes. Much of the feedback is coming from our development = community.=20 >>>>> =20 >>>>> Ah, very cool. Developer experience is the most valuable feedback, in m= y opinion. If you can't actually build the blasted thing, what good is it? := ) >>>>> =20 >>>>> Glad to hear that you=E2=80=99re working with developers building the s= pec. Please thank them for the feedback. >>>>> =20 >>>>> -- Justin >>>>> =20 >>>>> = Best wishes, >>>>> = -- Mike >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-C953F08C-71C1-4A15-9C49-1BE868B37EC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Regarding charter. 
The charter is a one-liner. To say associating clients is not in= the charter while saying every other 'new' thing that is in the spec (eg cl= ient auth type) is in is laughable. After all the entire draft is new functi= onality. 

The item i have asked for is not new= . It preserves information that was available without reg. Namely a way to r= ecognize multiple clients as a common public client as in 6749 they share a c= lient_id.  The draft throws this information away preventing security a= dmins from making any judgements since all clients are now anonymized.
=

Where in the charter does it say you can anonymize the c= lients? 

Phil

On 2013-05-21, at 6= :46, Justin Richer <jricher@mitre.or= g> wrote:

=20 =20 =20
On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


=46rom the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be= expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
=
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case.


  http://blue-bu= tton.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:

And dynamic client registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case.

There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.
[JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 I was pretty fully engaged at= the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green=E2=80=A6
 
(Perhaps if any of you reply to this thread, you could also choose a distinct=  color for your inline replies, so that it will be easily evident who said what.  As i= t is, just the back-and-forth between Phil and Justin is already very difficult to follow. = ; Thanks.)
 
From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I thin= k we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put= together some intro text, etc.
 
 <= /div>
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.h= unt@oracle.com>
 wrot= e:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
&= nbsp;
Phil, many thanks for the extremely thorough review! It is very useful indeed. <= /div>
 
My comments and responses to each point are inline. 
 =
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt= @oracle.com> wrote:
 =
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall=  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:=
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should= clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. <= /o:p>
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first tim= e a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.<= /o:p>
 = ;
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 = ;
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)<= /div>
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I=E2=80=99= m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I=E2=80=99ll note that i= n RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If= we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It=E2=80=99s not the right p= lace to extend what an OAuth client is in new ways.
 
2.  How ar= e client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 =
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (=C2=A74.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. =
Something like this should be in the draft.
&nb= sp;
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 =
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 =
How does a client authenticate the first time and subsequent times to the registration service?
 =
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 =
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
=
 
Someth= ing like this should be in the draft.
 = ;
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in =C2=A73. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread =E2=80=9CClient Credentia= l Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D= .  I will work with Justin to apply these clarifications to the specification.  This may go int= o the proposed credential management overview section discussed above.
 
3.  How is= versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 =
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.=
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have= an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.<= /div>
 = ;
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  = ;
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I=  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it=E2=80=99s inappropriate t= o do so here.  We don=E2=80=99t need t= o boil the ocean.  If a new charter item i= s approved to do work on client instances and protocol elements to use and express them, that=E2=80=99s the= time for the working group to consider that possibility =E2=80=93 not a= s part of Dynamic Client Registration.
 
4.  What= is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?=
 
See the response above above and the definition in =C2=A71.2: =
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.<= /div>
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
&= nbsp;
Client=
 Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new regist=
ration.  The means of the Client
      obtaining the URL for this endp=
oint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2=
.0 Endpoint through
      which a specific Client can man=
age its registration information,
      provided by the Authorization S=
erver to the Client.  This URL for
      this endpoint is communicated t=
o the client by the Authorization
      Server in the Client Informatio=
n Response.
 
   o  Registration Access Token: An OAuth 2.0 B=
earer Token issued by the
      Authorization Server through th=
e Client Registration Endpoint
      which is used by the Client to a=
uthenticate itself during read,
      update, and delete operations.&=
nbsp; This token is associated with a
      particular Client.
 = ;
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I= think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method= is one thing that should not be negotiated per instance.
=
 =
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_m= ethod" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 =
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The= role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?<= /o:p>
 = ;
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 = ;
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent= that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So wh= y negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.<= /div>
 =

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery= protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 <= /span>
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I=E2=80=99ll work w= ith Justin to make sure that this is as clear as possible in the specification.<= /span>
 
Finally, there seems to be an inconsistent style approach with dra= ft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 =
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. <= /o:p>
&= nbsp;
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In th= e design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.<= /o:p>
 = ;
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in =C2=A74.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
=
ETags seem like an unnecessary addition (and potential complication) to the specification.  It=E2=80=99s already working fine as-is.
 
=
Specific items:
-----------------= ----
"token_endpoin= t_auth_method"
 =
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_aut= h_method"
 =
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind= shorter names (maybe not quite as short as the JOSE stuff ;-)
 = ;
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I=E2=80=99m fine clarify= ing the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I=E2=80=99m not OK revis= ing the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 =
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =C2=A72, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.=
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.=
 = ;
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
=
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it=E2=80=99s currently written.  The a= uthors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification. = I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
=
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *= is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server. = ; That should be explicitly out of scope.
 
=
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the =E2=80=9Cse= rvice documentation=E2=80=9D (RFC 6749, Sections 3= .1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/s= pecs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).=
 
=
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group=E2=80=99s set of deliverables. = I would support doing this work and the necessary rechartering to do so.
 
=
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is= for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That=E2=80=99s a clean separatio= n.  We should strongly resist muddying the two functions.
 
=
OAuth 2.0 is a success because it didn=E2=80=99t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same =E2=80= =93 focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
=
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I=E2= =80=99m sure that many of the current questions and confusions would not have arisen.  I think we=E2=80=99d as= sumed that this was obvious, but from the current discussions, it=E2=80=99s apparent= that it=E2=80=99s not obvious.  I wil= l personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
=
Getting back to the specifics, the only useful purpose of a multi-valued =E2=80=9Ctoken_endpo= int_client_auth_method=E2=80=9D member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But= that is a discovery function, and so should be part of the discovery work =E2=80= =93 not this specification.  We should resist shoehorning in bits of discovery into this specification.  I= t *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
=
* There is no authn method for "client_secret_saml" or "private_key_saml".
 =
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_j= wt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.=
 =
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.=
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that i= f a client has the assertion it has the right to present it.  IOW. The JWT= Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 = ;
I think I see the point that you're making now, let me try to re-state it:
 = ;
While the basics of "how to present a JWT as a client credential" is defined here: http:/= /tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 = ;
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the beare= r drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer= specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 =
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is= NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. = ;

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 =
That's possible, but they are in active use already. <= /div>
 =
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
&nb= sp;
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"<= /o:p>
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 =
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.=
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.=
&nb= sp;
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 =
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.<= /o:p>
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
&nb= sp;
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http:= //tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. =
 =
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?=
 =
See above. :)
 
Agreed on adding this reference.
 <= /span>
Section 2.1
 
In the table urn= :ietf:params:oauth:grant-type:jwt-bearer
is missing.
 =
It's there in the copy of -10 I'm reading off of ietf.org right now =E2=80=A6 ?
'
Sorry I meant: urn:ietf:params:oaut= h:grant-type:saml-bearer
&nb= sp;
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
=E2= =80=9CAs such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.=E2=80=9D

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (=E2=80=9Cinvalid_cl= ient_metadata=E2=80=9D)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry=E2=80=A6 = ; I=E2=80=99ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2=
 =
May want to add:<= /o:p>
 =
When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en= =E2=80=9D is missing in =E2=80=9Cclient_na= me=E2=80=9D, instead of =E2=80=9Cclient_na= me#en=E2=80=9D) the OAuth server may use interpret the language used based on= server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.=
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.<= /div>
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passe= s a single value for that registration?
&nb= sp;
&nb= sp;
No, the client should pass parameters as multiple separate values. Connect has this in its example:
&nb= sp;
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=
=90=8D",
Should= we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.<= /o:p>
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
&= nbsp;
Passin= g in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. <= /o:p>
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  I= f the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?<= /div>
 
Without specific proposed text changes to review, it=E2=80=99s= hard to know what to think about this comment.  Unless a specifi= c proposed text change is sent to the list with clear rationale for why it=E2=80=99s better than wha= t=E2=80=99s there now and reviewed by the working group, I don=E2=80=99t belie= ve we should change the specification in response to this comment.
 
Section 3=
 
Existing text:

=E2=80=9CIn order to support open registration and facilitate wider interop= erability, the Client Registration Endpoint SHOU= LD allow initial registration = requests with no authentica= tion.  These requests MAY be rate-limit= ed or otherwise limited to prevent a denial-of-service attack on the Client&nb= sp;Registration Endpoint.=E2=80=9D=

I would suggest to change the first =E2=80=9CSHO= ULD=E2=80=9D to =E2=80=9CMAY=E2= =80=9D.   In most cloud services, the first client is registered= by a human user. Then, other clients= can be further used to automate othe= r client registration. = ; So, the first request= would typically come with an authenticated user identity. 
 =
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. =
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
=
&nb= sp;
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

=E2=80=9CThe Client Registration Endpoint MAY accep= t 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.=E2=80=9D=

I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D to =E2=80= =9CSHOULD=E2=80=9D.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 =
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled. = The exception case is that specific permissions are required to perform dynamic client registration.<= /span>

About section 4.3:
=
 
<=
span style=3D"font-size: 12pt; ">If the client does not exist on this server=
, the server MUST respond
<=
span style=3D"font-size: 12pt; ">   with HTTP 401 Unauthorized, an=
d the Registration Access Token used to
<=
span style=3D"font-size: 12pt; ">   make this request SHOULD be im=
mediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.<= /o:p>
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here= actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.<= /div>
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it=E2=80=99s generally n= ot good to distinguish between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D e= rrors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I= don=E2=80=99t think a change is called for here.

About section 5.1:
=
Is registration_acces= s_token unique?  Or i= s it shared by multiple instances?   If shared, then registration_acces= s_token can't be revoked on delete of client.=
 = ;
The registration_acces= s_token is unique to a registered client, in the RFC 6749 sense of =E2=80=9Cclient= =E2=80=9D.  Again, if we want to do work on =E2=80=9Cclient instances=E2=80=9D= , we need to recharter and take this distinct work item up explicitly.

Suggest rename =E2=80=9Cexpires_a= t=E2=80=9D to =E2=80=9Cclient_se= cret_expires_at=E2=80=9D, 

Suggest to rename =E2=80=9Cissued_at= =E2=80=9D to =E2=80=9Cid_issued= _at=E2=80=9D
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,=


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's= why we are having last call. To confirm consensus on the draft. 
&= nbsp;
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
=
 = ;
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Ci= ssued_at=E2=80=9D are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
=
Section 7=
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.<= /span>
&nb= sp;
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
&nb= sp;
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?=
 
Yes. Much of the feedback is coming from our development community. 
 = ;
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you=E2=80=99= re working with developers building the spec.  Please thank them fo= r the feedback.
 
 -- Justin
=
 
     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;    Best wishes,
=
     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;    -- Mike




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


=20
= --Apple-Mail-C953F08C-71C1-4A15-9C49-1BE868B37EC9-- From jricher@mitre.org Tue May 21 08:34:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8921F92EB for ; Tue, 21 May 2013 08:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yjWsv9-u4aN for ; Tue, 21 May 2013 08:34:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB4121F9345 for ; Tue, 21 May 2013 08:34:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A56311F0945; Tue, 21 May 2013 11:34:08 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4E49D1F02E0; Tue, 21 May 2013 11:34:08 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 11:34:07 -0400 Message-ID: <519B93D2.5020602@mitre.org> Date: Tue, 21 May 2013 11:33:38 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040609070108020907040404" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 15:34:13 -0000 --------------040609070108020907040404 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit What's clear to me now is that what we're disagreeing on, at a fundamental level, is what dynamic registration is for. It is currently written to enable self-asserted registration of clients, with hooks in place to allow for higher assurance with further specification. What you want is for that latter, and while I see value in that, I think that case is far more complicated than you're giving it credit for. It is absolutely new functionality, because you're tying together multiple client_ids at an AS. If you want to do a public client still do that with a single client_id. You just now have other options as a client developer (including not making it a public client anymore, which ought to be a big win, right?). I'm sorry, but I'm failing to see what the disconnect is here. Also, auth type is required for the client to talk to the token endpoint. It's very useful in cases when you have clients and servers that can do several different things and you need to pick one. If your server doesn't enforce it or your client can't handle it, don't use the parameter. End of story. -- Justin On 05/21/2013 11:00 AM, Phil Hunt wrote: > Regarding charter. > > The charter is a one-liner. To say associating clients is not in the > charter while saying every other 'new' thing that is in the spec (eg > client auth type) is in is laughable. After all the entire draft is > new functionality. > > The item i have asked for is not new. It preserves information that > was available without reg. Namely a way to recognize multiple clients > as a common public client as in 6749 they share a client_id. The > draft throws this information away preventing security admins from > making any judgements since all clients are now anonymized. > > Where in the charter does it say you can anonymize the clients? > > Phil > > On 2013-05-21, at 6:46, Justin Richer > wrote: > >> >> On 05/21/2013 02:01 AM, Phil Hunt wrote: >>> >>> >>> Phil >>> >>> On 2013-05-20, at 8:35, Justin Richer >> > wrote: >>> >>>> >>>> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>>>> Mike, >>>>> >>>>> Rather then embed comments in an extended thread, I'd like to open >>>>> up a specific discussion on the objective of dyn reg. >>>>> >>>>> I see limited to no value in having clients completely anonymously >>>>> registering and receiving tokens without any ability to correlate >>>>> applications between applications. >>>> >>>> I think that herein lies a very big disconnect in assumptions. I >>>> see a huge benefit in anonymously registered clients getting tokens >>>> because there is an end-user in the loop during the authorization >>>> phase (long after registration has happened). The arity of >>>> registrations to authorizations approaches 1:1 in these cases, and >>>> I'm just fine with that. >>> Then what you describe is NOT anonymous but rather a profile not >>> covered by the spec as there is no discussion of user authenticated >>> registration. Implicitly or explicitly. >> >> [JR] I think you misunderstand what I said, let me try to be more >> explicit: the user is not authenticating the registration. The user >> is not involved in the registration. The user might not even know >> that a registration happened. The registration is (normally) >> completely anonymous and open, the client just shows up and says "Hi, >> I'm a client!". >> >> The "authorization" that I mentioned happens later and is a normal >> OAuth authorization, which has a user involved like usual. The >> authorization step in OAuth depends on *some* kind of registration >> happening beforehand, dynamic or otherwise. This is all perfectly >> within the model of OAuth. >> >>>> >>>> From the RFC6749 perspective, a "client" is not a particular piece >>>> of code, it is a particular copy of a piece of code with a >>>> particular client_id from the vantage point of a particular >>>> authorization server. >>> actually, i disagree. This spec fundamentally breaks the old >>> definition and behavior from 6749. In the old way every instance of >>> software shared a client_id. In this draft, u throw that away >>> without preserving the information. This is BAD! >> [JR] No, we're not throwing that away at all. The concept is the >> same, but when you add new functionality, the mechanics change a bit. >> A "client_id" was always pairwise between a client and an AS. If a >> client had to talk to two AS's before, it would have two client_ids. >> That's still the case. If there were multiple copies of a >> confidential client, you need to get a client_id and client_secret to >> each copy. That's still the case. What's different is that we've made >> it *easier* for a particular piece of code to get different >> client_ids when it's talking to the same or a different auth server, >> at runtime. When you have to manually register every client, you're >> going to just do it once. If you can do it dynamically, you have more >> options. >> >> Note that you can *still* have a public client with a known client_id >> if you want to. You don't even need to use dynamic registration for >> that. Heck, you don't need to use dynamic registration for any kind >> of client if you don't want to, since most services will probably >> still offer manual registration through some portal kind of page. >> >>> >>> >>>> A "client" is, conceptually, a pairwise association between two >>>> running codebases. When you have a particular piece of code talking >>>> only to one auth server and being manually configured at said auth >>>> server with its client_id, this is fairly clear and straightforward >>>> and the arity is simple. Things get a bit muddy when you introduce >>>> dynamic registration, which is why I think that we need to have >>>> introductory text about this. Specifically: >>>> >>>> - a particular piece of code can be run on multiple devices and >>>> talk to the same auth server, each copy of that code getting its >>>> own client_id. >>>> - a particular copy of a particular piece of code can now be >>>> expected to talk to multiple auth servers, each auth server giving >>>> the piece of code its own client_id. >>>> >>>> Both of these are cases of what defines an "instance" in most >>>> people's heads, even though it's the same software, even sometimes >>>> the same running copy of the same software. But as far as RFC6749's >>>> definition of "client" is concerned, these are all completely >>>> separate "client"s with no way to tie them together out of the box. >>>> And that's fine. >>>> >>>>> >>>>> Associating client_id's with known client applications to allow >>>>> admins to know who is running what version of clients seems to be >>>>> the most fundamental part of the reason for dynamic reg. How can >>>>> you revoke access to particular client app types? As Justin >>>>> already talked about in his Blue Button+ scenario, there are often >>>>> life and death situations where particular sets of clients need to >>>>> be revoked. >>>> While it's very useful, I wouldn't (and haven't) classified it >>>> quite like that. Nor would I say that the BB+ profile is a complete >>>> solution -- our Registry component does not actually push >>>> revocation notifications down to Providers (yet), so it's more like >>>> invalidating a root certificate and waiting for caches to time out >>>> for things to cascade. We've been talking about adding some form of >>>> callback to providers, but we don't want to boil that particular >>>> ocean right now. However, the BB+ profile makes use of a >>>> well-specified discovery and Registry set up, as well as data >>>> conveyed in structured, signed tokens (JWTs) at different points in >>>> the process. >>>> >>>>> >>>>> Or put another way. I believe this will be a critical operational >>>>> requirement going forwards. If the spec is published as is, it >>>>> will be quickly invalidated by one that does at least partially >>>>> address the problem. >>>> That's not true at all. BB+ addresses this scenario and still uses >>>> the Dynamic Registration spec as-is. I would encourage folks to >>>> read what we're doing, a work-in-progress found here: >>> but you are breaking other things and overloading client cred >>> etc to pass in signed data. I don't want a hack for a solution. I >>> want interop. >> [JR] I'm curious, what exactly are we breaking? If anything in BB+ >> breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that >> we need to fix there. It is our intent to be fully compatible with >> OAuth Dyn Reg, and we are even explicitly calling for open >> registration as mandatory to implement for authorization servers >> within BB+, even though we have additional mechanisms as well for >> what we're calling "trusted registrations". For those trusted >> registrations, we're not using the client *credentials* to pass in >> signed data, we're using the initial *registration authentication* >> mechanism (which is to say, an OAuth token) for its intended purpose: >> authorizing the holder of this token access to the registration >> endpoint. In BB+, we're profiling exactly what that means. To wit, we >> define the content of the token (which is fully compatible with >> DynReg which doesn't care what's in the token) and how the AS can >> verify it (which DynReg doesn't care how it happens) and we've added >> some additional rules and policies that allow us to tie together >> instances of the client across the distributed network. >> >> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a >> huge amount of very specific machinery (signed tokens with known >> formats and fields, a Registry with manual pre-registration, a >> three-tiered discovery service with information about clients and >> service providers rooted at the Registry, trust frameworks and >> network enforcement policies that all players have to agree to before >> playing, etc.), and it's not really doing just registration anymore. >> In BB+, we needed the Registry and Discovery services to do other >> functions as well apart from just registration, and so it makes sense >> to re-use them. >> >> If there were a simple solution that didn't leave security holes the >> size of a small army, I'd be glad to bring it to the table. But I am >> convinced that a good solution for managing client instances across a >> network requires a lot more thought and consideration, and I believe >> that having a fully specified discovery service will help this case, >> like it has helped in BB+. But I think that it's a complex enough >> problem that it needs its own set of considerations. With DynReg, we >> need to leave things open for that work in the future, and I believe >> we have, but we shouldn't kill the simple, general case for want of a >> special case. >> >>>> >>>> http://blue-button.github.io/blue-button-plus-pull/ >>>> >>>> Just because you make something better doesn't mean you throw >>>> necessarily away everything you've done to date. >>>> >>>>> >>>>> We're ahead of schedule, lets talk through the requirement. >>>> I believe that the requirement of tying instances together is >>>> explicitly out of scope for the dynamic registration protocol. I >>>> intended to have text to that effect in the section I'm adding >>>> about the client lifecycle. >>> >>> where is this stated in charter? >> [JR] The charter for the working states what's in scope, not what's >> out of scope, correct? It has been my understanding of IETF process >> that additional functionality needs to be considered separately. All >> the charter says about registration is this: >> >> And dynamic client registration will make >> it easier to broadly deploy OAuth clients (performing services to >> users). >> >> >> And: >> >> Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >> the IESG for consideration as a Proposed Standard >> >> There's nothing in there at all about tying together client >> instances. I have not seen anything to convince me that management of >> client instances across a deployed network of auth servers is a >> necessary part of basic client registration. It sounds very likely to >> me that it *is* required for your use case, but that doesn't make it >> required for everybody's use case. >> >> There are other important pieces of functionality that the WG isn't >> picking up right now (such as token chaining and token introspection) >> that are absolutely necessary for my own use cases, but I think it >> makes sense for those to be separate modules. >> >>>> >>>>> >>>>> As I mentioned in my comments to the other thread. Let's say we >>>>> agree not do this now. Well, then the new draft that does solve it >>>>> would likely be 95% overlap. Thus I see this issue as within >>>>> charter and should be solved now rather then waiting for a V2 dyn >>>>> reg in the next charter. >>>> Why wouldn't the new draft just be the extra 5%? I personally think >>>> that it's a lot more than 5% once you have in all the assurance and >>>> safety mechanisms in place to avoid self-asserted values causing >>>> race conditions, and what not. >>> >>> Two drafts to do registration is not the way to go. It implies >>> complexity where there should be none. There is no technical reason >>> for two drafts. >> [JR] There is a need when there's a special case that requires a >> large amount of overhead to be done correctly, to allow the general >> case to move forward and be used on its own (as it is being used today). >> >>>> >>>> -- Justin >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>>>> >>>>>> Thanks for the detailed feedback, Phil. Sorry for the delayed >>>>>> response – I was pretty fully engaged at the European Identity >>>>>> Conference (whereOAuth 2.0 won the award for best new standard >>>>>> J). My feedback on the points >>>>>> raised is inline in green… >>>>>> (Perhaps if any of you reply to this thread, you could also >>>>>> choose a distinctcolorfor your inline replies, so that it will be >>>>>> easily evident who said what. As it is, just the back-and-forth >>>>>> between Phil and Justin is already very difficult to follow. Thanks.) >>>>>> *From:*oauth-bounces@ietf.org >>>>>> [mailto:oauth-bounces@ietf.org]*On >>>>>> Behalf Of*Phil Hunt >>>>>> *Sent:*Thursday, May 16, 2013 12:54 PM >>>>>> *To:*Richer, Justin P. >>>>>> *Cc:*oauth@ietf.org WG >>>>>> *Subject:*Re: [OAUTH-WG] Last call review of >>>>>> draft-ietf-oauth-dyn-reg-10 >>>>>> Justin, >>>>>> Thanks for the discussion. More comments below... >>>>>> BTW. I'm happy to contribute text. Just want to get to some rough >>>>>> agreement first. For example, I think we need to have a away to >>>>>> recognize two pieces of software as being the same (even if >>>>>> self-asserted). Once defined, I can put together some intro >>>>>> text, etc. >>>>>> Phil >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>>>>> On May 15, 2013, at 10:30 PM, Phil Hunt >>>>> > >>>>>> wrote: >>>>>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>>>>> Phil, many thanks for the extremely thorough review! It is very >>>>>> useful indeed. >>>>>> My comments and responses to each point are inline. >>>>>> On May 15, 2013, at 4:30 PM, Phil Hunt >>>>> > wrote: >>>>>> It seems unfortunate that I have not gotten a chance to get into >>>>>> this level of detail much earlier. But then, I guess that's what >>>>>> LC review is for! My apologies for not getting many of these >>>>>> concerns to the WG much earlier. >>>>>> */Overall /* >>>>>> ----------- >>>>>> I think dynamic registration is a critical part of the OAuth >>>>>> framework now that we are starting to consider how individual >>>>>> client applications should operate when there is one or more >>>>>> deployments of a particular resource API. We've moved from the >>>>>> simple use case of a single API provider like Facebook or Flickr >>>>>> and moved on to standards based, open source based, and >>>>>> commercial based deployments where there are multiple service >>>>>> endpoints and many clients to manage. >>>>>> The dynamic registration spec is actually dealing with a couple >>>>>> of issues that I would like to see made more clear in early part >>>>>> of the spec: >>>>>> 1. How is a new client application recognized for the first time >>>>>> when deployed against a particular SP endpoint? Should clients >>>>>> actually assert an application_id UUID that never changes and >>>>>> possibly a version id that does change with versions? >>>>>> In the general case, why is any recognition required? If you're >>>>>> doing things as part of a larger protocol ecosystem, like Blue >>>>>> Button+ or a particular OpenID Connect provider, then you can >>>>>> define semantics for tying together classes of clients (see below >>>>>> for more discussion on this very point). But in general, a client >>>>>> is just going to show up as a new instance to the AS and get >>>>>> issued a new, unique client_id, and that's that. >>>>>> I think we have to define more clearly what an "instance" is. For >>>>>> me, there are applications and there are instances of that >>>>>> application. It is useful to understand that a client >>>>>> application represents a set of code that should behave in a >>>>>> consistent way. It seems to me the first time a new application >>>>>> shows up is very different from the subsequent instances that >>>>>> register. For example, after the first registration, subsequent >>>>>> instances don't need special review or approval to the same degree. >>>>>> But without other mechanisms to tie things together, there's no >>>>>> way for an authorization server to know if any client instance is >>>>>> tied to any other client instance. Therefore, from the >>>>>> perspective of an AS, the first instance of an application (i.e., >>>>>> particular configuration of a set of code) to register is no >>>>>> different to subsequent instances of that same application. How >>>>>> were you envisioning an AS knowing the difference between the >>>>>> first and subsequent instances of an application, specifically? >>>>>> If there's an "application_id" like you mention above, I think it >>>>>> raises more questions than it resolves: Who issues the >>>>>> application_id, some server or the application itself? Is it >>>>>> validated at all? Should it be considered secret? What happens >>>>>> when someone simply steals an application_id? Does an AS have to >>>>>> do anything to check with any other AS to see if the >>>>>> application_id has already been used elsewhere? >>>>>> I do agree that a discussion of "instance vs. application" would >>>>>> be helpful in clearing this up, I'll make a note to add text to >>>>>> that effect. (We had to do something similar for BB+) >>>>>> I think it is simple enough to at least add a self generated UUID >>>>>> for the application ID. Though I would allow for cases where the >>>>>> application ID is assigned when the client developer and the APIs >>>>>> owner do a formal assignment of application IDs. >>>>>> In a sense this is just a lower tech way of doing it than what >>>>>> you described as the initial client credential in Blue Button+ >>>>>> where you encoded extra claims into the initial app credential. >>>>>> What the UUID does is link multiple instances of a client app >>>>>> together as the same "thing" that should have similar >>>>>> heuristics/behaviours. This is very useful if you want to be >>>>>> able to revoke access to a set of clients identified by >>>>>> application id (or a version of that app). >>>>>> While I’m sympathetic to the OAuth working group eventually doing >>>>>> work on differentiating between instances of an OAuth client, >>>>>> I’ll note that in RFC 6749 or RFC 6750 there is no such thing as >>>>>> a client instance. There are only clients, which are identified >>>>>> by client_id values. If we want to do work on client instances, >>>>>> we should recharter to add this new work as a working group >>>>>> deliverable. We should not try to shoehorn bits and pieces of it >>>>>> into the Dynamic Registration spec, any more than we should have >>>>>> tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is >>>>>> there to register clients as defined in RFC 6749. It’s not the >>>>>> right place to extend what an OAuth client is in new ways. >>>>>> >>>>>> 2. How are client credentials managed. Are we assuming >>>>>> client credentials have a limited lifetime or rotation >>>>>> policy? >>>>>> The intent was that client_secret could be rotated, as >>>>>> indicated by the expires_at member of the response. If a >>>>>> client's secret expires, it calls the read operation on >>>>>> the Client Configuration Endpoint (§4.2) to get its new >>>>>> client_secret. If this is unclear in the current text >>>>>> (which I suspect it may be after multiple refactorings), >>>>>> then I welcome suggestions and specific text as to how to >>>>>> make that clear. >>>>>> >>>>>> Something like this should be in the draft. >>>>>> Should this be up in the introductory text, somewhere else, >>>>>> or have its own section? >>>>>> >>>>>> I'm starting to think credential management is a key part of the >>>>>> draft. It may be worth introducing a specific section outling the >>>>>> registration life-cycle, registration access token usage, and >>>>>> client token usage and bootstrapping. >>>>>> I think that adding a discussion on this would be fine, as it >>>>>> could help developers understand the workflow of registering, >>>>>> using, and updating registered clients. >>>>>> >>>>>> How does a client authenticate the first time and subsequent >>>>>> times to the registration service? >>>>>> This is a separate question all together, as it does not >>>>>> involve the client_secret or client_id at all. Rather, the >>>>>> first time the client shows up to the registration service, >>>>>> it may either: >>>>>> - Not authenticate at all (this is the true public, open >>>>>> registration, and it is recommended that servers do this) >>>>>> - Authenticate using an OAuth 2.0 token (which ATM means a >>>>>> bearer token). How the client gets that bearer token and what >>>>>> the bearer token means to the AS beyond "this client is >>>>>> authorized to register" is out of scope for the spec, by design. >>>>>> Subsequent times that the same registered client (by which we >>>>>> mean the same instance of a client with a particular >>>>>> client_id) shows up at the registration endpoint (actually, >>>>>> the Client Configuration Endpoint), it uses its Registration >>>>>> Access Token that it was issued on initial registration. This >>>>>> is an OAuth 2.0 Bearer token that is unique to the client >>>>>> instance. >>>>>> >>>>>> Something like this should be in the draft. >>>>>> OK, the definition of the registration access token can be >>>>>> expanded, but I think that the rest of it is already in there in >>>>>> §3. I'd welcome suggestions on which bits of this could be made >>>>>> clearer. >>>>>> See the discussion on what the registration_access_token is in >>>>>> the thread “Client Credential Expiry and new Registration Access >>>>>> Token - draft-ietf-oauth-dyn-reg-10”. I will work with Justin to >>>>>> apply these clarifications to the specification. This may go into >>>>>> the proposed credential management overview section discussed above. >>>>>> >>>>>> 3. How is versioning of clients managed? Should each new >>>>>> version of a client require a change in client >>>>>> registration including possibly changing client_id and >>>>>> authentication credential? I don't have a strong feeling, >>>>>> but it is something that implementors should consider. >>>>>> >>>>>> This is up to the AS, really, and I don't think that any >>>>>> global policy would ever fly here. Especially if you consider >>>>>> that the entire notion of "version" is more fluid these days >>>>>> than it ever has been. I wouldn't mind adding a discussion in >>>>>> the security considerations if it merits mentioning though, >>>>>> so that we can help both client developers and server >>>>>> developers institute reasonably good policy. >>>>>> >>>>>> I guess the issue is that when a client upgrades it may have >>>>>> access to the old credentials. What is the intent then of >>>>>> registration. Since you have an update are clients expected to >>>>>> update /re-register or not? I'm not sure this is a security >>>>>> consideration but more part of the whole change management >>>>>> function dynamic registration supports. >>>>>> If your upgraded version of the client still has access to its >>>>>> old credentials, why wouldn't it just use those? I don't see a >>>>>> reason for forcing a re-registration. Nor do I see any way that >>>>>> an AS would even be able to tell that a client had been upgraded. >>>>>> An upgraded client always has the *option* of re-registering >>>>>> itself and getting a new client_id. >>>>>> I think the concern here is that rotation of client credential is >>>>>> not something discussed before. Before we put it in the spec we >>>>>> should consider the reasons for doing it and what problems it solves. >>>>>> I think this may be just a case of letting people exchange >>>>>> credentials for whatever reason they feel is appropriate. The >>>>>> version upgrade thing suggests that when a client is upgraded it >>>>>> should go to the registration server to "re-register". Depending >>>>>> on the policy of the server, it may (or may not) receive a new >>>>>> client_id and/or new credential. >>>>>> One of the best benefits I can think of is if you discover a >>>>>> version of a client has a problem, being able to select a group >>>>>> of clients by software and version is important. Thus if >>>>>> client_id doesn't trace to a particular software and version, >>>>>> that makes it hard to do. I think you talked about this as an >>>>>> issue for Blue Button+ >>>>>> Again, RFC 6749 defines no client instances or groups of clients, >>>>>> therefore I believe that it’s inappropriate to do so here. We >>>>>> don’t need to boil the ocean. If a new charter item is approved >>>>>> to do work on client instances and protocol elements to use and >>>>>> express them, that’s the time for the working group to consider >>>>>> that possibility – not as part of Dynamic Client Registration. >>>>>> >>>>>> 4. What is the registration access token? Why is is used? >>>>>> What is its life-cycle? When is it issued, when is it >>>>>> changed? When is it deleted? >>>>>> See the response above above and the definition in §1.2: >>>>>> >>>>>> Registration Access Token: An OAuth 2.0 Bearer Token >>>>>> issued by the Authorization Server through the Client >>>>>> Registration Endpoint which is used by the Client to >>>>>> authenticate itself during read, update, and delete >>>>>> operations. This token is associated with a particular >>>>>> Client. >>>>>> >>>>>> If this can be clarified, I welcome text suggestions. >>>>>> >>>>>> The latter part of 1.2 didn't seem like terminology but rather >>>>>> architecture or part of the introduction that describes what the >>>>>> spec does. The third point doesn't seem to fit with the other two >>>>>> except to say that the dynamic registration endpoints use their >>>>>> own access tokens called registration access tokens. >>>>>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>>>>> a Client can request new registration. The means of the Client >>>>>> obtaining the URL for this endpoint are out of scope for this >>>>>> specification. >>>>>> >>>>>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>>>>> which a specific Client can manage its registration information, >>>>>> provided by the Authorization Server to the Client. This URL for >>>>>> this endpoint is communicated to the client by the Authorization >>>>>> Server in the Client Information Response. >>>>>> >>>>>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the >>>>>> Authorization Server through the Client Registration Endpoint >>>>>> which is used by the Client to authenticate itself during read, >>>>>> update, and delete operations. This token is associated with a >>>>>> particular Client. >>>>>> This section is meant to just introduce the new terms that are >>>>>> then explained in greater detail throughout the rest of the >>>>>> document. Yes, it's a bit architecture, but only in the sense >>>>>> that you need to define the terms that make up your architecture. >>>>>> How would you suggest that it change? >>>>>> Probably this is more a matter of style. But, what happened for >>>>>> me is I naturally skipped the terminology section, as I wasn't >>>>>> expecting protocol components to be there. "terminology" is >>>>>> something I think people tend to use as a dictionary rather than >>>>>> as protocol component description. Maybe the chairs can advise? >>>>>> >>>>>> If we distinguish between first time registration of a >>>>>> particular client software package, it is possible that >>>>>> somethings like authentication method can be negotiate in or >>>>>> out-of-band at that time. Subsequent registrations should >>>>>> only have parameters for items that could change per >>>>>> deployment (like tos_uri). I think >>>>>> token_endpoint_auth_method is one thing that should not be >>>>>> negotiated per instance. >>>>>> >>>>>> When subsequent instances register, I have to ask the >>>>>> question, for example when would things like >>>>>> "token_endpoint_auth_method" be negotiated or be >>>>>> different for the same client software? Should not all >>>>>> instances use the same authentication method. >>>>>> >>>>>> I'm confused by this -- as far as the dynamic registration >>>>>> spec is concerned, all instances are separate from each >>>>>> other. All parameters change per instance. And instance, you >>>>>> should keep in mind, is defined as any one copy of the client >>>>>> code connecting to any new authorization server. That pairing >>>>>> creates the client_id, and therefore the instance, and >>>>>> therefore the registration access token, and therefore the >>>>>> registration itself at a conceptual level. So there is no way >>>>>> other than per-instance for a client to ask for a particular >>>>>> token_endpoint_auth_method. Where else would the AS find out >>>>>> about it? >>>>>> >>>>>> We still disagree on this. It is my assertion that clients should >>>>>> NEVER ask for a particular token auth method. Since it is the AS >>>>>> that is authenticating the client, then it is the AS's right to >>>>>> set the authentication policy. The role of dynamic reg endpoint >>>>>> is to inform the client what it must do. My assumption is that >>>>>> during the first time a piece of software is registered (the >>>>>> first instance), there could be some OOB discussion by an >>>>>> administrator to approve the particular authentication type for >>>>>> the AS in question. >>>>>> I haven't heard a reason justifying this parameter other then "it >>>>>> is needed". Why? >>>>>> The role of the dynamic registration protocol is twofold: half of >>>>>> that is the server informing the client what it must do. But the >>>>>> other half is the client informing the server what it *can* do, >>>>>> or what it *wants* to do. >>>>>> And again, there's no way to distinguish a first instance from a >>>>>> subsequent instance unless you're doing something in addition. >>>>>> Nothing is stopping the same application from registering a new >>>>>> instance of itself for every single user or every single token >>>>>> that it wants to get access for. That's complicated and wasteful >>>>>> and not a great idea, sure, but there's no useful way to prevent >>>>>> that kind of behavior if you also want open registration of clients. >>>>>> I think we've discussed how recognizing subsequent instances is >>>>>> easily done. >>>>>> As I mentioned in the other thread, if a developer chooses to >>>>>> limit the capabilities of the client it must do so by looking to >>>>>> the developer or standard behind the API. Otherwise they are >>>>>> taking the chance. There's no way a developer can query all the >>>>>> potential deployers to ask what authn types will you use. As I >>>>>> said, the net effect in the absence of an API standard dictating >>>>>> what should be supported, the developer will have to implement >>>>>> all methods. >>>>>> My point here is that none of this is helped by the client app >>>>>> saying what it supports. A developer who takes the route of >>>>>> limiting implementation takes the chance that the server will not >>>>>> accept. So why negotiate within registration? >>>>>> >>>>>> And there's no way other than per-instance for the server to >>>>>> tell the client which token_endpoint_auth_method to use. All >>>>>> instances will probably ask for the same >>>>>> token_endpoint_auth_method from all auth servers they talk >>>>>> to, right? And each AS will tell each instance that registers >>>>>> with it to use a particular auth method. There is no way to >>>>>> tie together different instances across (or within) auth >>>>>> servers without specifying a significant amount of other >>>>>> machinery. >>>>>> >>>>>> Which is not to say that it's not useful in some >>>>>> circumstances to tie together different instances of the same >>>>>> code across (or within) auth servers. This is why, with Blue >>>>>> Button+, we specified a specific token format for the initial >>>>>> access token that the clients use to call the registration >>>>>> endpoint the first time, as well as a discovery protocol >>>>>> against a centralized server that handles pre-registration. >>>>>> All of this machinery is, in my opinion, a stupendous >>>>>> overkill for the general case, though if some folks find use >>>>>> for it outside of BB+ then it'd be a good thing to abstract >>>>>> out and make its own spec that extends the Dyn Reg spec in a >>>>>> fully compatible way. Furthermore, even in Blue Button+ we >>>>>> specify that all auth servers MUST also accept open >>>>>> registration, without an initial access token, where the >>>>>> client simply shows up and says "hey, here are my >>>>>> parameters." The auth server has no way to know in this case >>>>>> any kind of out-of-band negotiation for different things. In >>>>>> BB+ we are writing very specific policy guidelines about how >>>>>> to present the UX and things to the end user for all of these >>>>>> different cases. But again, all of this is specific to the >>>>>> BB+ use case, and I don't see value in dragging it in to the >>>>>> registration spec on its own. I believe it would be far too >>>>>> limiting. >>>>>> >>>>>> See my previous comments on differentiating client instances >>>>>> being out of scope without rechartering to do this new work >>>>>> and on what the registration_access_token is. In short, the >>>>>> registration_access_token is an RFC 6750 bearer token issued >>>>>> to the party registering the client, enabling it to >>>>>> subsequently retrieve information about the client >>>>>> registration and to potentially update the registration >>>>>> information for that registered client. Again, I’ll work >>>>>> with Justin to make sure that this is as clear as possible in >>>>>> the specification. >>>>>> >>>>>> Finally, there seems to be an inconsistent style approach >>>>>> with draft-hardjono-oauth-resource-reg >>>>>> which >>>>>> uses ETags. Should this draft do so as well? >>>>>> That's an individual submission, not a working group draft. >>>>>> Nobody has, until now, even mentioned the use of ETags here. >>>>>> UMA (where the resource registration draft comes from) uses >>>>>> ETags, hence their inclusion there. I personally don't see >>>>>> their utility here, though, and I wouldn't want to include a >>>>>> wholly new mechanism this late. >>>>>> >>>>>> Yes. Thomas' draft is not a WG document. But that doesn't mean he >>>>>> doesn't have a point. It's worth discussing. >>>>>> One could argue that the point of an ETag is that it is useful >>>>>> for change detection when there are multiple writers to a >>>>>> particular resource. In the design of dynamic registration >>>>>> endpoint, there should only be one writer -- the client. This is >>>>>> an important observation. >>>>>> There are other mechanisms that handle this -- namely, the >>>>>> registration access token and the client_id. Many instances >>>>>> include the client_id in some form in the client configuration >>>>>> endpoint's URL for sanity checking, as described in §4.1. >>>>>> If everyone agrees, I'm in agreement. But it will likely mean >>>>>> changes for the resource reg draft if adopted. >>>>>> ETags seem like an unnecessary addition (and potential >>>>>> complication) to the specification. It’s already working fine as-is. >>>>>> >>>>>> */Specific items:/* >>>>>> --------------------- >>>>>> *"token_endpoint_auth_method"* >>>>>> There is some confusion as to whether this applies to server >>>>>> or client authentication. Suggest renaming parameter to >>>>>> "token_endpoint_client_auth_method" >>>>>> This is the first I've heard of this particular confusion. >>>>>> I'm fine with either name but at this stage I don't want to >>>>>> make syntax changes without very, very compelling reasons to >>>>>> do so. >>>>>> >>>>>> The question was raised to me by some new developers. It seems >>>>>> obvious to us as experienced OAuth persons, but to new developers >>>>>> it seems unclear. Also, now that you are introducing >>>>>> registration authentication, the whole thing gets very confusing. >>>>>> So it is useful disambiguate all the parameters where possible. >>>>>> That said, I wouldn't mind shorter names (maybe not quite as >>>>>> short as the JOSE stuff ;-) >>>>>> Fair enough, but again, I only want to do syntax changes if the >>>>>> rest of the WG *really* wants to. >>>>>> I agree with Justin here. I’m fine clarifying the description of >>>>>> this parameter to resolve the potential ambiguities that you >>>>>> cite, Phil. I’m not OK revising the syntax without a compelling >>>>>> reason to do so. >>>>>> >>>>>> * Currently, the API only supports a single value instead of >>>>>> an array. If the purpose is to allow the client to know what >>>>>> auth methods it supports, this should be an array indicated >>>>>> what methods the client supports - or it should not be used. >>>>>> I would rather like this to be an array, personally, and >>>>>> brought it up with the OpenID Connect working group about six >>>>>> months ago. But there it was decided that a single value was >>>>>> simpler and sufficient for the purpose. The IETF draft has >>>>>> inherited this decision. I *believe* (though am not 100% >>>>>> positive) that I brought up this very issue in the WG here >>>>>> but didn't receive any traction on it, so single it remains. >>>>>> >>>>>> I can get behind multiple values. In this case, it changes the >>>>>> meaning of the parameter. Instead of the client forcing the >>>>>> server to use a particular method, the client is informing the >>>>>> server about what methods it can perform. This allows the server >>>>>> to assign the appropriate method based on its own policy. >>>>>> >>>>>> Also note that this field, like all others in §2, represents two >>>>>> things: the client telling the server "I want to use this value >>>>>> for this field", and the server telling the client "this is the >>>>>> value you have for this field". It's not exactly a negotiation, >>>>>> more like making a polite request to an absolute dictator who has >>>>>> the last word anyway. But at least this dictator is nice enough >>>>>> to tell you what their decision was instead of just decapitating you. >>>>>> This is the heart of my objection. This fuzziness is is going to >>>>>> lead to interop issues. >>>>>> There is no fuzziness that I can see here. It's parallelism >>>>>> between what goes in to the endpoint and what comes out of it. >>>>>> The semantics for the request and the response are different, and >>>>>> differentiable by the fact that one is a request and the other is >>>>>> a response. >>>>>> The inter-op issue I would like to point out is that the spec >>>>>> does not currently specify if particular input values are >>>>>> singular or multiple. If an implementer assumes singular and >>>>>> clients assume multiple, we have issues. >>>>>> The multiple/single discussion above gets to the heart of what I >>>>>> **do** believe is a deficiency in the specification, as it’s >>>>>> currently written. The authors, myself included, have failed to >>>>>> make it 100% clear that discovery of Authorization Server >>>>>> functionality is out of scope for this specification. I strongly >>>>>> believe that we need to add a clear statement to this effect in >>>>>> the introduction to the specification. >>>>>> The purpose of the Dynamic Client Registration specification is >>>>>> for the client to register with the Authorization Server and to >>>>>> inform it of properties of the client that the AS may want/need >>>>>> to be aware of. It **is not** the purpose of this specification >>>>>> for it to be used by clients in any manner to discover features >>>>>> of the Authorization Server. That should be explicitly out of scope. >>>>>> Currently, clients are instructed by RFC 6749 to discover >>>>>> information about Authorization Servers they interact with by >>>>>> consulting the “service documentation” (RFC 6749, Sections 3.1 >>>>>> and 3.2). They can also learn information about Authorization >>>>>> Servers in specific contexts through discovery protocols such as >>>>>> OpenID Connect Discovery >>>>>> (http://openid.net/specs/openid-connect-discovery-1_0.html) and >>>>>> UMA Discovery (TBD). >>>>>> I suspect that at some point, someone in the OAuth working group >>>>>> will propose developing a generic OAuth discovery mechanism, >>>>>> which will lead to a rechartering to include this work in the >>>>>> working group’s set of deliverables. I would support doing this >>>>>> work and the necessary rechartering to do so. >>>>>> That being said, I strongly oppose trying to shoehorn piecemeal >>>>>> aspects of discovery into the Dynamic Client Registration >>>>>> specification. It is distinct functionality and deserves >>>>>> first-class and separable treatment by the working group. >>>>>> Discovery is for potential clients to learn properties of the AS >>>>>> before registration. Registration is for potential clients to >>>>>> inform the AS of its properties, creating a registered client. >>>>>> Discovery sends information about the AS to the Client. >>>>>> Registration sends information about the Client to the AS. >>>>>> That’s a clean separation. We should strongly resist muddying >>>>>> the two functions. >>>>>> OAuth 2.0 is a success because it didn’t try to boil the ocean. >>>>>> It specified how to do one thing well in a simple, web-friendly >>>>>> manner. We should do the same – focusing on specifying >>>>>> interoperable dynamic client registration, while making it clear >>>>>> that this is distinct from discovery about Authorization Server >>>>>> properties, and making it clear that discovery is out of scope >>>>>> for this work. >>>>>> I apologize at this point on behalf of myself and the other spec >>>>>> editors for not being 100% clear that discovery functionality is >>>>>> explicitly out of scope for Dynamic Client Registration. If we >>>>>> had done so, I’m sure that many of the current questions and >>>>>> confusions would not have arisen. I think we’d assumed that this >>>>>> was obvious, but from the current discussions, it’s apparent that >>>>>> it’s not obvious. I will personally commit to clarifying the >>>>>> specification at this point to eliminate this potential point of >>>>>> confusion. >>>>>> Getting back to the specifics, the only useful purpose of a >>>>>> multi-valued “token_endpoint_client_auth_method” member would be >>>>>> to enable the client to discover information about the >>>>>> authentication methods supported by the AS after the registration >>>>>> had been performed. But that is a discovery function, and so >>>>>> should be part of the discovery work – not this specification. We >>>>>> should resist shoehorning in bits of discovery into this >>>>>> specification. It **is** a worthwhile topic, but deserves full >>>>>> consideration by the working group in its own right. Therefore, >>>>>> this member must remain single-valued, and be clearly specified >>>>>> as the method by which a client informs the AS which token >>>>>> endpoint authentication method it will use. Anything else would >>>>>> be scope creep, and result in an unnecessarily complicated >>>>>> specification and unnecessarily complicated clients. >>>>>> >>>>>> * There is no authn method for "client_secret_saml" or >>>>>> "private_key_saml". >>>>>> Nobody has really asked that these two be included or >>>>>> specified. The extension mechanism (using an absolute URI) >>>>>> would allow someone else to define these. Is the definition >>>>>> in the SAML Assertion draft sufficient for their use? >>>>>> >>>>>> I think this is coming from the fact that there is a JWT bearer >>>>>> draft and a SAML bearer draft. The truth is you are defining an >>>>>> authentication that isn't even defined. >>>>>> >>>>>> /There are no profiles referenced or defined for >>>>>> "client_secret_jwt" or "private_key_jwt". Neither of the >>>>>> JWT or SAML Bearer drafts referenced cover these types of >>>>>> flows. They only cover bearer flows. "client_secret_jwt" >>>>>> and "private_key_jwt" seem to have some meaning within >>>>>> OpenID Connect, but I note that OIDC does not fully >>>>>> define these either./ >>>>>> The JWT assertion draft does say how to use a JWT for >>>>>> client authentication, and the DynReg text differentiates >>>>>> between a client signing said JWT with its own secret >>>>>> symmetrically vs. a client using its own private key, >>>>>> asymmetrically. >>>>>> >>>>>> Actually my interpretation is the JWT draft assumes the JWT >>>>>> Bearer is a bearer token. The assumption is that if a client >>>>>> has the assertion it has the right to present it. IOW. The >>>>>> JWT Bearer Draft is most definitively not a JWT HoK Draft. :-) >>>>>> Regardless, you are introducing a new profile which is undefined. >>>>>> >>>>>> I think I see the point that you're making now, let me try to >>>>>> re-state it: >>>>>> While the basics of "how to present a JWT as a client credential" >>>>>> is defined here: >>>>>> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, >>>>>> it's not completely specified in that it doesn't fully restrict >>>>>> the signature secret source, the audience claim, and other things >>>>>> that the AS would need to check and validate. Right? The dynamic >>>>>> registration draft can define those cases in greater detail if >>>>>> needed (though I think it does so sufficiently as-is, I welcome >>>>>> more clarity). >>>>>> I'd be OK with adding the SAML bit, going into greater detail on >>>>>> the JWT bits, or dropping the JWT bits, if the WG wants to do any >>>>>> of those actions. My objection is that the JWT stuff is already >>>>>> in use and functioning and it'd be a shame to leave it out. >>>>>> I guess then the mistake the JWT Bearer and SAML Bearer drafts >>>>>> authors made is they assumed everyone had the same definition of >>>>>> bearer token. To me a bearer token opaque to the client. It >>>>>> therefore cannot do any signature work with regards to the token >>>>>> itself. Now, that's not to say a proof didn't occur between the >>>>>> client and the token issuer, but when the client wields the >>>>>> token, it is handling an opaque string. >>>>>> The concept of client_secret_jwt suggests an HoK profile. >>>>>> Therefore of course the bearer drafts are a little >>>>>> underspecified when it comes to HoK profiles. >>>>>> So for example, you need a draft like the MAC draft for this. >>>>>> I'm having trouble overall here. It seems the authn types suggest >>>>>> ONLY strong authentication for clients, yet during the >>>>>> registration process the current draft isn't able to correlate >>>>>> multiple instances of the same software (even in a self-asserted >>>>>> way). If you haven't authenticated the software at all, why have >>>>>> strong client auth? >>>>>> >>>>>> There is no authentication method defined for >>>>>> "client_bearer_saml" or "client_bearer_jwt" or >>>>>> "client_bearer_ref". Since the bearer specs say this >>>>>> is acceptable, the dynamic registration spec should >>>>>> accept these. >>>>>> I don't understand this bit -- where are these >>>>>> defined in RFC6750? I don't even know what >>>>>> client_bearer_ref would refer to. >>>>>> >>>>>> 6750 says you can use a bearer assertion (e.g. obtained >>>>>> from an IDP) and wield it as an authentication assertion. >>>>>> The client is NOT creating or modifying the assertion. >>>>>> The client is simply passing one it previously obtained. >>>>>> What you are describing is not bearer. It is holder of >>>>>> key. Very very different. >>>>>> >>>>>> A possible suggestion is to remove client_secret_jwt and >>>>>> private_key_jwt and define those as register extensions >>>>>> since these profiles are not defined. >>>>>> That's possible, but they are in active use already. >>>>>> That may be true. But then you need to write another >>>>>> draft so the rest of us can implement it in an >>>>>> interoperable way. Me I prefer not to guess what you are >>>>>> doing. >>>>>> >>>>>> This much I agree with. >>>>>> Justin, John, and I discussed this issue and agree with your >>>>>> suggestion, Phil. Since they are not completely specified, >>>>>> we will remove the client_secret_jwt and private_key_jwt >>>>>> methods from the specification and add a registry, enabling >>>>>> specification that do fully specify these and other token >>>>>> endpoint authentication methods, including potential methods >>>>>> using SAML assertions, to register them in the registry, >>>>>> rather than trying to bake them into the Dynamic Client >>>>>> Registration specification. >>>>>> >>>>>> *About "tos_uri" and "policy_uri"* >>>>>> The distinction between tos_uri and policy_uri is >>>>>> unclear. Can we clarify or combine them? >>>>>> Terms of service and policy are two different documents. >>>>>> One is something that a user accepts (generally >>>>>> describing what the user will do), one is a statement of >>>>>> what the service provider (in this case, the client) will >>>>>> do. More importantly, we used to have only one, and >>>>>> several people asked for them to be split. >>>>>> >>>>>> Several developers were confused by this. In particular they >>>>>> couldn't figure out which was used for what. Just passing >>>>>> along the feedback. >>>>>> OK, the distinction that I see is that the TOS is >>>>>> contractual, the Policy is a statement. Re-reading the >>>>>> definitions in there right now, that can be made much >>>>>> clearer. (It even looks like some OIDC text leaked into the >>>>>> definition of policy_uri and that hadn't been caught yet.) >>>>>> I support clarifying the language on these definitions, and >>>>>> will work with Justin to do so. >>>>>> >>>>>> Also, aren't these really URIs or are they meant to be URLs? >>>>>> There was already discussion about this on the list: The >>>>>> IETF is apparently trying to deprecate URL in favor of >>>>>> URI in new specs. So in practice they'll nearly always be >>>>>> URLs, but since all URLs are URIs we're not technically >>>>>> incorrect in following the new policy. And it makes the >>>>>> IESG less mad at us, which is a plus. >>>>>> >>>>>> Arg. Nice. Then the text should say the value passed must >>>>>> resolve to a valid web page, document, whatever. >>>>>> That's fair, and it's something that the AS can even check if >>>>>> it wants to. >>>>>> Agreed on this clarification. >>>>>> >>>>>> *About "jwks_uri"* >>>>>> A normative reference for >>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is >>>>>> needed. >>>>>> Yes, you're correct, I'll add that. >>>>>> Should be URL instead of URI? >>>>>> See above. :) >>>>>> Agreed on adding this reference. >>>>>> *Section 2.1* >>>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>>>> is missing. >>>>>> It's there in the copy of -10 I'm reading off ofietf.org >>>>>> right now … ? >>>>>> >>>>>> ' >>>>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>>>>> Ah, that makes more sense. If the WG wants to add in SAML >>>>>> support to parallel the JWT support, I'd be OK with that. >>>>>> >>>>>> “As such, a server supporting these fields SHOULD take >>>>>> steps to ensure that a client cannot register itself into >>>>>> an inconsistent state.” >>>>>> >>>>>> We may want to define more detailed HTTP error >>>>>> response. E.g. 400 status code + defined error code >>>>>> (“invalid_client_metadata”)? >>>>>> I'd be fine with defining a more explicit error state in >>>>>> this case. I think it would help interop for the servers >>>>>> that want to enforce grant-type and response-type >>>>>> restrictions, but servers that can't or don't care about >>>>>> restricting grants types and whatnot don't have to do >>>>>> anything special. >>>>>> I **think** that this goes away with the deletion of >>>>>> client_secret_jwt and private_key_jwt in favor of the >>>>>> registry… I’ll do a consistency check and verify that >>>>>> when the spec is updated accordingly. >>>>>> *Section 2.2* >>>>>> May want to add: >>>>>> When “#” language tag is missing, (e.g. “#en” is missing >>>>>> in “client_name”, instead of “client_name#en”) the OAuth >>>>>> server may use interpret the language used based on >>>>>> server configuration or heuristics. >>>>>> That seems inconsistent with what we already have: >>>>>> >>>>>> If any human-readable field is sent without a >>>>>> language tag, parties using it MUST NOT make any >>>>>> assumptions about the language, character set, or >>>>>> script of the string value, and the string value MUST >>>>>> be used as-is wherever it is presented in a user >>>>>> interface. >>>>>> >>>>>> Which is to say, treat it as a raw byte-value-string and >>>>>> don't try to get fancy. >>>>>> >>>>>> I will discuss with our developers. I'm not sure the as-is >>>>>> works. >>>>>> Is it the intent that when the client has localized >>>>>> "client_name" for example, it should pass all language >>>>>> variations in a JSON array? >>>>>> Or, should part of the registration be to indicate which >>>>>> interface language the client wishes to use? Then it only >>>>>> passes a single value for that registration? >>>>>> No, the client should pass parameters as multiple separate >>>>>> values. Connect has this in its example: >>>>>> >>>>>> "client_name": "My Example", >>>>>> >>>>>> "client_name#ja-Jpan-JP": >>>>>> >>>>>> "クライアント名", >>>>>> >>>>>> Should we add that to at least one of the examples in DynReg? >>>>>> (The language tags are a late addition, so the examples don't >>>>>> reflect it.) >>>>>> >>>>>> An example would definitely help. >>>>>> >>>>>> If the client passes only a single unadorned field, the AS >>>>>> can't make any assumption about what language it is. Think of >>>>>> this as the internationalized value of the field while the >>>>>> language tags are the localized versions of the field. This >>>>>> is why we recommend that the bare-value always be sent by the >>>>>> client, so that in the lack of anything more specific, the AS >>>>>> can at least do *something* with it. >>>>>> Passing in a "default" language field (like default_locale or >>>>>> the like) is only going to lead to pain for implementors of >>>>>> both clients and servers, and it's going to hurt the >>>>>> interoperability of the human-readable fields. >>>>>> >>>>>> I think what I meant is since you are allowing each client to >>>>>> register different things, AND the client likely already knows >>>>>> the user's preferred language, why wouldn't the client just pass >>>>>> text values in one language and another parameter indicating >>>>>> preferred language in the case of any service generated text. >>>>>> Is the reason you are passing multiple localizations is so that >>>>>> you can use the preferred language of the resource owner rather >>>>>> then the client user? I wonder if that is correct. If the >>>>>> language preferences are in fact different, what would the user >>>>>> of the client app expect? >>>>>> ----> any multi-lingual people have any opinions here? >>>>>> >>>>>> Without specific proposed text changes to review, it’s hard >>>>>> to know what to think about this comment. Unless a specific >>>>>> proposed text change is sent to the list with clear rationale >>>>>> for why it’s better than what’s there now and reviewed by the >>>>>> working group, I don’t believe we should change the >>>>>> specification in response to this comment. >>>>>> >>>>>> *Section 3* >>>>>> Existing text: >>>>>> >>>>>> “In order to support open registration and facilitate >>>>>> wider interoperability, the Client Registration >>>>>> Endpoint SHOULD allow initial registration requests with >>>>>> no authentication. These requests MAY be rate-limited or >>>>>> otherwise limited to prevent a denial-of-service attack >>>>>> on the Client Registration Endpoint.” >>>>>> >>>>>> I would suggest to change the first “SHOULD” to “MAY”. >>>>>> In most cloud services, the first client is registered >>>>>> by a human user. Then, other clients can be further used >>>>>> to automate other client registration. So, the >>>>>> first request would typically come with an authenticated >>>>>> user identity. >>>>>> I think the weight of "SHOULD" is appropriate here, >>>>>> because I believe that turning off open registration at >>>>>> the AS (which is what this is talking about) really ought >>>>>> to be the exception rather than the rule. >>>>>> >>>>>> I think you are reading it wrong -- a double-negative issue. >>>>>> The end of the sentence is "no authentication". You are >>>>>> implying that NO Authentication us what should normally be >>>>>> done. I think you intend anonymous authentication to be the >>>>>> exception rather than the rule don't you? >>>>>> No, I think that anonymous authentication should be the rule. >>>>>> Open registration should be default. >>>>>> >>>>>> I disagree. Again, the spec seems contradictory. It suggests >>>>>> strong client auth methods and at the same time anonymous >>>>>> registration. Yes you gain uniqueness, but that's about it. >>>>>> >>>>>> >>>>>> On the flip side, the earlier paragraph: >>>>>> >>>>>> “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.” >>>>>> >>>>>> I tend to think it would be better to change this “MAY” to >>>>>> “SHOULD”. >>>>>> >>>>>> That access token would carry a human user >>>>>> authenticated identity somehow. In some cases, it can be a >>>>>> pure authenticated user assertion token. >>>>>> Again, disagree, for the same reasoning as above. >>>>>> >>>>>> Same reasoning. >>>>>> >>>>>> I agree with Justin here. The default should be that open >>>>>> registrations are enabled. The exception case is that specific >>>>>> permissions are required to perform dynamic client registration. >>>>>> >>>>>> *About section 4.3:* >>>>>> If the client does not exist on this server, the server MUST respond >>>>>> with HTTP 401 Unauthorized, and the Registration Access Token used to >>>>>> make this request SHOULD be immediately revoked. >>>>>> If the Client does not exist on this server, shouldn't it return >>>>>> a "404 Not Found"? >>>>>> >>>>>> If revoking the registration access token, is it bound to a >>>>>> single client registration? This is not clear. What is the >>>>>> lifecycle around registration access token? Only hint is in the >>>>>> Client Information Response in section 5.1. >>>>>> The language about the 401 here (and in other nearby sections) is >>>>>> specifically so that you treat a missing client and a bad >>>>>> registration access token the same way. You see, returning a 404 >>>>>> here actually indicates things were in an inconsistent state. >>>>>> Namely, that the registration access token was still valid but >>>>>> the client that the registration access token was attached to >>>>>> doesn't exist anymore. The registration access token in meant to >>>>>> be tied to a client's instance (or registration), so it's >>>>>> actually more sensible to act as though the registration access >>>>>> token isn't valid anymore. In at least some implementations >>>>>> (specifically ours at MITRE that's built on SECOAUTH in Java), >>>>>> you'd never be able to reach the 404 state due to consistency >>>>>> checking with the inbound token. >>>>>> Since the intent of the registration access token is that it's >>>>>> bound to a single instance, its lifecycle is generally tied to >>>>>> the lifecycle begins at the issuance of a new client_id with that >>>>>> instance. That token might be revoked and a new one issued on >>>>>> Read and Update requests to the Client Configuration Endpoint >>>>>> (and the client needs to be prepared for that -- same as the >>>>>> client_secret), and it will be revoked when the client is deleted >>>>>> either with a Delete call to the Client Configuration Endpoint or >>>>>> something happening out-of-band to kill the client. >>>>>> Should we add more explanatory text to the definition in the >>>>>> terminology section? Elsewhere? I'm very open to concrete >>>>>> suggestions with this, since I don't think it's as clear as we'd >>>>>> like. >>>>>> I think we should look at it. >>>>>> >>>>>> For security reasons, it’s generally not good to distinguish >>>>>> between “not found” and “unauthorized” errors in responses, as >>>>>> that can provide the attacker an oracle to probe whether a >>>>>> particular entity exists I don’t think a change is called for here. >>>>>> >>>>>> *About section 5.1:* >>>>>> Is registration_access_token unique? Or is it shared by multiple >>>>>> instances? If shared, then registration_access_token can't be >>>>>> revoked on delete of client. >>>>>> The registration_access_token is unique to a registered client, >>>>>> in the RFC 6749 sense of “client”. Again, if we want to do work >>>>>> on “client instances”, we need to recharter and take this >>>>>> distinct work item up explicitly. >>>>>> >>>>>> Suggest rename “expires_at” to “client_secret_expires_at”, >>>>>> >>>>>> Suggest to rename “issued_at” to “id_issued_at” >>>>>> While I do like the suggestion of changing these to >>>>>> client_secret_expires_at and client_id_issued_at, and I think >>>>>> these are more clear and readable, >>>>>> >>>>>> >>>>>> I don't want to change the syntax during last call unless there >>>>>> is a clear need and a clear consensus for doing so. >>>>>> That's why we are having last call. To confirm consensus on the >>>>>> draft. >>>>>> Same reasoning as earlier. You now have multiple tokens >>>>>> (registration access and client) in play. The spec needs to be >>>>>> clear which one it is talking about. >>>>>> I'm fine with the suggested change but I would like more feedback >>>>>> from other people before moving forward with it. There's a lot of >>>>>> value in "just pick a name and ship it" as well though, and I >>>>>> don't want to devolve into bike shedding. (I'm not accusing you >>>>>> of bike shedding quite yet, btw, just afraid of getting into a >>>>>> long debate on names.) >>>>>> Again, this was a problem raised by people new to the >>>>>> specification. They found it confusing. I tend to agree. We're >>>>>> not talking about what colour to paint the shed. We're talking >>>>>> about whether the bike shed is a house. :-) >>>>>> I'm not too fussed about whether you call it "cl_sec_expiry" or >>>>>> "client_secret_expires_at". >>>>>> >>>>>> If the definitions of “expires_at” or “issued_at” are unclear, we >>>>>> should clarify them. If you believe that this is the case Phil, >>>>>> can you supply proposed alternative definition text that is >>>>>> clearer? That being said, I believe that at this point we should >>>>>> stick with the existing protocol element names unless >>>>>> overwhelming working group sentiment emerges to change them. >>>>>> They are already working fine as-is in production deployments. >>>>>> >>>>>> *Section 7* >>>>>> When a client_secret expires is it the intent that clients do >>>>>> an update or refresh to get a new client secret? >>>>>> Yes, the client is supposed to either call the read or update >>>>>> methods on the client configuration endpoint to get its new >>>>>> secret. As discussed above, I'm not sure that's as clear as >>>>>> it needs to be, and I welcome suggestions on how to clarify this. >>>>>> Either is a reasonable behavior on the behalf of clients, >>>>>> depending upon context. I support adding text to clarify this. >>>>>> Again, thanks for the very thorough read through. Have you >>>>>> implemented any of the spec yet, either as-is or with any of >>>>>> your suggested changes? >>>>>> >>>>>> Yes. Much of the feedback is coming from our development community. >>>>>> Ah, very cool. Developer experience is the most valuable >>>>>> feedback, in my opinion. If you can't actually build the blasted >>>>>> thing, what good is it? :) >>>>>> Glad to hear that you’re working with developers building the >>>>>> spec. Please thank them for the feedback. >>>>>> -- Justin >>>>>> Best wishes, >>>>>> -- Mike >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >> --------------040609070108020907040404 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit What's clear to me now is that what we're disagreeing on, at a fundamental level, is what dynamic registration is for. It is currently written to enable self-asserted registration of clients, with hooks in place to allow for higher assurance with further specification. What you want is for that latter, and while I see value in that, I think that case is far more complicated than you're giving it credit for. It is absolutely new functionality, because you're tying together multiple client_ids at an AS.

If you want to do a public client still do that with a single client_id. You just now have other options as a client developer (including not making it a public client anymore, which ought to be a big win, right?). I'm sorry, but I'm failing to see what the disconnect is here.

Also, auth type is required for the client to talk to the token endpoint. It's very useful in cases when you have clients and servers that can do several different things and you need to pick one. If your server doesn't enforce it or your client can't handle it, don't use the parameter. End of story.

 -- Justin

On 05/21/2013 11:00 AM, Phil Hunt wrote:
Regarding charter. 

The charter is a one-liner. To say associating clients is not in the charter while saying every other 'new' thing that is in the spec (eg client auth type) is in is laughable. After all the entire draft is new functionality. 

The item i have asked for is not new. It preserves information that was available without reg. Namely a way to recognize multiple clients as a common public client as in 6749 they share a client_id.  The draft throws this information away preventing security admins from making any judgements since all clients are now anonymized.

Where in the charter does it say you can anonymize the clients? 

Phil

On 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org> wrote:


On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case.


  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:

And dynamic client registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case.

There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.
[JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…
 
(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.
 
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the registration service?
 
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.
 
3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.
 
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?
 
See the response above above and the definition in §1.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.
 
   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.
 
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.
 
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
* There is no authn method for "client_secret_saml" or "private_key_saml".
 
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.
 
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:
 
While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.
 
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant-type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect has this in its example:
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.
 
Section 3
 
Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.
 
The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. 
 
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
 
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.
 
 -- Justin
 
                                                            Best wishes,
                                                            -- Mike




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



--------------040609070108020907040404-- From jricher@mitre.org Tue May 21 08:44:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC721F9731 for ; Tue, 21 May 2013 08:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR47-VsV1Zc3 for ; Tue, 21 May 2013 08:44:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAED21F9714 for ; Tue, 21 May 2013 08:44:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B62BE1F0967; Tue, 21 May 2013 11:44:01 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 849F81F02E0; Tue, 21 May 2013 11:44:01 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 11:44:01 -0400 Message-ID: <519B9623.8030403@mitre.org> Date: Tue, 21 May 2013 11:43:31 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070002050108020008060001" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 15:44:04 -0000 --------------070002050108020008060001 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Phil, I am considering the knowledge model. You could say that we're "throwing away" a shared client_id in one case, because now public clients don't have to be public clients anymore in many cases. Native apps that used to have to be public clients (because they would otherwise all be shipped with the same client_secret) are no longer forced to do that. Each copy can register itself independently. Most of the time this means that the app will just present its pre-configured set of metadata to the AS, and get back a client_id and client_secret all for its own. I don't see how it's possible for an AS to know a client is a member of a "class" or running a particular copy (or version, or instance, etc.) of a piece of code without specifying a large amount of other mechanisms. However, you can still do public clients with a shared client id if you do some kind of manual registration. You don't need dynamic registration for this case because it's easy to just bake the client_id into all of your clients. The "class" of public clients is "tied together" in the manual registration case because the developer went to the AS's webpage and got a client_id to bake into their clients. That doesn't go away. But if you want all copies of your public clients to get the same client_id at all AS's they talk to (or otherwise be linked together), then you're going to need do specify a *whole* lot more than just registration. And it's not at all needed for what I (and others) see as the "normal" case for registration. This is why I want to leave it out of the registration spec and let it get the attention it deserves on its own. -- Justin On 05/21/2013 10:26 AM, Phil Hunt wrote: > Justin, > > Please re-consider what I was saying. You are not cnsidering what was > known without reg and what is known after dyn reg. > > In public clients, you are changing the meaning of client_id. > > You are throwing away what was shared among all public clients (a > client id) running the same software. > > When you issue a separate id you need to retain what was known before > which was critically important-a set of clients share the same > software and thus behave in certain ways. > > Gaining a unique cred while losing information about what the software > is makes dyn reg's value dramatically reduced. > > Phil > > On 2013-05-21, at 6:46, Justin Richer > wrote: > >> >> On 05/21/2013 02:01 AM, Phil Hunt wrote: >>> >>> >>> Phil >>> >>> On 2013-05-20, at 8:35, Justin Richer >> > wrote: >>> >>>> >>>> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>>>> Mike, >>>>> >>>>> Rather then embed comments in an extended thread, I'd like to open >>>>> up a specific discussion on the objective of dyn reg. >>>>> >>>>> I see limited to no value in having clients completely anonymously >>>>> registering and receiving tokens without any ability to correlate >>>>> applications between applications. >>>> >>>> I think that herein lies a very big disconnect in assumptions. I >>>> see a huge benefit in anonymously registered clients getting tokens >>>> because there is an end-user in the loop during the authorization >>>> phase (long after registration has happened). The arity of >>>> registrations to authorizations approaches 1:1 in these cases, and >>>> I'm just fine with that. >>> Then what you describe is NOT anonymous but rather a profile not >>> covered by the spec as there is no discussion of user authenticated >>> registration. Implicitly or explicitly. >> >> [JR] I think you misunderstand what I said, let me try to be more >> explicit: the user is not authenticating the registration. The user >> is not involved in the registration. The user might not even know >> that a registration happened. The registration is (normally) >> completely anonymous and open, the client just shows up and says "Hi, >> I'm a client!". >> >> The "authorization" that I mentioned happens later and is a normal >> OAuth authorization, which has a user involved like usual. The >> authorization step in OAuth depends on *some* kind of registration >> happening beforehand, dynamic or otherwise. This is all perfectly >> within the model of OAuth. >> >>>> >>>> From the RFC6749 perspective, a "client" is not a particular piece >>>> of code, it is a particular copy of a piece of code with a >>>> particular client_id from the vantage point of a particular >>>> authorization server. >>> actually, i disagree. This spec fundamentally breaks the old >>> definition and behavior from 6749. In the old way every instance of >>> software shared a client_id. In this draft, u throw that away >>> without preserving the information. This is BAD! >> [JR] No, we're not throwing that away at all. The concept is the >> same, but when you add new functionality, the mechanics change a bit. >> A "client_id" was always pairwise between a client and an AS. If a >> client had to talk to two AS's before, it would have two client_ids. >> That's still the case. If there were multiple copies of a >> confidential client, you need to get a client_id and client_secret to >> each copy. That's still the case. What's different is that we've made >> it *easier* for a particular piece of code to get different >> client_ids when it's talking to the same or a different auth server, >> at runtime. When you have to manually register every client, you're >> going to just do it once. If you can do it dynamically, you have more >> options. >> >> Note that you can *still* have a public client with a known client_id >> if you want to. You don't even need to use dynamic registration for >> that. Heck, you don't need to use dynamic registration for any kind >> of client if you don't want to, since most services will probably >> still offer manual registration through some portal kind of page. >> >>> >>> >>>> A "client" is, conceptually, a pairwise association between two >>>> running codebases. When you have a particular piece of code talking >>>> only to one auth server and being manually configured at said auth >>>> server with its client_id, this is fairly clear and straightforward >>>> and the arity is simple. Things get a bit muddy when you introduce >>>> dynamic registration, which is why I think that we need to have >>>> introductory text about this. Specifically: >>>> >>>> - a particular piece of code can be run on multiple devices and >>>> talk to the same auth server, each copy of that code getting its >>>> own client_id. >>>> - a particular copy of a particular piece of code can now be >>>> expected to talk to multiple auth servers, each auth server giving >>>> the piece of code its own client_id. >>>> >>>> Both of these are cases of what defines an "instance" in most >>>> people's heads, even though it's the same software, even sometimes >>>> the same running copy of the same software. But as far as RFC6749's >>>> definition of "client" is concerned, these are all completely >>>> separate "client"s with no way to tie them together out of the box. >>>> And that's fine. >>>> >>>>> >>>>> Associating client_id's with known client applications to allow >>>>> admins to know who is running what version of clients seems to be >>>>> the most fundamental part of the reason for dynamic reg. How can >>>>> you revoke access to particular client app types? As Justin >>>>> already talked about in his Blue Button+ scenario, there are often >>>>> life and death situations where particular sets of clients need to >>>>> be revoked. >>>> While it's very useful, I wouldn't (and haven't) classified it >>>> quite like that. Nor would I say that the BB+ profile is a complete >>>> solution -- our Registry component does not actually push >>>> revocation notifications down to Providers (yet), so it's more like >>>> invalidating a root certificate and waiting for caches to time out >>>> for things to cascade. We've been talking about adding some form of >>>> callback to providers, but we don't want to boil that particular >>>> ocean right now. However, the BB+ profile makes use of a >>>> well-specified discovery and Registry set up, as well as data >>>> conveyed in structured, signed tokens (JWTs) at different points in >>>> the process. >>>> >>>>> >>>>> Or put another way. I believe this will be a critical operational >>>>> requirement going forwards. If the spec is published as is, it >>>>> will be quickly invalidated by one that does at least partially >>>>> address the problem. >>>> That's not true at all. BB+ addresses this scenario and still uses >>>> the Dynamic Registration spec as-is. I would encourage folks to >>>> read what we're doing, a work-in-progress found here: >>> but you are breaking other things and overloading client cred >>> etc to pass in signed data. I don't want a hack for a solution. I >>> want interop. >> [JR] I'm curious, what exactly are we breaking? If anything in BB+ >> breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that >> we need to fix there. It is our intent to be fully compatible with >> OAuth Dyn Reg, and we are even explicitly calling for open >> registration as mandatory to implement for authorization servers >> within BB+, even though we have additional mechanisms as well for >> what we're calling "trusted registrations". For those trusted >> registrations, we're not using the client *credentials* to pass in >> signed data, we're using the initial *registration authentication* >> mechanism (which is to say, an OAuth token) for its intended purpose: >> authorizing the holder of this token access to the registration >> endpoint. In BB+, we're profiling exactly what that means. To wit, we >> define the content of the token (which is fully compatible with >> DynReg which doesn't care what's in the token) and how the AS can >> verify it (which DynReg doesn't care how it happens) and we've added >> some additional rules and policies that allow us to tie together >> instances of the client across the distributed network. >> >> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a >> huge amount of very specific machinery (signed tokens with known >> formats and fields, a Registry with manual pre-registration, a >> three-tiered discovery service with information about clients and >> service providers rooted at the Registry, trust frameworks and >> network enforcement policies that all players have to agree to before >> playing, etc.), and it's not really doing just registration anymore. >> In BB+, we needed the Registry and Discovery services to do other >> functions as well apart from just registration, and so it makes sense >> to re-use them. >> >> If there were a simple solution that didn't leave security holes the >> size of a small army, I'd be glad to bring it to the table. But I am >> convinced that a good solution for managing client instances across a >> network requires a lot more thought and consideration, and I believe >> that having a fully specified discovery service will help this case, >> like it has helped in BB+. But I think that it's a complex enough >> problem that it needs its own set of considerations. With DynReg, we >> need to leave things open for that work in the future, and I believe >> we have, but we shouldn't kill the simple, general case for want of a >> special case. >> >>>> >>>> http://blue-button.github.io/blue-button-plus-pull/ >>>> >>>> Just because you make something better doesn't mean you throw >>>> necessarily away everything you've done to date. >>>> >>>>> >>>>> We're ahead of schedule, lets talk through the requirement. >>>> I believe that the requirement of tying instances together is >>>> explicitly out of scope for the dynamic registration protocol. I >>>> intended to have text to that effect in the section I'm adding >>>> about the client lifecycle. >>> >>> where is this stated in charter? >> [JR] The charter for the working states what's in scope, not what's >> out of scope, correct? It has been my understanding of IETF process >> that additional functionality needs to be considered separately. All >> the charter says about registration is this: >> >> And dynamic client registration will make >> it easier to broadly deploy OAuth clients (performing services to >> users). >> >> >> And: >> >> Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >> the IESG for consideration as a Proposed Standard >> >> There's nothing in there at all about tying together client >> instances. I have not seen anything to convince me that management of >> client instances across a deployed network of auth servers is a >> necessary part of basic client registration. It sounds very likely to >> me that it *is* required for your use case, but that doesn't make it >> required for everybody's use case. >> >> There are other important pieces of functionality that the WG isn't >> picking up right now (such as token chaining and token introspection) >> that are absolutely necessary for my own use cases, but I think it >> makes sense for those to be separate modules. >> >>>> >>>>> >>>>> As I mentioned in my comments to the other thread. Let's say we >>>>> agree not do this now. Well, then the new draft that does solve it >>>>> would likely be 95% overlap. Thus I see this issue as within >>>>> charter and should be solved now rather then waiting for a V2 dyn >>>>> reg in the next charter. >>>> Why wouldn't the new draft just be the extra 5%? I personally think >>>> that it's a lot more than 5% once you have in all the assurance and >>>> safety mechanisms in place to avoid self-asserted values causing >>>> race conditions, and what not. >>> >>> Two drafts to do registration is not the way to go. It implies >>> complexity where there should be none. There is no technical reason >>> for two drafts. >> [JR] There is a need when there's a special case that requires a >> large amount of overhead to be done correctly, to allow the general >> case to move forward and be used on its own (as it is being used today). >> >>>> >>>> -- Justin >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-05-17, at 1:08 PM, Mike Jones wrote: >>>>> >>>>>> Thanks for the detailed feedback, Phil. Sorry for the delayed >>>>>> response – I was pretty fully engaged at the European Identity >>>>>> Conference (whereOAuth 2.0 won the award for best new standard >>>>>> J). My feedback on the points >>>>>> raised is inline in green… >>>>>> (Perhaps if any of you reply to this thread, you could also >>>>>> choose a distinctcolorfor your inline replies, so that it will be >>>>>> easily evident who said what. As it is, just the back-and-forth >>>>>> between Phil and Justin is already very difficult to follow. Thanks.) >>>>>> *From:*oauth-bounces@ietf.org >>>>>> [mailto:oauth-bounces@ietf.org]*On >>>>>> Behalf Of*Phil Hunt >>>>>> *Sent:*Thursday, May 16, 2013 12:54 PM >>>>>> *To:*Richer, Justin P. >>>>>> *Cc:*oauth@ietf.org WG >>>>>> *Subject:*Re: [OAUTH-WG] Last call review of >>>>>> draft-ietf-oauth-dyn-reg-10 >>>>>> Justin, >>>>>> Thanks for the discussion. More comments below... >>>>>> BTW. I'm happy to contribute text. Just want to get to some rough >>>>>> agreement first. For example, I think we need to have a away to >>>>>> recognize two pieces of software as being the same (even if >>>>>> self-asserted). Once defined, I can put together some intro >>>>>> text, etc. >>>>>> Phil >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: >>>>>> On May 15, 2013, at 10:30 PM, Phil Hunt >>>>> > >>>>>> wrote: >>>>>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: >>>>>> Phil, many thanks for the extremely thorough review! It is very >>>>>> useful indeed. >>>>>> My comments and responses to each point are inline. >>>>>> On May 15, 2013, at 4:30 PM, Phil Hunt >>>>> > wrote: >>>>>> It seems unfortunate that I have not gotten a chance to get into >>>>>> this level of detail much earlier. But then, I guess that's what >>>>>> LC review is for! My apologies for not getting many of these >>>>>> concerns to the WG much earlier. >>>>>> */Overall /* >>>>>> ----------- >>>>>> I think dynamic registration is a critical part of the OAuth >>>>>> framework now that we are starting to consider how individual >>>>>> client applications should operate when there is one or more >>>>>> deployments of a particular resource API. We've moved from the >>>>>> simple use case of a single API provider like Facebook or Flickr >>>>>> and moved on to standards based, open source based, and >>>>>> commercial based deployments where there are multiple service >>>>>> endpoints and many clients to manage. >>>>>> The dynamic registration spec is actually dealing with a couple >>>>>> of issues that I would like to see made more clear in early part >>>>>> of the spec: >>>>>> 1. How is a new client application recognized for the first time >>>>>> when deployed against a particular SP endpoint? Should clients >>>>>> actually assert an application_id UUID that never changes and >>>>>> possibly a version id that does change with versions? >>>>>> In the general case, why is any recognition required? If you're >>>>>> doing things as part of a larger protocol ecosystem, like Blue >>>>>> Button+ or a particular OpenID Connect provider, then you can >>>>>> define semantics for tying together classes of clients (see below >>>>>> for more discussion on this very point). But in general, a client >>>>>> is just going to show up as a new instance to the AS and get >>>>>> issued a new, unique client_id, and that's that. >>>>>> I think we have to define more clearly what an "instance" is. For >>>>>> me, there are applications and there are instances of that >>>>>> application. It is useful to understand that a client >>>>>> application represents a set of code that should behave in a >>>>>> consistent way. It seems to me the first time a new application >>>>>> shows up is very different from the subsequent instances that >>>>>> register. For example, after the first registration, subsequent >>>>>> instances don't need special review or approval to the same degree. >>>>>> But without other mechanisms to tie things together, there's no >>>>>> way for an authorization server to know if any client instance is >>>>>> tied to any other client instance. Therefore, from the >>>>>> perspective of an AS, the first instance of an application (i.e., >>>>>> particular configuration of a set of code) to register is no >>>>>> different to subsequent instances of that same application. How >>>>>> were you envisioning an AS knowing the difference between the >>>>>> first and subsequent instances of an application, specifically? >>>>>> If there's an "application_id" like you mention above, I think it >>>>>> raises more questions than it resolves: Who issues the >>>>>> application_id, some server or the application itself? Is it >>>>>> validated at all? Should it be considered secret? What happens >>>>>> when someone simply steals an application_id? Does an AS have to >>>>>> do anything to check with any other AS to see if the >>>>>> application_id has already been used elsewhere? >>>>>> I do agree that a discussion of "instance vs. application" would >>>>>> be helpful in clearing this up, I'll make a note to add text to >>>>>> that effect. (We had to do something similar for BB+) >>>>>> I think it is simple enough to at least add a self generated UUID >>>>>> for the application ID. Though I would allow for cases where the >>>>>> application ID is assigned when the client developer and the APIs >>>>>> owner do a formal assignment of application IDs. >>>>>> In a sense this is just a lower tech way of doing it than what >>>>>> you described as the initial client credential in Blue Button+ >>>>>> where you encoded extra claims into the initial app credential. >>>>>> What the UUID does is link multiple instances of a client app >>>>>> together as the same "thing" that should have similar >>>>>> heuristics/behaviours. This is very useful if you want to be >>>>>> able to revoke access to a set of clients identified by >>>>>> application id (or a version of that app). >>>>>> While I’m sympathetic to the OAuth working group eventually doing >>>>>> work on differentiating between instances of an OAuth client, >>>>>> I’ll note that in RFC 6749 or RFC 6750 there is no such thing as >>>>>> a client instance. There are only clients, which are identified >>>>>> by client_id values. If we want to do work on client instances, >>>>>> we should recharter to add this new work as a working group >>>>>> deliverable. We should not try to shoehorn bits and pieces of it >>>>>> into the Dynamic Registration spec, any more than we should have >>>>>> tried to shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is >>>>>> there to register clients as defined in RFC 6749. It’s not the >>>>>> right place to extend what an OAuth client is in new ways. >>>>>> >>>>>> 2. How are client credentials managed. Are we assuming >>>>>> client credentials have a limited lifetime or rotation >>>>>> policy? >>>>>> The intent was that client_secret could be rotated, as >>>>>> indicated by the expires_at member of the response. If a >>>>>> client's secret expires, it calls the read operation on >>>>>> the Client Configuration Endpoint (§4.2) to get its new >>>>>> client_secret. If this is unclear in the current text >>>>>> (which I suspect it may be after multiple refactorings), >>>>>> then I welcome suggestions and specific text as to how to >>>>>> make that clear. >>>>>> >>>>>> Something like this should be in the draft. >>>>>> Should this be up in the introductory text, somewhere else, >>>>>> or have its own section? >>>>>> >>>>>> I'm starting to think credential management is a key part of the >>>>>> draft. It may be worth introducing a specific section outling the >>>>>> registration life-cycle, registration access token usage, and >>>>>> client token usage and bootstrapping. >>>>>> I think that adding a discussion on this would be fine, as it >>>>>> could help developers understand the workflow of registering, >>>>>> using, and updating registered clients. >>>>>> >>>>>> How does a client authenticate the first time and subsequent >>>>>> times to the registration service? >>>>>> This is a separate question all together, as it does not >>>>>> involve the client_secret or client_id at all. Rather, the >>>>>> first time the client shows up to the registration service, >>>>>> it may either: >>>>>> - Not authenticate at all (this is the true public, open >>>>>> registration, and it is recommended that servers do this) >>>>>> - Authenticate using an OAuth 2.0 token (which ATM means a >>>>>> bearer token). How the client gets that bearer token and what >>>>>> the bearer token means to the AS beyond "this client is >>>>>> authorized to register" is out of scope for the spec, by design. >>>>>> Subsequent times that the same registered client (by which we >>>>>> mean the same instance of a client with a particular >>>>>> client_id) shows up at the registration endpoint (actually, >>>>>> the Client Configuration Endpoint), it uses its Registration >>>>>> Access Token that it was issued on initial registration. This >>>>>> is an OAuth 2.0 Bearer token that is unique to the client >>>>>> instance. >>>>>> >>>>>> Something like this should be in the draft. >>>>>> OK, the definition of the registration access token can be >>>>>> expanded, but I think that the rest of it is already in there in >>>>>> §3. I'd welcome suggestions on which bits of this could be made >>>>>> clearer. >>>>>> See the discussion on what the registration_access_token is in >>>>>> the thread “Client Credential Expiry and new Registration Access >>>>>> Token - draft-ietf-oauth-dyn-reg-10”. I will work with Justin to >>>>>> apply these clarifications to the specification. This may go into >>>>>> the proposed credential management overview section discussed above. >>>>>> >>>>>> 3. How is versioning of clients managed? Should each new >>>>>> version of a client require a change in client >>>>>> registration including possibly changing client_id and >>>>>> authentication credential? I don't have a strong feeling, >>>>>> but it is something that implementors should consider. >>>>>> >>>>>> This is up to the AS, really, and I don't think that any >>>>>> global policy would ever fly here. Especially if you consider >>>>>> that the entire notion of "version" is more fluid these days >>>>>> than it ever has been. I wouldn't mind adding a discussion in >>>>>> the security considerations if it merits mentioning though, >>>>>> so that we can help both client developers and server >>>>>> developers institute reasonably good policy. >>>>>> >>>>>> I guess the issue is that when a client upgrades it may have >>>>>> access to the old credentials. What is the intent then of >>>>>> registration. Since you have an update are clients expected to >>>>>> update /re-register or not? I'm not sure this is a security >>>>>> consideration but more part of the whole change management >>>>>> function dynamic registration supports. >>>>>> If your upgraded version of the client still has access to its >>>>>> old credentials, why wouldn't it just use those? I don't see a >>>>>> reason for forcing a re-registration. Nor do I see any way that >>>>>> an AS would even be able to tell that a client had been upgraded. >>>>>> An upgraded client always has the *option* of re-registering >>>>>> itself and getting a new client_id. >>>>>> I think the concern here is that rotation of client credential is >>>>>> not something discussed before. Before we put it in the spec we >>>>>> should consider the reasons for doing it and what problems it solves. >>>>>> I think this may be just a case of letting people exchange >>>>>> credentials for whatever reason they feel is appropriate. The >>>>>> version upgrade thing suggests that when a client is upgraded it >>>>>> should go to the registration server to "re-register". Depending >>>>>> on the policy of the server, it may (or may not) receive a new >>>>>> client_id and/or new credential. >>>>>> One of the best benefits I can think of is if you discover a >>>>>> version of a client has a problem, being able to select a group >>>>>> of clients by software and version is important. Thus if >>>>>> client_id doesn't trace to a particular software and version, >>>>>> that makes it hard to do. I think you talked about this as an >>>>>> issue for Blue Button+ >>>>>> Again, RFC 6749 defines no client instances or groups of clients, >>>>>> therefore I believe that it’s inappropriate to do so here. We >>>>>> don’t need to boil the ocean. If a new charter item is approved >>>>>> to do work on client instances and protocol elements to use and >>>>>> express them, that’s the time for the working group to consider >>>>>> that possibility – not as part of Dynamic Client Registration. >>>>>> >>>>>> 4. What is the registration access token? Why is is used? >>>>>> What is its life-cycle? When is it issued, when is it >>>>>> changed? When is it deleted? >>>>>> See the response above above and the definition in §1.2: >>>>>> >>>>>> Registration Access Token: An OAuth 2.0 Bearer Token >>>>>> issued by the Authorization Server through the Client >>>>>> Registration Endpoint which is used by the Client to >>>>>> authenticate itself during read, update, and delete >>>>>> operations. This token is associated with a particular >>>>>> Client. >>>>>> >>>>>> If this can be clarified, I welcome text suggestions. >>>>>> >>>>>> The latter part of 1.2 didn't seem like terminology but rather >>>>>> architecture or part of the introduction that describes what the >>>>>> spec does. The third point doesn't seem to fit with the other two >>>>>> except to say that the dynamic registration endpoints use their >>>>>> own access tokens called registration access tokens. >>>>>> Client Registration Endpoint: The OAuth 2.0 Endpoint through which >>>>>> a Client can request new registration. The means of the Client >>>>>> obtaining the URL for this endpoint are out of scope for this >>>>>> specification. >>>>>> >>>>>> o Client Configuration Endpoint: The OAuth 2.0 Endpoint through >>>>>> which a specific Client can manage its registration information, >>>>>> provided by the Authorization Server to the Client. This URL for >>>>>> this endpoint is communicated to the client by the Authorization >>>>>> Server in the Client Information Response. >>>>>> >>>>>> o Registration Access Token: An OAuth 2.0 Bearer Token issued by the >>>>>> Authorization Server through the Client Registration Endpoint >>>>>> which is used by the Client to authenticate itself during read, >>>>>> update, and delete operations. This token is associated with a >>>>>> particular Client. >>>>>> This section is meant to just introduce the new terms that are >>>>>> then explained in greater detail throughout the rest of the >>>>>> document. Yes, it's a bit architecture, but only in the sense >>>>>> that you need to define the terms that make up your architecture. >>>>>> How would you suggest that it change? >>>>>> Probably this is more a matter of style. But, what happened for >>>>>> me is I naturally skipped the terminology section, as I wasn't >>>>>> expecting protocol components to be there. "terminology" is >>>>>> something I think people tend to use as a dictionary rather than >>>>>> as protocol component description. Maybe the chairs can advise? >>>>>> >>>>>> If we distinguish between first time registration of a >>>>>> particular client software package, it is possible that >>>>>> somethings like authentication method can be negotiate in or >>>>>> out-of-band at that time. Subsequent registrations should >>>>>> only have parameters for items that could change per >>>>>> deployment (like tos_uri). I think >>>>>> token_endpoint_auth_method is one thing that should not be >>>>>> negotiated per instance. >>>>>> >>>>>> When subsequent instances register, I have to ask the >>>>>> question, for example when would things like >>>>>> "token_endpoint_auth_method" be negotiated or be >>>>>> different for the same client software? Should not all >>>>>> instances use the same authentication method. >>>>>> >>>>>> I'm confused by this -- as far as the dynamic registration >>>>>> spec is concerned, all instances are separate from each >>>>>> other. All parameters change per instance. And instance, you >>>>>> should keep in mind, is defined as any one copy of the client >>>>>> code connecting to any new authorization server. That pairing >>>>>> creates the client_id, and therefore the instance, and >>>>>> therefore the registration access token, and therefore the >>>>>> registration itself at a conceptual level. So there is no way >>>>>> other than per-instance for a client to ask for a particular >>>>>> token_endpoint_auth_method. Where else would the AS find out >>>>>> about it? >>>>>> >>>>>> We still disagree on this. It is my assertion that clients should >>>>>> NEVER ask for a particular token auth method. Since it is the AS >>>>>> that is authenticating the client, then it is the AS's right to >>>>>> set the authentication policy. The role of dynamic reg endpoint >>>>>> is to inform the client what it must do. My assumption is that >>>>>> during the first time a piece of software is registered (the >>>>>> first instance), there could be some OOB discussion by an >>>>>> administrator to approve the particular authentication type for >>>>>> the AS in question. >>>>>> I haven't heard a reason justifying this parameter other then "it >>>>>> is needed". Why? >>>>>> The role of the dynamic registration protocol is twofold: half of >>>>>> that is the server informing the client what it must do. But the >>>>>> other half is the client informing the server what it *can* do, >>>>>> or what it *wants* to do. >>>>>> And again, there's no way to distinguish a first instance from a >>>>>> subsequent instance unless you're doing something in addition. >>>>>> Nothing is stopping the same application from registering a new >>>>>> instance of itself for every single user or every single token >>>>>> that it wants to get access for. That's complicated and wasteful >>>>>> and not a great idea, sure, but there's no useful way to prevent >>>>>> that kind of behavior if you also want open registration of clients. >>>>>> I think we've discussed how recognizing subsequent instances is >>>>>> easily done. >>>>>> As I mentioned in the other thread, if a developer chooses to >>>>>> limit the capabilities of the client it must do so by looking to >>>>>> the developer or standard behind the API. Otherwise they are >>>>>> taking the chance. There's no way a developer can query all the >>>>>> potential deployers to ask what authn types will you use. As I >>>>>> said, the net effect in the absence of an API standard dictating >>>>>> what should be supported, the developer will have to implement >>>>>> all methods. >>>>>> My point here is that none of this is helped by the client app >>>>>> saying what it supports. A developer who takes the route of >>>>>> limiting implementation takes the chance that the server will not >>>>>> accept. So why negotiate within registration? >>>>>> >>>>>> And there's no way other than per-instance for the server to >>>>>> tell the client which token_endpoint_auth_method to use. All >>>>>> instances will probably ask for the same >>>>>> token_endpoint_auth_method from all auth servers they talk >>>>>> to, right? And each AS will tell each instance that registers >>>>>> with it to use a particular auth method. There is no way to >>>>>> tie together different instances across (or within) auth >>>>>> servers without specifying a significant amount of other >>>>>> machinery. >>>>>> >>>>>> Which is not to say that it's not useful in some >>>>>> circumstances to tie together different instances of the same >>>>>> code across (or within) auth servers. This is why, with Blue >>>>>> Button+, we specified a specific token format for the initial >>>>>> access token that the clients use to call the registration >>>>>> endpoint the first time, as well as a discovery protocol >>>>>> against a centralized server that handles pre-registration. >>>>>> All of this machinery is, in my opinion, a stupendous >>>>>> overkill for the general case, though if some folks find use >>>>>> for it outside of BB+ then it'd be a good thing to abstract >>>>>> out and make its own spec that extends the Dyn Reg spec in a >>>>>> fully compatible way. Furthermore, even in Blue Button+ we >>>>>> specify that all auth servers MUST also accept open >>>>>> registration, without an initial access token, where the >>>>>> client simply shows up and says "hey, here are my >>>>>> parameters." The auth server has no way to know in this case >>>>>> any kind of out-of-band negotiation for different things. In >>>>>> BB+ we are writing very specific policy guidelines about how >>>>>> to present the UX and things to the end user for all of these >>>>>> different cases. But again, all of this is specific to the >>>>>> BB+ use case, and I don't see value in dragging it in to the >>>>>> registration spec on its own. I believe it would be far too >>>>>> limiting. >>>>>> >>>>>> See my previous comments on differentiating client instances >>>>>> being out of scope without rechartering to do this new work >>>>>> and on what the registration_access_token is. In short, the >>>>>> registration_access_token is an RFC 6750 bearer token issued >>>>>> to the party registering the client, enabling it to >>>>>> subsequently retrieve information about the client >>>>>> registration and to potentially update the registration >>>>>> information for that registered client. Again, I’ll work >>>>>> with Justin to make sure that this is as clear as possible in >>>>>> the specification. >>>>>> >>>>>> Finally, there seems to be an inconsistent style approach >>>>>> with draft-hardjono-oauth-resource-reg >>>>>> which >>>>>> uses ETags. Should this draft do so as well? >>>>>> That's an individual submission, not a working group draft. >>>>>> Nobody has, until now, even mentioned the use of ETags here. >>>>>> UMA (where the resource registration draft comes from) uses >>>>>> ETags, hence their inclusion there. I personally don't see >>>>>> their utility here, though, and I wouldn't want to include a >>>>>> wholly new mechanism this late. >>>>>> >>>>>> Yes. Thomas' draft is not a WG document. But that doesn't mean he >>>>>> doesn't have a point. It's worth discussing. >>>>>> One could argue that the point of an ETag is that it is useful >>>>>> for change detection when there are multiple writers to a >>>>>> particular resource. In the design of dynamic registration >>>>>> endpoint, there should only be one writer -- the client. This is >>>>>> an important observation. >>>>>> There are other mechanisms that handle this -- namely, the >>>>>> registration access token and the client_id. Many instances >>>>>> include the client_id in some form in the client configuration >>>>>> endpoint's URL for sanity checking, as described in §4.1. >>>>>> If everyone agrees, I'm in agreement. But it will likely mean >>>>>> changes for the resource reg draft if adopted. >>>>>> ETags seem like an unnecessary addition (and potential >>>>>> complication) to the specification. It’s already working fine as-is. >>>>>> >>>>>> */Specific items:/* >>>>>> --------------------- >>>>>> *"token_endpoint_auth_method"* >>>>>> There is some confusion as to whether this applies to server >>>>>> or client authentication. Suggest renaming parameter to >>>>>> "token_endpoint_client_auth_method" >>>>>> This is the first I've heard of this particular confusion. >>>>>> I'm fine with either name but at this stage I don't want to >>>>>> make syntax changes without very, very compelling reasons to >>>>>> do so. >>>>>> >>>>>> The question was raised to me by some new developers. It seems >>>>>> obvious to us as experienced OAuth persons, but to new developers >>>>>> it seems unclear. Also, now that you are introducing >>>>>> registration authentication, the whole thing gets very confusing. >>>>>> So it is useful disambiguate all the parameters where possible. >>>>>> That said, I wouldn't mind shorter names (maybe not quite as >>>>>> short as the JOSE stuff ;-) >>>>>> Fair enough, but again, I only want to do syntax changes if the >>>>>> rest of the WG *really* wants to. >>>>>> I agree with Justin here. I’m fine clarifying the description of >>>>>> this parameter to resolve the potential ambiguities that you >>>>>> cite, Phil. I’m not OK revising the syntax without a compelling >>>>>> reason to do so. >>>>>> >>>>>> * Currently, the API only supports a single value instead of >>>>>> an array. If the purpose is to allow the client to know what >>>>>> auth methods it supports, this should be an array indicated >>>>>> what methods the client supports - or it should not be used. >>>>>> I would rather like this to be an array, personally, and >>>>>> brought it up with the OpenID Connect working group about six >>>>>> months ago. But there it was decided that a single value was >>>>>> simpler and sufficient for the purpose. The IETF draft has >>>>>> inherited this decision. I *believe* (though am not 100% >>>>>> positive) that I brought up this very issue in the WG here >>>>>> but didn't receive any traction on it, so single it remains. >>>>>> >>>>>> I can get behind multiple values. In this case, it changes the >>>>>> meaning of the parameter. Instead of the client forcing the >>>>>> server to use a particular method, the client is informing the >>>>>> server about what methods it can perform. This allows the server >>>>>> to assign the appropriate method based on its own policy. >>>>>> >>>>>> Also note that this field, like all others in §2, represents two >>>>>> things: the client telling the server "I want to use this value >>>>>> for this field", and the server telling the client "this is the >>>>>> value you have for this field". It's not exactly a negotiation, >>>>>> more like making a polite request to an absolute dictator who has >>>>>> the last word anyway. But at least this dictator is nice enough >>>>>> to tell you what their decision was instead of just decapitating you. >>>>>> This is the heart of my objection. This fuzziness is is going to >>>>>> lead to interop issues. >>>>>> There is no fuzziness that I can see here. It's parallelism >>>>>> between what goes in to the endpoint and what comes out of it. >>>>>> The semantics for the request and the response are different, and >>>>>> differentiable by the fact that one is a request and the other is >>>>>> a response. >>>>>> The inter-op issue I would like to point out is that the spec >>>>>> does not currently specify if particular input values are >>>>>> singular or multiple. If an implementer assumes singular and >>>>>> clients assume multiple, we have issues. >>>>>> The multiple/single discussion above gets to the heart of what I >>>>>> **do** believe is a deficiency in the specification, as it’s >>>>>> currently written. The authors, myself included, have failed to >>>>>> make it 100% clear that discovery of Authorization Server >>>>>> functionality is out of scope for this specification. I strongly >>>>>> believe that we need to add a clear statement to this effect in >>>>>> the introduction to the specification. >>>>>> The purpose of the Dynamic Client Registration specification is >>>>>> for the client to register with the Authorization Server and to >>>>>> inform it of properties of the client that the AS may want/need >>>>>> to be aware of. It **is not** the purpose of this specification >>>>>> for it to be used by clients in any manner to discover features >>>>>> of the Authorization Server. That should be explicitly out of scope. >>>>>> Currently, clients are instructed by RFC 6749 to discover >>>>>> information about Authorization Servers they interact with by >>>>>> consulting the “service documentation” (RFC 6749, Sections 3.1 >>>>>> and 3.2). They can also learn information about Authorization >>>>>> Servers in specific contexts through discovery protocols such as >>>>>> OpenID Connect Discovery >>>>>> (http://openid.net/specs/openid-connect-discovery-1_0.html) and >>>>>> UMA Discovery (TBD). >>>>>> I suspect that at some point, someone in the OAuth working group >>>>>> will propose developing a generic OAuth discovery mechanism, >>>>>> which will lead to a rechartering to include this work in the >>>>>> working group’s set of deliverables. I would support doing this >>>>>> work and the necessary rechartering to do so. >>>>>> That being said, I strongly oppose trying to shoehorn piecemeal >>>>>> aspects of discovery into the Dynamic Client Registration >>>>>> specification. It is distinct functionality and deserves >>>>>> first-class and separable treatment by the working group. >>>>>> Discovery is for potential clients to learn properties of the AS >>>>>> before registration. Registration is for potential clients to >>>>>> inform the AS of its properties, creating a registered client. >>>>>> Discovery sends information about the AS to the Client. >>>>>> Registration sends information about the Client to the AS. >>>>>> That’s a clean separation. We should strongly resist muddying >>>>>> the two functions. >>>>>> OAuth 2.0 is a success because it didn’t try to boil the ocean. >>>>>> It specified how to do one thing well in a simple, web-friendly >>>>>> manner. We should do the same – focusing on specifying >>>>>> interoperable dynamic client registration, while making it clear >>>>>> that this is distinct from discovery about Authorization Server >>>>>> properties, and making it clear that discovery is out of scope >>>>>> for this work. >>>>>> I apologize at this point on behalf of myself and the other spec >>>>>> editors for not being 100% clear that discovery functionality is >>>>>> explicitly out of scope for Dynamic Client Registration. If we >>>>>> had done so, I’m sure that many of the current questions and >>>>>> confusions would not have arisen. I think we’d assumed that this >>>>>> was obvious, but from the current discussions, it’s apparent that >>>>>> it’s not obvious. I will personally commit to clarifying the >>>>>> specification at this point to eliminate this potential point of >>>>>> confusion. >>>>>> Getting back to the specifics, the only useful purpose of a >>>>>> multi-valued “token_endpoint_client_auth_method” member would be >>>>>> to enable the client to discover information about the >>>>>> authentication methods supported by the AS after the registration >>>>>> had been performed. But that is a discovery function, and so >>>>>> should be part of the discovery work – not this specification. We >>>>>> should resist shoehorning in bits of discovery into this >>>>>> specification. It **is** a worthwhile topic, but deserves full >>>>>> consideration by the working group in its own right. Therefore, >>>>>> this member must remain single-valued, and be clearly specified >>>>>> as the method by which a client informs the AS which token >>>>>> endpoint authentication method it will use. Anything else would >>>>>> be scope creep, and result in an unnecessarily complicated >>>>>> specification and unnecessarily complicated clients. >>>>>> >>>>>> * There is no authn method for "client_secret_saml" or >>>>>> "private_key_saml". >>>>>> Nobody has really asked that these two be included or >>>>>> specified. The extension mechanism (using an absolute URI) >>>>>> would allow someone else to define these. Is the definition >>>>>> in the SAML Assertion draft sufficient for their use? >>>>>> >>>>>> I think this is coming from the fact that there is a JWT bearer >>>>>> draft and a SAML bearer draft. The truth is you are defining an >>>>>> authentication that isn't even defined. >>>>>> >>>>>> /There are no profiles referenced or defined for >>>>>> "client_secret_jwt" or "private_key_jwt". Neither of the >>>>>> JWT or SAML Bearer drafts referenced cover these types of >>>>>> flows. They only cover bearer flows. "client_secret_jwt" >>>>>> and "private_key_jwt" seem to have some meaning within >>>>>> OpenID Connect, but I note that OIDC does not fully >>>>>> define these either./ >>>>>> The JWT assertion draft does say how to use a JWT for >>>>>> client authentication, and the DynReg text differentiates >>>>>> between a client signing said JWT with its own secret >>>>>> symmetrically vs. a client using its own private key, >>>>>> asymmetrically. >>>>>> >>>>>> Actually my interpretation is the JWT draft assumes the JWT >>>>>> Bearer is a bearer token. The assumption is that if a client >>>>>> has the assertion it has the right to present it. IOW. The >>>>>> JWT Bearer Draft is most definitively not a JWT HoK Draft. :-) >>>>>> Regardless, you are introducing a new profile which is undefined. >>>>>> >>>>>> I think I see the point that you're making now, let me try to >>>>>> re-state it: >>>>>> While the basics of "how to present a JWT as a client credential" >>>>>> is defined here: >>>>>> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, >>>>>> it's not completely specified in that it doesn't fully restrict >>>>>> the signature secret source, the audience claim, and other things >>>>>> that the AS would need to check and validate. Right? The dynamic >>>>>> registration draft can define those cases in greater detail if >>>>>> needed (though I think it does so sufficiently as-is, I welcome >>>>>> more clarity). >>>>>> I'd be OK with adding the SAML bit, going into greater detail on >>>>>> the JWT bits, or dropping the JWT bits, if the WG wants to do any >>>>>> of those actions. My objection is that the JWT stuff is already >>>>>> in use and functioning and it'd be a shame to leave it out. >>>>>> I guess then the mistake the JWT Bearer and SAML Bearer drafts >>>>>> authors made is they assumed everyone had the same definition of >>>>>> bearer token. To me a bearer token opaque to the client. It >>>>>> therefore cannot do any signature work with regards to the token >>>>>> itself. Now, that's not to say a proof didn't occur between the >>>>>> client and the token issuer, but when the client wields the >>>>>> token, it is handling an opaque string. >>>>>> The concept of client_secret_jwt suggests an HoK profile. >>>>>> Therefore of course the bearer drafts are a little >>>>>> underspecified when it comes to HoK profiles. >>>>>> So for example, you need a draft like the MAC draft for this. >>>>>> I'm having trouble overall here. It seems the authn types suggest >>>>>> ONLY strong authentication for clients, yet during the >>>>>> registration process the current draft isn't able to correlate >>>>>> multiple instances of the same software (even in a self-asserted >>>>>> way). If you haven't authenticated the software at all, why have >>>>>> strong client auth? >>>>>> >>>>>> There is no authentication method defined for >>>>>> "client_bearer_saml" or "client_bearer_jwt" or >>>>>> "client_bearer_ref". Since the bearer specs say this >>>>>> is acceptable, the dynamic registration spec should >>>>>> accept these. >>>>>> I don't understand this bit -- where are these >>>>>> defined in RFC6750? I don't even know what >>>>>> client_bearer_ref would refer to. >>>>>> >>>>>> 6750 says you can use a bearer assertion (e.g. obtained >>>>>> from an IDP) and wield it as an authentication assertion. >>>>>> The client is NOT creating or modifying the assertion. >>>>>> The client is simply passing one it previously obtained. >>>>>> What you are describing is not bearer. It is holder of >>>>>> key. Very very different. >>>>>> >>>>>> A possible suggestion is to remove client_secret_jwt and >>>>>> private_key_jwt and define those as register extensions >>>>>> since these profiles are not defined. >>>>>> That's possible, but they are in active use already. >>>>>> That may be true. But then you need to write another >>>>>> draft so the rest of us can implement it in an >>>>>> interoperable way. Me I prefer not to guess what you are >>>>>> doing. >>>>>> >>>>>> This much I agree with. >>>>>> Justin, John, and I discussed this issue and agree with your >>>>>> suggestion, Phil. Since they are not completely specified, >>>>>> we will remove the client_secret_jwt and private_key_jwt >>>>>> methods from the specification and add a registry, enabling >>>>>> specification that do fully specify these and other token >>>>>> endpoint authentication methods, including potential methods >>>>>> using SAML assertions, to register them in the registry, >>>>>> rather than trying to bake them into the Dynamic Client >>>>>> Registration specification. >>>>>> >>>>>> *About "tos_uri" and "policy_uri"* >>>>>> The distinction between tos_uri and policy_uri is >>>>>> unclear. Can we clarify or combine them? >>>>>> Terms of service and policy are two different documents. >>>>>> One is something that a user accepts (generally >>>>>> describing what the user will do), one is a statement of >>>>>> what the service provider (in this case, the client) will >>>>>> do. More importantly, we used to have only one, and >>>>>> several people asked for them to be split. >>>>>> >>>>>> Several developers were confused by this. In particular they >>>>>> couldn't figure out which was used for what. Just passing >>>>>> along the feedback. >>>>>> OK, the distinction that I see is that the TOS is >>>>>> contractual, the Policy is a statement. Re-reading the >>>>>> definitions in there right now, that can be made much >>>>>> clearer. (It even looks like some OIDC text leaked into the >>>>>> definition of policy_uri and that hadn't been caught yet.) >>>>>> I support clarifying the language on these definitions, and >>>>>> will work with Justin to do so. >>>>>> >>>>>> Also, aren't these really URIs or are they meant to be URLs? >>>>>> There was already discussion about this on the list: The >>>>>> IETF is apparently trying to deprecate URL in favor of >>>>>> URI in new specs. So in practice they'll nearly always be >>>>>> URLs, but since all URLs are URIs we're not technically >>>>>> incorrect in following the new policy. And it makes the >>>>>> IESG less mad at us, which is a plus. >>>>>> >>>>>> Arg. Nice. Then the text should say the value passed must >>>>>> resolve to a valid web page, document, whatever. >>>>>> That's fair, and it's something that the AS can even check if >>>>>> it wants to. >>>>>> Agreed on this clarification. >>>>>> >>>>>> *About "jwks_uri"* >>>>>> A normative reference for >>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is >>>>>> needed. >>>>>> Yes, you're correct, I'll add that. >>>>>> Should be URL instead of URI? >>>>>> See above. :) >>>>>> Agreed on adding this reference. >>>>>> *Section 2.1* >>>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer >>>>>> is missing. >>>>>> It's there in the copy of -10 I'm reading off ofietf.org >>>>>> right now … ? >>>>>> >>>>>> ' >>>>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer >>>>>> Ah, that makes more sense. If the WG wants to add in SAML >>>>>> support to parallel the JWT support, I'd be OK with that. >>>>>> >>>>>> “As such, a server supporting these fields SHOULD take >>>>>> steps to ensure that a client cannot register itself into >>>>>> an inconsistent state.” >>>>>> >>>>>> We may want to define more detailed HTTP error >>>>>> response. E.g. 400 status code + defined error code >>>>>> (“invalid_client_metadata”)? >>>>>> I'd be fine with defining a more explicit error state in >>>>>> this case. I think it would help interop for the servers >>>>>> that want to enforce grant-type and response-type >>>>>> restrictions, but servers that can't or don't care about >>>>>> restricting grants types and whatnot don't have to do >>>>>> anything special. >>>>>> I **think** that this goes away with the deletion of >>>>>> client_secret_jwt and private_key_jwt in favor of the >>>>>> registry… I’ll do a consistency check and verify that >>>>>> when the spec is updated accordingly. >>>>>> *Section 2.2* >>>>>> May want to add: >>>>>> When “#” language tag is missing, (e.g. “#en” is missing >>>>>> in “client_name”, instead of “client_name#en”) the OAuth >>>>>> server may use interpret the language used based on >>>>>> server configuration or heuristics. >>>>>> That seems inconsistent with what we already have: >>>>>> >>>>>> If any human-readable field is sent without a >>>>>> language tag, parties using it MUST NOT make any >>>>>> assumptions about the language, character set, or >>>>>> script of the string value, and the string value MUST >>>>>> be used as-is wherever it is presented in a user >>>>>> interface. >>>>>> >>>>>> Which is to say, treat it as a raw byte-value-string and >>>>>> don't try to get fancy. >>>>>> >>>>>> I will discuss with our developers. I'm not sure the as-is >>>>>> works. >>>>>> Is it the intent that when the client has localized >>>>>> "client_name" for example, it should pass all language >>>>>> variations in a JSON array? >>>>>> Or, should part of the registration be to indicate which >>>>>> interface language the client wishes to use? Then it only >>>>>> passes a single value for that registration? >>>>>> No, the client should pass parameters as multiple separate >>>>>> values. Connect has this in its example: >>>>>> >>>>>> "client_name": "My Example", >>>>>> >>>>>> "client_name#ja-Jpan-JP": >>>>>> >>>>>> "クライアント名", >>>>>> >>>>>> Should we add that to at least one of the examples in DynReg? >>>>>> (The language tags are a late addition, so the examples don't >>>>>> reflect it.) >>>>>> >>>>>> An example would definitely help. >>>>>> >>>>>> If the client passes only a single unadorned field, the AS >>>>>> can't make any assumption about what language it is. Think of >>>>>> this as the internationalized value of the field while the >>>>>> language tags are the localized versions of the field. This >>>>>> is why we recommend that the bare-value always be sent by the >>>>>> client, so that in the lack of anything more specific, the AS >>>>>> can at least do *something* with it. >>>>>> Passing in a "default" language field (like default_locale or >>>>>> the like) is only going to lead to pain for implementors of >>>>>> both clients and servers, and it's going to hurt the >>>>>> interoperability of the human-readable fields. >>>>>> >>>>>> I think what I meant is since you are allowing each client to >>>>>> register different things, AND the client likely already knows >>>>>> the user's preferred language, why wouldn't the client just pass >>>>>> text values in one language and another parameter indicating >>>>>> preferred language in the case of any service generated text. >>>>>> Is the reason you are passing multiple localizations is so that >>>>>> you can use the preferred language of the resource owner rather >>>>>> then the client user? I wonder if that is correct. If the >>>>>> language preferences are in fact different, what would the user >>>>>> of the client app expect? >>>>>> ----> any multi-lingual people have any opinions here? >>>>>> >>>>>> Without specific proposed text changes to review, it’s hard >>>>>> to know what to think about this comment. Unless a specific >>>>>> proposed text change is sent to the list with clear rationale >>>>>> for why it’s better than what’s there now and reviewed by the >>>>>> working group, I don’t believe we should change the >>>>>> specification in response to this comment. >>>>>> >>>>>> *Section 3* >>>>>> Existing text: >>>>>> >>>>>> “In order to support open registration and facilitate >>>>>> wider interoperability, the Client Registration >>>>>> Endpoint SHOULD allow initial registration requests with >>>>>> no authentication. These requests MAY be rate-limited or >>>>>> otherwise limited to prevent a denial-of-service attack >>>>>> on the Client Registration Endpoint.” >>>>>> >>>>>> I would suggest to change the first “SHOULD” to “MAY”. >>>>>> In most cloud services, the first client is registered >>>>>> by a human user. Then, other clients can be further used >>>>>> to automate other client registration. So, the >>>>>> first request would typically come with an authenticated >>>>>> user identity. >>>>>> I think the weight of "SHOULD" is appropriate here, >>>>>> because I believe that turning off open registration at >>>>>> the AS (which is what this is talking about) really ought >>>>>> to be the exception rather than the rule. >>>>>> >>>>>> I think you are reading it wrong -- a double-negative issue. >>>>>> The end of the sentence is "no authentication". You are >>>>>> implying that NO Authentication us what should normally be >>>>>> done. I think you intend anonymous authentication to be the >>>>>> exception rather than the rule don't you? >>>>>> No, I think that anonymous authentication should be the rule. >>>>>> Open registration should be default. >>>>>> >>>>>> I disagree. Again, the spec seems contradictory. It suggests >>>>>> strong client auth methods and at the same time anonymous >>>>>> registration. Yes you gain uniqueness, but that's about it. >>>>>> >>>>>> >>>>>> On the flip side, the earlier paragraph: >>>>>> >>>>>> “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.” >>>>>> >>>>>> I tend to think it would be better to change this “MAY” to >>>>>> “SHOULD”. >>>>>> >>>>>> That access token would carry a human user >>>>>> authenticated identity somehow. In some cases, it can be a >>>>>> pure authenticated user assertion token. >>>>>> Again, disagree, for the same reasoning as above. >>>>>> >>>>>> Same reasoning. >>>>>> >>>>>> I agree with Justin here. The default should be that open >>>>>> registrations are enabled. The exception case is that specific >>>>>> permissions are required to perform dynamic client registration. >>>>>> >>>>>> *About section 4.3:* >>>>>> If the client does not exist on this server, the server MUST respond >>>>>> with HTTP 401 Unauthorized, and the Registration Access Token used to >>>>>> make this request SHOULD be immediately revoked. >>>>>> If the Client does not exist on this server, shouldn't it return >>>>>> a "404 Not Found"? >>>>>> >>>>>> If revoking the registration access token, is it bound to a >>>>>> single client registration? This is not clear. What is the >>>>>> lifecycle around registration access token? Only hint is in the >>>>>> Client Information Response in section 5.1. >>>>>> The language about the 401 here (and in other nearby sections) is >>>>>> specifically so that you treat a missing client and a bad >>>>>> registration access token the same way. You see, returning a 404 >>>>>> here actually indicates things were in an inconsistent state. >>>>>> Namely, that the registration access token was still valid but >>>>>> the client that the registration access token was attached to >>>>>> doesn't exist anymore. The registration access token in meant to >>>>>> be tied to a client's instance (or registration), so it's >>>>>> actually more sensible to act as though the registration access >>>>>> token isn't valid anymore. In at least some implementations >>>>>> (specifically ours at MITRE that's built on SECOAUTH in Java), >>>>>> you'd never be able to reach the 404 state due to consistency >>>>>> checking with the inbound token. >>>>>> Since the intent of the registration access token is that it's >>>>>> bound to a single instance, its lifecycle is generally tied to >>>>>> the lifecycle begins at the issuance of a new client_id with that >>>>>> instance. That token might be revoked and a new one issued on >>>>>> Read and Update requests to the Client Configuration Endpoint >>>>>> (and the client needs to be prepared for that -- same as the >>>>>> client_secret), and it will be revoked when the client is deleted >>>>>> either with a Delete call to the Client Configuration Endpoint or >>>>>> something happening out-of-band to kill the client. >>>>>> Should we add more explanatory text to the definition in the >>>>>> terminology section? Elsewhere? I'm very open to concrete >>>>>> suggestions with this, since I don't think it's as clear as we'd >>>>>> like. >>>>>> I think we should look at it. >>>>>> >>>>>> For security reasons, it’s generally not good to distinguish >>>>>> between “not found” and “unauthorized” errors in responses, as >>>>>> that can provide the attacker an oracle to probe whether a >>>>>> particular entity exists I don’t think a change is called for here. >>>>>> >>>>>> *About section 5.1:* >>>>>> Is registration_access_token unique? Or is it shared by multiple >>>>>> instances? If shared, then registration_access_token can't be >>>>>> revoked on delete of client. >>>>>> The registration_access_token is unique to a registered client, >>>>>> in the RFC 6749 sense of “client”. Again, if we want to do work >>>>>> on “client instances”, we need to recharter and take this >>>>>> distinct work item up explicitly. >>>>>> >>>>>> Suggest rename “expires_at” to “client_secret_expires_at”, >>>>>> >>>>>> Suggest to rename “issued_at” to “id_issued_at” >>>>>> While I do like the suggestion of changing these to >>>>>> client_secret_expires_at and client_id_issued_at, and I think >>>>>> these are more clear and readable, >>>>>> >>>>>> >>>>>> I don't want to change the syntax during last call unless there >>>>>> is a clear need and a clear consensus for doing so. >>>>>> That's why we are having last call. To confirm consensus on the >>>>>> draft. >>>>>> Same reasoning as earlier. You now have multiple tokens >>>>>> (registration access and client) in play. The spec needs to be >>>>>> clear which one it is talking about. >>>>>> I'm fine with the suggested change but I would like more feedback >>>>>> from other people before moving forward with it. There's a lot of >>>>>> value in "just pick a name and ship it" as well though, and I >>>>>> don't want to devolve into bike shedding. (I'm not accusing you >>>>>> of bike shedding quite yet, btw, just afraid of getting into a >>>>>> long debate on names.) >>>>>> Again, this was a problem raised by people new to the >>>>>> specification. They found it confusing. I tend to agree. We're >>>>>> not talking about what colour to paint the shed. We're talking >>>>>> about whether the bike shed is a house. :-) >>>>>> I'm not too fussed about whether you call it "cl_sec_expiry" or >>>>>> "client_secret_expires_at". >>>>>> >>>>>> If the definitions of “expires_at” or “issued_at” are unclear, we >>>>>> should clarify them. If you believe that this is the case Phil, >>>>>> can you supply proposed alternative definition text that is >>>>>> clearer? That being said, I believe that at this point we should >>>>>> stick with the existing protocol element names unless >>>>>> overwhelming working group sentiment emerges to change them. >>>>>> They are already working fine as-is in production deployments. >>>>>> >>>>>> *Section 7* >>>>>> When a client_secret expires is it the intent that clients do >>>>>> an update or refresh to get a new client secret? >>>>>> Yes, the client is supposed to either call the read or update >>>>>> methods on the client configuration endpoint to get its new >>>>>> secret. As discussed above, I'm not sure that's as clear as >>>>>> it needs to be, and I welcome suggestions on how to clarify this. >>>>>> Either is a reasonable behavior on the behalf of clients, >>>>>> depending upon context. I support adding text to clarify this. >>>>>> Again, thanks for the very thorough read through. Have you >>>>>> implemented any of the spec yet, either as-is or with any of >>>>>> your suggested changes? >>>>>> >>>>>> Yes. Much of the feedback is coming from our development community. >>>>>> Ah, very cool. Developer experience is the most valuable >>>>>> feedback, in my opinion. If you can't actually build the blasted >>>>>> thing, what good is it? :) >>>>>> Glad to hear that you’re working with developers building the >>>>>> spec. Please thank them for the feedback. >>>>>> -- Justin >>>>>> Best wishes, >>>>>> -- Mike >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >> --------------070002050108020008060001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Phil,

I am considering the knowledge model. You could say that we're "throwing away" a shared client_id in one case, because now public clients don't have to be public clients anymore in many cases. Native apps that used to have to be public clients (because they would otherwise all be shipped with the same client_secret) are no longer forced to do that. Each copy can register itself independently. Most of the time this means that the app will just present its pre-configured set of metadata to the AS, and get back a client_id and client_secret all for its own. I don't see how it's possible for an AS to know a client is a member of a "class" or running a particular copy (or version, or instance, etc.) of a piece of code without specifying a large amount of other mechanisms.

However, you can still do public clients with a shared client id if you do some kind of manual registration. You don't need dynamic registration for this case because it's easy to just bake the client_id into all of your clients. The "class" of public clients is "tied together" in the manual registration case because the developer went to the AS's webpage and got a client_id to bake into their clients. That doesn't go away.

But if you want all copies of your public clients to get the same client_id at all AS's they talk to (or otherwise be linked together), then you're going to need do specify a *whole* lot more than just registration. And it's not at all needed for what I (and others) see as the "normal" case for registration. This is why I want to leave it out of the registration spec and let it get the attention it deserves on its own.

 -- Justin

On 05/21/2013 10:26 AM, Phil Hunt wrote:
Justin,

Please re-consider what I was saying. You are not cnsidering what was known without reg and what is known after dyn reg. 

In public clients, you are changing the meaning of client_id. 

You are throwing away what was shared among all public clients (a client id) running the same software. 

When you issue a separate id you need to retain what was known before which was critically important-a set of clients share the same software and thus behave in certain ways. 

Gaining a unique cred while losing information about what the software is makes dyn reg's value dramatically reduced. 

Phil

On 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org> wrote:


On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case.


  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily away everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:

And dynamic client registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it required for everybody's use case.

There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.
[JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…
 
(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?
 
In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.
 
But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).
 
While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own section?
 
I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
 
I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the registration service?
 
This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.
 
3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.
 
If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id. 
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  
 
One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+
 
Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?
 
See the response above above and the definition in §1.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.
 
   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?
 
We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do. 
 
And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done.
 
As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?
 
And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

 
See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
 
ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.
 
I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.
 
I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.
 
I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to interop issues.
 
There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
 
The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.
 
The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.
 
Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.
 
Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.
 
* There is no authn method for "client_secret_saml" or "private_key_saml".
 
Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?
 
I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.
 
The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:
 
While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?
 
There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.
 
What you are describing is not bearer. It is holder of key. Very very different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?
 
Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.
 
OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant-type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.
 
“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?
 
I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get fancy.
 
I will discuss with our developers. I'm not sure the as-is works.  
 
Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?
 
Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect has this in its example:
 
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields. 
 
I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.
 
Section 3
 
Existing text:

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

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registration should be default. 
 
I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

“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.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.
 
If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.
 
Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.
 
The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”
 
While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,


I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. 
 
Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
 
I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)
 
Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at". 

If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.
 
 -- Justin
 
                                                            Best wishes,
                                                            -- Mike




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



--------------070002050108020008060001-- From phil.hunt@oracle.com Tue May 21 09:41:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8537821F98CA for ; Tue, 21 May 2013 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdv5DkFou2qn for ; Tue, 21 May 2013 09:41:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9192021F9399 for ; Tue, 21 May 2013 09:41:39 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4LGfaQI017620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 16:41:37 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LGfb4G005686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 16:41:38 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LGfbnJ019336; Tue, 21 May 2013 16:41:37 GMT Received: from [25.33.179.153] (/24.114.85.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 May 2013 09:41:36 -0700 References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <519B9623.8030403@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-A0BDF7B5-B4DF-4348-8E58-241F52341535 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 21 May 2013 09:41:28 -0700 To: Justin Richer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 16:41:49 -0000 --Apple-Mail-A0BDF7B5-B4DF-4348-8E58-241F52341535 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not quite. I will call you.=20 I am saying we are transitioning from the old public client model. The new m= odel proposes quasi-confidential characteristics but in some respects is mis= sing key information from the public model. Namely that a group of clients a= re related and there have common behaviour and security characteristics.=20 We need to add to the self-asserted model an assertion equiv to the old comm= on client_id. That is all.=20 I am NOT looking for a proof of application identity here. That is too far. B= ut certainly what we define here can open that door.=20 Phil On 2013-05-21, at 8:43, Justin Richer wrote: > Phil,=20 >=20 > I am considering the knowledge model. You could say that we're "throwing a= way" a shared client_id in one case, because now public clients don't have t= o be public clients anymore in many cases. Native apps that used to have to b= e public clients (because they would otherwise all be shipped with the same c= lient_secret) are no longer forced to do that. Each copy can register itself= independently. Most of the time this means that the app will just present i= ts pre-configured set of metadata to the AS, and get back a client_id and cl= ient_secret all for its own. I don't see how it's possible for an AS to know= a client is a member of a "class" or running a particular copy (or version,= or instance, etc.) of a piece of code without specifying a large amount of o= ther mechanisms.=20 >=20 > However, you can still do public clients with a shared client id if you do= some kind of manual registration. You don't need dynamic registration for t= his case because it's easy to just bake the client_id into all of your clien= ts. The "class" of public clients is "tied together" in the manual registrat= ion case because the developer went to the AS's webpage and got a client_id t= o bake into their clients. That doesn't go away.=20 >=20 > But if you want all copies of your public clients to get the same client_i= d at all AS's they talk to (or otherwise be linked together), then you're go= ing to need do specify a *whole* lot more than just registration. And it's n= ot at all needed for what I (and others) see as the "normal" case for regist= ration. This is why I want to leave it out of the registration spec and let i= t get the attention it deserves on its own. >=20 > -- Justin >=20 > On 05/21/2013 10:26 AM, Phil Hunt wrote: >> Justin, >>=20 >> Please re-consider what I was saying. You are not cnsidering what was kno= wn without reg and what is known after dyn reg.=20 >>=20 >> In public clients, you are changing the meaning of client_id.=20 >>=20 >> You are throwing away what was shared among all public clients (a client i= d) running the same software.=20 >>=20 >> When you issue a separate id you need to retain what was known before whi= ch was critically important-a set of clients share the same software and thu= s behave in certain ways.=20 >>=20 >> Gaining a unique cred while losing information about what the software is= makes dyn reg's value dramatically reduced.=20 >>=20 >> Phil >>=20 >> On 2013-05-21, at 6:46, Justin Richer wrote: >>=20 >>>=20 >>> On 05/21/2013 02:01 AM, Phil Hunt wrote: >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-05-20, at 8:35, Justin Richer wrote: >>>>=20 >>>>>=20 >>>>> On 05/17/2013 05:27 PM, Phil Hunt wrote: >>>>>> Mike, >>>>>>=20 >>>>>> Rather then embed comments in an extended thread, I'd like to open up= a specific discussion on the objective of dyn reg. >>>>>>=20 >>>>>> I see limited to no value in having clients completely anonymously re= gistering and receiving tokens without any ability to correlate applications= between applications. >>>>>=20 >>>>> I think that herein lies a very big disconnect in assumptions. I see a= huge benefit in anonymously registered clients getting tokens because there= is an end-user in the loop during the authorization phase (long after regis= tration has happened). The arity of registrations to authorizations approach= es 1:1 in these cases, and I'm just fine with that. >>>> Then what you describe is NOT anonymous but rather a profile not co= vered by the spec as there is no discussion of user authenticated registrati= on. Implicitly or explicitly. >>>=20 >>> [JR] I think you misunderstand what I said, let me try to be more explic= it: the user is not authenticating the registration. The user is not involve= d in the registration. The user might not even know that a registration happ= ened. The registration is (normally) completely anonymous and open, the clie= nt just shows up and says "Hi, I'm a client!".=20 >>>=20 >>> The "authorization" that I mentioned happens later and is a normal OAuth= authorization, which has a user involved like usual. The authorization step= in OAuth depends on *some* kind of registration happening beforehand, dynam= ic or otherwise. This is all perfectly within the model of OAuth.=20 >>>=20 >>>>>=20 >>>>> =46rom the RFC6749 perspective, a "client" is not a particular piece o= f code, it is a particular copy of a piece of code with a particular client_= id from the vantage point of a particular authorization server. >>>> actually, i disagree. This spec fundamentally breaks the old defin= ition and behavior from 6749. In the old way every instance of software shar= ed a client_id. In this draft, u throw that away without preserving the info= rmation. This is BAD! >>> [JR] No, we're not throwing that away at all. The concept is the same, b= ut when you add new functionality, the mechanics change a bit. A "client_id"= was always pairwise between a client and an AS. If a client had to talk to t= wo AS's before, it would have two client_ids. That's still the case. If ther= e were multiple copies of a confidential client, you need to get a client_id= and client_secret to each copy. That's still the case. What's different is t= hat we've made it *easier* for a particular piece of code to get different c= lient_ids when it's talking to the same or a different auth server, at runti= me. When you have to manually register every client, you're going to just do= it once. If you can do it dynamically, you have more options.=20 >>>=20 >>> Note that you can *still* have a public client with a known client_id if= you want to. You don't even need to use dynamic registration for that. Heck= , you don't need to use dynamic registration for any kind of client if you d= on't want to, since most services will probably still offer manual registrat= ion through some portal kind of page. >>>=20 >>>>=20 >>>>=20 >>>>> A "client" is, conceptually, a pairwise association between two runnin= g codebases. When you have a particular piece of code talking only to one au= th server and being manually configured at said auth server with its client_= id, this is fairly clear and straightforward and the arity is simple. Things= get a bit muddy when you introduce dynamic registration, which is why I thi= nk that we need to have introductory text about this. Specifically: >>>>>=20 >>>>> - a particular piece of code can be run on multiple devices and talk t= o the same auth server, each copy of that code getting its own client_id.=20= >>>>> - a particular copy of a particular piece of code can now be expected= to talk to multiple auth servers, each auth server giving the piece of code= its own client_id.=20 >>>>>=20 >>>>> Both of these are cases of what defines an "instance" in most people's= heads, even though it's the same software, even sometimes the same running c= opy of the same software. But as far as RFC6749's definition of "client" is c= oncerned, these are all completely separate "client"s with no way to tie the= m together out of the box. And that's fine. >>>>>=20 >>>>>>=20 >>>>>> Associating client_id's with known client applications to allow admin= s to know who is running what version of clients seems to be the most fundam= ental part of the reason for dynamic reg. How can you revoke access to parti= cular client app types? As Justin already talked about in his Blue = Button+ scenario, there are often life and death situations wher= e particular sets of clients need to be revoked.=20 >>>>> While it's very useful, I wouldn't (and haven't) classified it quite l= ike that. Nor would I say that the BB+ profile is a complete= solution -- our Registry component does not actually push revocation notifi= cations down to Providers (yet), so it's more like invalidating a root certi= ficate and waiting for caches to time out for things to casc= ade. We've been talking about adding some form of callback to providers, but= we don't want to boil that particular ocean right now. However, the BB+ pro= file makes use of a well-specified discovery and Registry set up, as well as= data conveyed in structured, signed tokens (JWTs) at different points in th= e process. >>>>>=20 >>>>>>=20 >>>>>> Or put another way. I believe this will be a critical operational req= uirement going forwards. If the spec is published as is, it will be quickly i= nvalidated by one that does at least partially address the problem. >>>>> That's not true at all. BB+ addresses this scenario and still uses the= Dynamic Registration spec as-is. I would encourage folks to read what we're= doing, a work-in-progress found here: >>>> but you are breaking other things and overloading client cred etc t= o pass in signed data. I don't want a hack for a solution. I want interop. >>> [JR] I'm curious, what exactly are we breaking? If anything in BB+ break= s compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to f= ix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we= are even explicitly calling for open registration as mandatory to implement= for authorization servers within BB+, even though we have additional mechan= isms as well for what we're calling "trusted registrations". For those trust= ed registrations, we're not using the client *credentials* to pass in signed= data, we're using the initial *registration authentication* mechanism (whic= h is to say, an OAuth token) for its intended purpose: authorizing the holde= r of this token access to the registration endpoint. In BB+, we're profiling= exactly what that means. To wit, we define the content of the token (which i= s fully compatible with DynReg which doesn't care what's in the token) and h= ow the AS can verify it (which DynReg doesn't care how it happens) and we've= added some additional rules and policies that allow us to tie together inst= ances of the client across the distributed network.=20 >>>=20 >>> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge a= mount of very specific machinery (signed tokens with known formats and field= s, a Registry with manual pre-registration, a three-tiered discovery service= with information about clients and service providers rooted at the Registry= , trust frameworks and network enforcement policies that all players have to= agree to before playing, etc.), and it's not really doing just registration= anymore. In BB+, we needed the Registry and Discovery services to do other f= unctions as well apart from just registration, and so it makes sense to re-u= se them.=20 >>>=20 >>> If there were a simple solution that didn't leave security holes the siz= e of a small army, I'd be glad to bring it to the table. But I am convinced t= hat a good solution for managing client instances across a network requires a= lot more thought and consideration, and I believe that having a fully speci= fied discovery service will help this case, like it has helped in BB+. But I= think that it's a complex enough problem that it needs its own set of consi= derations. With DynReg, we need to leave things open for that work in the fu= ture, and I believe we have, but we shouldn't kill the simple, genera --Apple-Mail-A0BDF7B5-B4DF-4348-8E58-241F52341535 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new model proposes quasi-confidential characteristics but in some respects is missing key information from the public model.  Namely that a group of clients are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far. But certainly what we define here can open that door. 

Phil

On 2013-05-21, at 8:43, Justin Richer <jricher@mitre.org> wrote:

Phil,

I am considering the knowledge model. You could say that we're "throwing away" a shared client_id in one case, because now public clients don't have to be public clients anymore in many cases. Native apps that used to have to be public clients (because they would otherwise all be shipped with the same client_secret) are no longer forced to do that. Each copy can register itself independently. Most of the time this means that the app will just present its pre-configured set of metadata to the AS, and get back a client_id and client_secret all for its own. I don't see how it's possible for an AS to know a client is a member of a "class" or running a particular copy (or version, or instance, etc.) of a piece of code without specifying a large amount of other mechanisms.

However, you can still do public clients with a shared client id if you do some kind of manual registration. You don't need dynamic registration for this case because it's easy to just bake the client_id into all of your clients. The "class" of public clients is "tied together" in the manual registration case because the developer went to the AS's webpage and got a client_id to bake into their clients. That doesn't go away.

But if you want all copies of your public clients to get the same client_id at all AS's they talk to (or otherwise be linked together), then you're going to need do specify a *whole* lot more than just registration. And it's not at all needed for what I (and others) see as the "normal" case for registration. This is why I want to leave it out of the registration spec and let it get the attention it deserves on its own.

 -- Justin

On 05/21/2013 10:26 AM, Phil Hunt wrote:
Justin,

Please re-consider what I was saying. You are not cnsidering what was known without reg and what is known after dyn reg. 

In public clients, you are changing the meaning of client_id. 

You are throwing away what was shared among all public clients (a client id) running the same software. 

When you issue a separate id you need to retain what was known before which was critically important-a set of clients share the same software and thus behave in certain ways. 

Gaining a unique cred while losing information about what the software is makes dyn reg's value dramatically reduced. 

Phil

On 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org> wrote:


On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth.


From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.



A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id.

Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.


Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, genera
--Apple-Mail-A0BDF7B5-B4DF-4348-8E58-241F52341535-- From Michael.Jones@microsoft.com Tue May 21 10:53:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9836821F9914 for ; Tue, 21 May 2013 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08lFiA1QFDuY for ; Tue, 21 May 2013 10:52:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id AD33121F990C for ; Tue, 21 May 2013 10:52:30 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.203) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.698.0; Tue, 21 May 2013 17:52:25 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Tue, 21 May 2013 17:52:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 21 May 2013 17:52:06 +0000 From: Mike Jones To: "Justin P. Richer" , Phil Hunt Thread-Topic: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOVjRC7EIUuQ3MakO6lkHhIS5M25kP62cx Date: Tue, 21 May 2013 17:52:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367748E19TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(51914003)(50854003)(377424003)(15454003)(24454002)(51444003)(54094003)(199002)(377454002)(66654002)(479174002)(85644002)(74502001)(15974865001)(54316002)(16297215003)(47736001)(55846006)(47976001)(63696002)(4396001)(49866001)(74366001)(31966008)(76482001)(50986001)(74662001)(56776001)(56816002)(46102001)(20776003)(81542001)(71186001)(47446002)(81342001)(44976003)(54356001)(15395725003)(69226001)(74876001)(16601075002)(53806001)(33656001)(16406001)(6806003)(74706001)(65816001)(15202345002)(59766001)(77982001)(79102001)(51856001)(16236675002)(80022001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08534B37A7 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 17:53:05 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367748E19TK5EX14MBXC283r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable No information is being thrown away. Developers can use dynamic registrati= on to obtain a client_id and then have all the client instances use that cl= ient_id if they choose - just like they can do when doing out-of-band regis= tration with a site=92s developer portal. The only difference is that they= don=92t have to do out-of-band registration anymore! -- Mike From: Phil Hunt Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD8=FD:=FD02=FD =FDAM To: Justin Richer Cc: oauth@ietf.org WG Regarding charter. The charter is a one-liner. To say associating clients is not in the charte= r while saying every other 'new' thing that is in the spec (eg client auth = type) is in is laughable. After all the entire draft is new functionality. The item i have asked for is not new. It preserves information that was ava= ilable without reg. Namely a way to recognize multiple clients as a common = public client as in 6749 they share a client_id. The draft throws this inf= ormation away preventing security admins from making any judgements since a= ll clients are now anonymized. Where in the charter does it say you can anonymize the clients? Phil On 2013-05-21, at 6:46, Justin Richer > wrote: On 05/21/2013 02:01 AM, Phil Hunt wrote: Phil On 2013-05-20, at 8:35, Justin Richer > wrote: On 05/17/2013 05:27 PM, Phil Hunt wrote: Mike, Rather then embed comments in an extended thread, I'd like to open up a spe= cific discussion on the objective of dyn reg. I see limited to no value in having clients completely anonymously register= ing and receiving tokens without any ability to correlate applications betw= een applications. I think that herein lies a very big disconnect in assumptions. I see a huge= benefit in anonymously registered clients getting tokens because there is = an end-user in the loop during the authorization phase (long after registra= tion has happened). The arity of registrations to authorizations approaches= 1:1 in these cases, and I'm just fine with that. Then what you describe is NOT anonymous but rather a profile not covere= d by the spec as there is no discussion of user authenticated registration.= Implicitly or explicitly. [JR] I think you misunderstand what I said, let me try to be more explicit:= the user is not authenticating the registration. The user is not involved = in the registration. The user might not even know that a registration happe= ned. The registration is (normally) completely anonymous and open, the clie= nt just shows up and says "Hi, I'm a client!". The "authorization" that I mentioned happens later and is a normal OAuth au= thorization, which has a user involved like usual. The authorization step i= n OAuth depends on *some* kind of registration happening beforehand, dynami= c or otherwise. This is all perfectly within the model of OAuth. >From the RFC6749 perspective, a "client" is not a particular piece of code,= it is a particular copy of a piece of code with a particular client_id fro= m the vantage point of a particular authorization server. actually, i disagree. This spec fundamentally breaks the old definitio= n and behavior from 6749. In the old way every instance of software shared = a client_id. In this draft, u throw that away without preserving the inform= ation. This is BAD! [JR] No, we're not throwing that away at all. The concept is the same, but = when you add new functionality, the mechanics change a bit. A "client_id" w= as always pairwise between a client and an AS. If a client had to talk to t= wo AS's before, it would have two client_ids. That's still the case. If the= re were multiple copies of a confidential client, you need to get a client_= id and client_secret to each copy. That's still the case. What's different = is that we've made it *easier* for a particular piece of code to get differ= ent client_ids when it's talking to the same or a different auth server, at= runtime. When you have to manually register every client, you're going to = just do it once. If you can do it dynamically, you have more options. Note that you can *still* have a public client with a known client_id if yo= u want to. You don't even need to use dynamic registration for that. Heck, = you don't need to use dynamic registration for any kind of client if you do= n't want to, since most services will probably still offer manual registrat= ion through some portal kind of page. A "client" is, conceptually, a pairwise association between two running cod= ebases. When you have a particular piece of code talking only to one auth s= erver and being manually configured at said auth server with its client_id,= this is fairly clear and straightforward and the arity is simple. Things g= et a bit muddy when you introduce dynamic registration, which is why I thin= k that we need to have introductory text about this. Specifically: - a particular piece of code can be run on multiple devices and talk to th= e same auth server, each copy of that code getting its own client_id. - a particular copy of a particular piece of code can now be expected to t= alk to multiple auth servers, each auth server giving the piece of code its= own client_id. Both of these are cases of what defines an "instance" in most people's head= s, even though it's the same software, even sometimes the same running copy= of the same software. But as far as RFC6749's definition of "client" is co= ncerned, these are all completely separate "client"s with no way to tie the= m together out of the box. And that's fine. Associating client_id's with known client applications to allow admins to k= now who is running what version of clients seems to be the most fundamental= part of the reason for dynamic reg. How can you revoke access to particula= r client app types? As Justin already talked about in his Blue Button+ sce= nario, there are often life and death situations where particular sets of c= lients need to be revoked. While it's very useful, I wouldn't (and haven't) classified it quite like t= hat. Nor would I say that the BB+ profile is a complete solution -- our Reg= istry component does not actually push revocation notifications down to Pro= viders (yet), so it's more like invalidating a root certificate and waiting= for caches to time out for things to cascade. We've been talking about add= ing some form of callback to providers, but we don't want to boil that part= icular ocean right now. However, the BB+ profile makes use of a well-specif= ied discovery and Registry set up, as well as data conveyed in structured, = signed tokens (JWTs) at different points in the process. Or put another way. I believe this will be a critical operational requireme= nt going forwards. If the spec is published as is, it will be quickly inval= idated by one that does at least partially address the problem. That's not true at all. BB+ addresses this scenario and still uses the Dyna= mic Registration spec as-is. I would encourage folks to read what we're doi= ng, a work-in-progress found here: but you are breaking other things and overloading client cred etc to p= ass in signed data. I don't want a hack for a solution. I want interop. [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks c= ompatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fi= x there. It is our intent to be fully compatible with OAuth Dyn Reg, and we= are even explicitly calling for open registration as mandatory to implemen= t for authorization servers within BB+, even though we have additional mech= anisms as well for what we're calling "trusted registrations". For those tr= usted registrations, we're not using the client *credentials* to pass in si= gned data, we're using the initial *registration authentication* mechanism = (which is to say, an OAuth token) for its intended purpose: authorizing the= holder of this token access to the registration endpoint. In BB+, we're pr= ofiling exactly what that means. To wit, we define the content of the token= (which is fully compatible with DynReg which doesn't care what's in the to= ken) and how the AS can verify it (which DynReg doesn't care how it happens= ) and we've added some additional rules and policies that allow us to tie t= ogether instances of the client across the distributed network. So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amo= unt of very specific machinery (signed tokens with known formats and fields= , a Registry with manual pre-registration, a three-tiered discovery service= with information about clients and service providers rooted at the Registr= y, trust frameworks and network enforcement policies that all players have = to agree to before playing, etc.), and it's not really doing just registrat= ion anymore. In BB+, we needed the Registry and Discovery services to do ot= her functions as well apart from just registration, and so it makes sense t= o re-use them. If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced th= at a good solution for managing client instances across a network requires = a lot more thought and consideration, and I believe that having a fully spe= cified discovery service will help this case, like it has helped in BB+. Bu= t I think that it's a complex enough problem that it needs its own set of c= onsiderations. With DynReg, we need to leave things open for that work in t= he future, and I believe we have, but we shouldn't kill the simple, general= case for want of a special case. http://blue-button.github.io/blue-button-plus-pull/ Just because you make something better doesn't mean you throw necessarily a= way everything you've done to date. We're ahead of schedule, lets talk through the requirement. I believe that the requirement of tying instances together is explicitly ou= t of scope for the dynamic registration protocol. I intended to have text t= o that effect in the section I'm adding about the client lifecycle. where is this stated in charter? [JR] The charter for the working states what's in scope, not what's out of = scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abo= ut registration is this: And dynamic client registration will make it easier to broadly deploy OAuth clients (performing services to users). And: Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG fo= r consideration as a Proposed Standard There's nothing in there at all about tying together client instances. I ha= ve not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client = registration. It sounds very likely to me that it *is* required for your us= e case, but that doesn't make it required for everybody's use case. There are other important pieces of functionality that the WG isn't picking= up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for thos= e to be separate modules. As I mentioned in my comments to the other thread. Let's say we agree not d= o this now. Well, then the new draft that does solve it would likely be 95%= overlap. Thus I see this issue as within charter and should be solved now= rather then waiting for a V2 dyn reg in the next charter. Why wouldn't the new draft just be the extra 5%? I personally think that it= 's a lot more than 5% once you have in all the assurance and safety mechani= sms in place to avoid self-asserted values causing race conditions, and wha= t not. Two drafts to do registration is not the way to go. It implies complex= ity where there should be none. There is no technical reason for two drafts= . [JR] There is a need when there's a special case that requires a large amou= nt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today). -- Justin Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 1:08 PM, Mike Jones wrote: Thanks for the detailed feedback, Phil. Sorry for the delayed response =96= I was pretty fully engaged at the European Identity Conference (where OAut= h 2.0 won the award for best new standard :)). My feedback on the points raised is inline in green=85 (Perhaps if any of you reply to this thread, you could also choose a distin= ct color for your inline replies, so that it will be easily evident who sai= d what. As it is, just the back-and-forth between Phil and Justin is alrea= dy very difficult to follow. Thanks.) From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 16, 2013 12:54 PM To: Richer, Justin P. Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Justin, Thanks for the discussion. More comments below... BTW. I'm happy to contribute text. Just want to get to some rough agreement= first. For example, I think we need to have a away to recognize two piece= s of software as being the same (even if self-asserted). Once defined, I c= an put together some intro text, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: Phil, many thanks for the extremely thorough review! It is very useful inde= ed. My comments and responses to each point are inline. On May 15, 2013, at 4:30 PM, Phil Hunt > wrote: It seems unfortunate that I have not gotten a chance to get into this level= of detail much earlier. But then, I guess that's what LC review is for! My= apologies for not getting many of these concerns to the WG much earlier. Overall ----------- I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Faceboo= k or Flickr and moved on to standards based, open source based, and commerc= ial based deployments where there are multiple service endpoints and many c= lients to manage. The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec: 1. How is a new client application recognized for the first time when depl= oyed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does c= hange with versions? In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together = classes of clients (see below for more discussion on this very point). But = in general, a client is just going to show up as a new instance to the AS a= nd get issued a new, unique client_id, and that's that. I think we have to define more clearly what an "instance" is. For me, there= are applications and there are instances of that application. It is usefu= l to understand that a client application represents a set of code that sho= uld behave in a consistent way. It seems to me the first time a new applic= ation shows up is very different from the subsequent instances that registe= r. For example, after the first registration, subsequent instances don't ne= ed special review or approval to the same degree. But without other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other cl= ient instance. Therefore, from the perspective of an AS, the first instance= of an application (i.e., particular configuration of a set of code) to reg= ister is no different to subsequent instances of that same application. How= were you envisioning an AS knowing the difference between the first and su= bsequent instances of an application, specifically? If there's an "applicat= ion_id" like you mention above, I think it raises more questions than it re= solves: Who issues the application_id, some server or the application itsel= f? Is it validated at all? Should it be considered secret? What happens whe= n someone simply steals an application_id? Does an AS have to do anything t= o check with any other AS to see if the application_id has already been use= d elsewhere? I do agree that a discussion of "instance vs. application" would be helpful= in clearing this up, I'll make a note to add text to that effect. (We had = to do something similar for BB+) I think it is simple enough to at least add a self generated UUID for the a= pplication ID. Though I would allow for cases where the application ID is = assigned when the client developer and the APIs owner do a formal assignmen= t of application IDs. In a sense this is just a lower tech way of doing it than what you describe= d as the initial client credential in Blue Button+ where you encoded extra = claims into the initial app credential. What the UUID does is link multiple instances of a client app together as t= he same "thing" that should have similar heuristics/behaviours. This is ve= ry useful if you want to be able to revoke access to a set of clients ident= ified by application id (or a version of that app). While I=92m sympathetic to the OAuth working group eventually doing work on= differentiating between instances of an OAuth client, I=92ll note that in = RFC 6749 or RFC 6750 there is no such thing as a client instance. There ar= e only clients, which are identified by client_id values. If we want to do= work on client instances, we should recharter to add this new work as a wo= rking group deliverable. We should not try to shoehorn bits and pieces of = it into the Dynamic Registration spec, any more than we should have tried t= o shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to registe= r clients as defined in RFC 6749. It=92s not the right place to extend wha= t an OAuth client is in new ways. 2. How are client credentials managed. Are we assuming client credentials = have a limited lifetime or rotation policy? The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it = may be after multiple refactorings), then I welcome suggestions and specifi= c text as to how to make that clear. Something like this should be in the draft. Should this be up in the introductory text, somewhere else, or have its own= section? I'm starting to think credential management is a key part of the draft. It = may be worth introducing a specific section outling the registration life-c= ycle, registration access token usage, and client token usage and bootstrap= ping. I think that adding a discussion on this would be fine, as it could help de= velopers understand the workflow of registering, using, and updating regist= ered clients. How does a client authenticate the first time and subsequent times to the r= egistration service? This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either: - Not authenticate at all (this is the true public, open registration, an= d it is recommended that servers do this) - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the= spec, by design. Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is= an OAuth 2.0 Bearer token that is unique to the client instance. Something like this should be in the draft. OK, the definition of the registration access token can be expanded, but I = think that the rest of it is already in there in =A73. I'd welcome suggesti= ons on which bits of this could be made clearer. See the discussion on what the registration_access_token is in the thread = =93Client Credential Expiry and new Registration Access Token - draft-ietf-= oauth-dyn-reg-10=94. I will work with Justin to apply these clarifications= to the specification. This may go into the proposed credential management= overview section discussed above. 3. How is versioning of clients managed? Should each new version of a clie= nt require a change in client registration including possibly changing clie= nt_id and authentication credential? I don't have a strong feeling, but it = is something that implementors should consider. This is up to the AS, really, and I don't think that any global policy woul= d ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding= a discussion in the security considerations if it merits mentioning though= , so that we can help both client developers and server developers institut= e reasonably good policy. I guess the issue is that when a client upgrades it may have access to the = old credentials. What is the intent then of registration. Since you have a= n update are clients expected to update /re-register or not? I'm not sure = this is a security consideration but more part of the whole change manageme= nt function dynamic registration supports. If your upgraded version of the client still has access to its old credenti= als, why wouldn't it just use those? I don't see a reason for forcing a re-= registration. Nor do I see any way that an AS would even be able to tell th= at a client had been upgraded. An upgraded client always has the *option* o= f re-registering itself and getting a new client_id. I think the concern here is that rotation of client credential is not somet= hing discussed before. Before we put it in the spec we should consider the = reasons for doing it and what problems it solves. I think this may be just a case of letting people exchange credentials for = whatever reason they feel is appropriate. The version upgrade thing sugges= ts that when a client is upgraded it should go to the registration server t= o "re-register". Depending on the policy of the server, it may (or may not= ) receive a new client_id and/or new credential. One of the best benefits I can think of is if you discover a version of a c= lient has a problem, being able to select a group of clients by software an= d version is important. Thus if client_id doesn't trace to a particular sof= tware and version, that makes it hard to do. I think you talked about thi= s as an issue for Blue Button+ Again, RFC 6749 defines no client instances or groups of clients, therefore= I believe that it=92s inappropriate to do so here. We don=92t need to boi= l the ocean. If a new charter item is approved to do work on client instan= ces and protocol elements to use and express them, that=92s the time for th= e working group to consider that possibility =96 not as part of Dynamic Cli= ent Registration. 4. What is the registration access token? Why is is used? What is its life= -cycle? When is it issued, when is it changed? When is it deleted? See the response above above and the definition in =A71.2: Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client. If this can be clarified, I welcome text suggestions. The latter part of 1.2 didn't seem like terminology but rather architecture= or part of the introduction that describes what the spec does. The third p= oint doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration acce= ss tokens. Client Registration Endpoint: The OAuth 2.0 Endpoint through which a Client can request new registration. The means of the Client obtaining the URL for this endpoint are out of scope for this specification. o Client Configuration Endpoint: The OAuth 2.0 Endpoint through which a specific Client can manage its registration information, provided by the Authorization Server to the Client. This URL for this endpoint is communicated to the client by the Authorization Server in the Client Information Response. o Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client. This section is meant to just introduce the new terms that are then explain= ed in greater detail throughout the rest of the document. Yes, it's a bit a= rchitecture, but only in the sense that you need to define the terms that m= ake up your architecture. How would you suggest that it change? Probably this is more a matter of style. But, what happened for me is I na= turally skipped the terminology section, as I wasn't expecting protocol com= ponents to be there. "terminology" is something I think people tend to use= as a dictionary rather than as protocol component description. Maybe the = chairs can advise? If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like = tos_uri). I think token_endpoint_auth_method is one thing that should not = be negotiated per instance. When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiated or be di= fferent for the same client software? Should not all instances use the same= authentication method. I'm confused by this -- as far as the dynamic registration spec is concerne= d, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy o= f the client code connecting to any new authorization server. That pairing = creates the client_id, and therefore the instance, and therefore the regist= ration access token, and therefore the registration itself at a conceptual = level. So there is no way other than per-instance for a client to ask for a= particular token_endpoint_auth_method. Where else would the AS find out ab= out it? We still disagree on this. It is my assertion that clients should NEVER ask= for a particular token auth method. Since it is the AS that is authenticat= ing the client, then it is the AS's right to set the authentication policy.= The role of dynamic reg endpoint is to inform the client what it must do.= My assumption is that during the first time a piece of software is regist= ered (the first instance), there could be some OOB discussion by an adminis= trator to approve the particular authentication type for the AS in question= . I haven't heard a reason justifying this parameter other then "it is needed= ". Why? The role of the dynamic registration protocol is twofold: half of that is t= he server informing the client what it must do. But the other half is the c= lient informing the server what it *can* do, or what it *wants* to do. And again, there's no way to distinguish a first instance from a subsequent= instance unless you're doing something in addition. Nothing is stopping th= e same application from registering a new instance of itself for every sing= le user or every single token that it wants to get access for. That's compl= icated and wasteful and not a great idea, sure, but there's no useful way = to prevent that kind of behavior if you also want open registration of clie= nts. I think we've discussed how recognizing subsequent instances is easily done= . As I mentioned in the other thread, if a developer chooses to limit the cap= abilities of the client it must do so by looking to the developer or standa= rd behind the API. Otherwise they are taking the chance. There's no way a= developer can query all the potential deployers to ask what authn types wi= ll you use. As I said, the net effect in the absence of an API standard dic= tating what should be supported, the developer will have to implement all m= ethods. My point here is that none of this is helped by the client app saying what = it supports. A developer who takes the route of limiting implementation tak= es the chance that the server will not accept. So why negotiate within reg= istration? And there's no way other than per-instance for the server to tell the clien= t which token_endpoint_auth_method to use. All instances will probably ask = for the same token_endpoint_auth_method from all auth servers they talk to,= right? And each AS will tell each instance that registers with it to use a= particular auth method. There is no way to tie together different instance= s across (or within) auth servers without specifying a significant amount o= f other machinery. Which is not to say that it's not useful in some circumstances to tie toget= her different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the= initial access token that the clients use to call the registration endpoin= t the first time, as well as a discovery protocol against a centralized se= rver that handles pre-registration. All of this machinery is, in my opinion= , a stupendous overkill for the general case, though if some folks find use= for it outside of BB+ then it'd be a good thing to abstract out and make i= ts own spec that extends the Dyn Reg spec in a fully compatible way. Furthe= rmore, even in Blue Button+ we specify that all auth servers MUST also acce= pt open registration, without an initial access token, where the client sim= ply shows up and says "hey, here are my parameters." The auth server has no= way to know in this case any kind of out-of-band negotiation for different= things. In BB+ we are writing very specific policy guidelines about how to= present the UX and things to the end user for all of these different cases= . But again, all of this is specific to the BB+ use case, and I don't see v= alue in dragging it in to the registration spec on its own. I believe it wo= uld be far too limiting. See my previous comments on differentiating client instances being out of s= cope without rechartering to do this new work and on what the registration_= access_token is. In short, the registration_access_token is an RFC 6750 be= arer token issued to the party registering the client, enabling it to subse= quently retrieve information about the client registration and to potential= ly update the registration information for that registered client. Again, = I=92ll work with Justin to make sure that this is as clear as possible in t= he specification. Finally, there seems to be an inconsistent style approach with draft-hardjo= no-oauth-resource-reg which uses ETags. Should this draft do so as well? That's an individual submission, not a working group draft. Nobody has, unt= il now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I person= ally don't see their utility here, though, and I wouldn't want to include a= wholly new mechanism this late. Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't h= ave a point. It's worth discussing. One could argue that the point of an ETag is that it is useful for change d= etection when there are multiple writers to a particular resource. In the = design of dynamic registration endpoint, there should only be one writer --= the client. This is an important observation. There are other mechanisms that handle this -- namely, the registration acc= ess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as desc= ribed in =A74.1. If everyone agrees, I'm in agreement. But it will likely mean changes for t= he resource reg draft if adopted. ETags seem like an unnecessary addition (and potential complication) to the= specification. It=92s already working fine as-is. Specific items: --------------------- "token_endpoint_auth_method" There is some confusion as to whether this applies to server or client auth= entication. Suggest renaming parameter to "token_endpoint_client_auth_meth= od" This is the first I've heard of this particular confusion. I'm fine with ei= ther name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. The question was raised to me by some new developers. It seems obvious to u= s as experienced OAuth persons, but to new developers it seems unclear. Al= so, now that you are introducing registration authentication, the whole thi= ng gets very confusing. So it is useful disambiguate all the parameters whe= re possible. That said, I wouldn't mind shorter names (maybe not quite as = short as the JOSE stuff ;-) Fair enough, but again, I only want to do syntax changes if the rest of the= WG *really* wants to. I agree with Justin here. I=92m fine clarifying the description of this pa= rameter to resolve the potential ambiguities that you cite, Phil. I=92m no= t OK revising the syntax without a compelling reason to do so. * Currently, the API only supports a single value instead of an array. If = the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it s= hould not be used. I would rather like this to be an array, personally, and brought it up with= the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% posi= tive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. I can get behind multiple values. In this case, it changes the meaning of t= he parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can perfor= m. This allows the server to assign the appropriate method based on its own= policy. Also note that this field, like all others in =A72, represents two things: = the client telling the server "I want to use this value for this field", an= d the server telling the client "this is the value you have for this field"= . It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator i= s nice enough to tell you what their decision was instead of just decapitat= ing you. This is the heart of my objection. This fuzziness is is going to lead to in= terop issues. There is no fuzziness that I can see here. It's parallelism between what go= es in to the endpoint and what comes out of it. The semantics for the reque= st and the response are different, and differentiable by the fact that one = is a request and the other is a response. The inter-op issue I would like to point out is that the spec does not curr= ently specify if particular input values are singular or multiple. If an i= mplementer assumes singular and clients assume multiple, we have issues. The multiple/single discussion above gets to the heart of what I *do* belie= ve is a deficiency in the specification, as it=92s currently written. The = authors, myself included, have failed to make it 100% clear that discovery = of Authorization Server functionality is out of scope for this specificatio= n. I strongly believe that we need to add a clear statement to this effect= in the introduction to the specification. The purpose of the Dynamic Client Registration specification is for the cli= ent to register with the Authorization Server and to inform it of propertie= s of the client that the AS may want/need to be aware of. It *is not* the = purpose of this specification for it to be used by clients in any manner to= discover features of the Authorization Server. That should be explicitly = out of scope. Currently, clients are instructed by RFC 6749 to discover information about= Authorization Servers they interact with by consulting the =93service docu= mentation=94 (RFC 6749, Sections 3.1 and 3.2). They can also learn informa= tion about Authorization Servers in specific contexts through discovery pro= tocols such as OpenID Connect Discovery (http://openid.net/specs/openid-con= nect-discovery-1_0.html) and UMA Discovery (TBD). I suspect that at some point, someone in the OAuth working group will propo= se developing a generic OAuth discovery mechanism, which will lead to a rec= hartering to include this work in the working group=92s set of deliverables= . I would support doing this work and the necessary rechartering to do so. That being said, I strongly oppose trying to shoehorn piecemeal aspects of = discovery into the Dynamic Client Registration specification. It is distin= ct functionality and deserves first-class and separable treatment by the wo= rking group. Discovery is for potential clients to learn properties of the= AS before registration. Registration is for potential clients to inform t= he AS of its properties, creating a registered client. Discovery sends inf= ormation about the AS to the Client. Registration sends information about = the Client to the AS. That=92s a clean separation. We should strongly res= ist muddying the two functions. OAuth 2.0 is a success because it didn=92t try to boil the ocean. It speci= fied how to do one thing well in a simple, web-friendly manner. We should = do the same =96 focusing on specifying interoperable dynamic client registr= ation, while making it clear that this is distinct from discovery about Aut= horization Server properties, and making it clear that discovery is out of = scope for this work. I apologize at this point on behalf of myself and the other spec editors fo= r not being 100% clear that discovery functionality is explicitly out of sc= ope for Dynamic Client Registration. If we had done so, I=92m sure that ma= ny of the current questions and confusions would not have arisen. I think = we=92d assumed that this was obvious, but from the current discussions, it= =92s apparent that it=92s not obvious. I will personally commit to clarify= ing the specification at this point to eliminate this potential point of co= nfusion. Getting back to the specifics, the only useful purpose of a multi-valued = =93token_endpoint_client_auth_method=94 member would be to enable the clien= t to discover information about the authentication methods supported by the= AS after the registration had been performed. But that is a discovery fun= ction, and so should be part of the discovery work =96 not this specificati= on. We should resist shoehorning in bits of discovery into this specificat= ion. It *is* a worthwhile topic, but deserves full consideration by the wo= rking group in its own right. Therefore, this member must remain single-va= lued, and be clearly specified as the method by which a client informs the = AS which token endpoint authentication method it will use. Anything else w= ould be scope creep, and result in an unnecessarily complicated specificati= on and unnecessarily complicated clients. * There is no authn method for "client_secret_saml" or "private_key_saml". Nobody has really asked that these two be included or specified. The extens= ion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use= ? I think this is coming from the fact that there is a JWT bearer draft and a= SAML bearer draft. The truth is you are defining an authentication that i= sn't even defined. There are no profiles referenced or defined for "client_secret_jwt" or "pri= vate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover th= ese types of flows. They only cover bearer flows. "client_secret_jwt" and = "private_key_jwt" seem to have some meaning within OpenID Connect, but I no= te that OIDC does not fully define these either. The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically. Actually my interpretation is the JWT draft assumes the JWT Bearer is a bea= rer token. The assumption is that if a client has the assertion it has the= right to present it. IOW. The JWT Bearer Draft is most definitively not a= JWT HoK Draft. :-) Regardless, you are introducing a new profile which is undefined. I think I see the point that you're making now, let me try to re-state it: While the basics of "how to present a JWT as a client credential" is define= d here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.se= ction.2.2 , it's not completely specified in that it doesn't fully restrict= the signature secret source, the audience claim, and other things that the= AS would need to check and validate. Right? The dynamic registration draft= can define those cases in greater detail if needed (though I think it does= so sufficiently as-is, I welcome more clarity). I'd be OK with adding the SAML bit, going into greater detail on the JWT bi= ts, or dropping the JWT bits, if the WG wants to do any of those actions. M= y objection is that the JWT stuff is already in use and functioning and it'= d be a shame to leave it out. I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made= is they assumed everyone had the same definition of bearer token. To me a= bearer token opaque to the client. It therefore cannot do any signature wo= rk with regards to the token itself. Now, that's not to say a proof didn't= occur between the client and the token issuer, but when the client wields = the token, it is handling an opaque string. The concept of client_secret_jwt suggests an HoK profile. Therefore of cou= rse the bearer drafts are a little underspecified when it comes to HoK prof= iles. So for example, you need a draft like the MAC draft for this. I'm having trouble overall here. It seems the authn types suggest ONLY stro= ng authentication for clients, yet during the registration process the curr= ent draft isn't able to correlate multiple instances of the same software (= even in a self-asserted way). If you haven't authenticated the software at= all, why have strong client auth? There is no authentication method defined for "client_bearer_saml" or "clie= nt_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration spec should accept these. I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to. 6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wi= eld it as an authentication assertion. The client is NOT creating or modif= ying the assertion. The client is simply passing one it previously obtained= . What you are describing is not bearer. It is holder of key. Very very diffe= rent. A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined. That's possible, but they are in active use already. That may be true. But then you need to write another draft so the rest of u= s can implement it in an interoperable way. Me I prefer not to guess what = you are doing. This much I agree with. Justin, John, and I discussed this issue and agree with your suggestion, Ph= il. Since they are not completely specified, we will remove the client_sec= ret_jwt and private_key_jwt methods from the specification and add a regist= ry, enabling specification that do fully specify these and other token endp= oint authentication methods, including potential methods using SAML asserti= ons, to register them in the registry, rather than trying to bake them into= the Dynamic Client Registration specification. About "tos_uri" and "policy_uri" The distinction between tos_uri and policy_uri is unclear. Can we clarify = or combine them? Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for the= m to be split. Several developers were confused by this. In particular they couldn't figur= e out which was used for what. Just passing along the feedback. OK, the distinction that I see is that the TOS is contractual, the Policy i= s a statement. Re-reading the definitions in there right now, that can be m= ade much clearer. (It even looks like some OIDC text leaked into the defini= tion of policy_uri and that hadn't been caught yet.) I support clarifying the language on these definitions, and will work with = Justin to do so. Also, aren't these really URIs or are they meant to be URLs? There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at u= s, which is a plus. Arg. Nice. Then the text should say the value passed must resolve to a val= id web page, document, whatever. That's fair, and it's something that the AS can even check if it wants to. Agreed on this clarification. About "jwks_uri" A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-key-09 is needed. Yes, you're correct, I'll add that. Should be URL instead of URI? See above. :) Agreed on adding this reference. Section 2.1 In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. It's there in the copy of -10 I'm reading off of ietf.org= right now =85 ? ' Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer Ah, that makes more sense. If the WG wants to add in SAML support to parall= el the JWT support, I'd be OK with that. =93As such, a server supporting these fields SHOULD take steps to ensure th= at a client cannot register itself into an inconsistent state.=94 We may want to define more detailed HTTP error response. E.g. 400 status co= de + defined error code (=93invalid_client_metadata=94)? I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special. I *think* that this goes away with the deletion of client_secret_jwt and pr= ivate_key_jwt in favor of the registry=85 I=92ll do a consistency check an= d verify that when the spec is updated accordingly. Section 2.2 May want to add: When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in =93clie= nt_name=94, instead of =93client_name#en=94) the OAuth server may use inter= pret the language used based on server configuration or heuristics. That seems inconsistent with what we already have: If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or scrip= t of the string value, and the string value MUST be used as-is wherever it = is presented in a user interface. Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. I will discuss with our developers. I'm not sure the as-is works. Is it the intent that when the client has localized "client_name" for examp= le, it should pass all language variations in a JSON array? Or, should part of the registration be to indicate which interface language= the client wishes to use? Then it only passes a single value for that reg= istration? No, the client should pass parameters as multiple separate values. Connect = has this in its example: "client_name": "My Example", "client_name#ja-Jpan-JP": "???????", Should we add that to at least one of the examples in DynReg? (The language= tags are a late addition, so the examples don't reflect it.) An example would definitely help. If the client passes only a single unadorned field, the AS can't make any a= ssumption about what language it is. Think of this as the internationalized= value of the field while the language tags are the localized versions of t= he field. This is why we recommend that the bare-value always be sent by th= e client, so that in the lack of anything more specific, the AS can at leas= t do *something* with it. Passing in a "default" language field (like default_locale or the like) is = only going to lead to pain for implementors of both clients and servers, an= d it's going to hurt the interoperability of the human-readable fields. I think what I meant is since you are allowing each client to register diff= erent things, AND the client likely already knows the user's preferred lang= uage, why wouldn't the client just pass text values in one language and ano= ther parameter indicating preferred language in the case of any service gen= erated text. Is the reason you are passing multiple localizations is so that you can use= the preferred language of the resource owner rather then the client user? = I wonder if that is correct. If the language preferences are in fact diffe= rent, what would the user of the client app expect? ----> any multi-lingual people have any opinions here? Without specific proposed text changes to review, it=92s hard to know what = to think about this comment. Unless a specific proposed text change is sen= t to the list with clear rationale for why it=92s better than what=92s ther= e now and reviewed by the working group, I don=92t believe we should change= the specification in response to this comment. Section 3 Existing text: =93In order to support open registration and facilitate wider interoperabil= ity, the Client Registration Endpoint SHOULD allow initial registration req= uests with no authentication. These requests MAY be rate-limited or otherw= ise limited to prevent a denial-of-service attack on the Client Registratio= n Endpoint.=94 I would suggest to change the first =93SHOULD=94 to =93MAY=94. In most cl= oud services, the first client is registered by a human user. Then, other c= lients can be further used to automate other client registration. So, the = first request would typically come with an authenticated user identity. I think the weight of "SHOULD" is appropriate here, because I believe that = turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule. I think you are reading it wrong -- a double-negative issue. The end of the= sentence is "no authentication". You are implying that NO Authentication = us what should normally be done. I think you intend anonymous authenticatio= n to be the exception rather than the rule don't you? No, I think that anonymous authentication should be the rule. Open registra= tion should be default. I disagree. Again, the spec seems contradictory. It suggests strong clien= t auth methods and at the same time anonymous registration. Yes you gain u= niqueness, but that's about it. On the flip side, the earlier paragraph: =93The Client Registration Endpoint MAY accept an initial authorization cre= dential in the form of an OAuth 2.0 [RFC6749] access token in order to limi= t registration to only previously authorized parties. The method by which t= his access token is obtained by the registrant is generally out-of-band and= is out of scope of this specification.=94 I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= . That access token would carry a human user authenticated identity somehow. = In some cases, it can be a pure authenticated user assertion token. Again, disagree, for the same reasoning as above. Same reasoning. I agree with Justin here. The default should be that open registrations ar= e enabled. The exception case is that specific permissions are required to= perform dynamic client registration. About section 4.3: If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the Registration Access Token used to make this request SHOULD be immediately revoked. If the Client does not exist on this server, shouldn't it return a "404 Not= Found"? If revoking the registration access token, is it bound to a single client r= egistration? This is not clear. What is the lifecycle around registration= access token? Only hint is in the Client Information Response in section 5= .1. The language about the 401 here (and in other nearby sections) is specifica= lly so that you treat a missing client and a bad registration access token = the same way. You see, returning a 404 here actually indicates things were = in an inconsistent state. Namely, that the registration access token was st= ill valid but the client that the registration access token was attached to= doesn't exist anymore. The registration access token in meant to be tied t= o a client's instance (or registration), so it's actually more sensible to = act as though the registration access token isn't valid anymore. In at leas= t some implementations (specifically ours at MITRE that's built on SECOAUTH= in Java), you'd never be able to reach the 404 state due to consistency ch= ecking with the inbound token. Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at = the issuance of a new client_id with that instance. That token might be rev= oked and a new one issued on Read and Update requests to the Client Configu= ration Endpoint (and the client needs to be prepared for that -- same as th= e client_secret), and it will be revoked when the client is deleted either = with a Delete call to the Client Configuration Endpoint or something happen= ing out-of-band to kill the client. Should we add more explanatory text to the definition in the terminology se= ction? Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd like. I think we should look at it. For security reasons, it=92s generally not good to distinguish between =93n= ot found=94 and =93unauthorized=94 errors in responses, as that can provide= the attacker an oracle to probe whether a particular entity exists I don= =92t think a change is called for here. About section 5.1: Is registration_access_token unique? Or is it shared by multiple instances= ? If shared, then registration_access_token can't be revoked on delete of= client. The registration_access_token is unique to a registered client, in the RFC = 6749 sense of =93client=94. Again, if we want to do work on =93client inst= ances=94, we need to recharter and take this distinct work item up explicit= ly. Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, Suggest to rename =93issued_at=94 to =93id_issued_at=94 While I do like the suggestion of changing these to client_secret_expires_a= t and client_id_issued_at, and I think these are more clear and readable, I don't want to change the syntax during last call unless there is a clear = need and a clear consensus for doing so. That's why we are having last call. To confirm consensus on the draft. Same reasoning as earlier. You now have multiple tokens (registration acces= s and client) in play. The spec needs to be clear which one it is talking a= bout. I'm fine with the suggested change but I would like more feedback from othe= r people before moving forward with it. There's a lot of value in "just pic= k a name and ship it" as well though, and I don't want to devolve into bike= shedding. (I'm not accusing you of bike shedding quite yet, btw, just afra= id of getting into a long debate on names.) Again, this was a problem raised by people new to the specification. They f= ound it confusing. I tend to agree. We're not talking about what colour to = paint the shed. We're talking about whether the bike shed is a house. :-) I'm not too fussed about whether you call it "cl_sec_expiry" or "client_sec= ret_expires_at". If the definitions of =93expires_at=94 or =93issued_at=94 are unclear, we s= hould clarify them. If you believe that this is the case Phil, can you sup= ply proposed alternative definition text that is clearer? That being said,= I believe that at this point we should stick with the existing protocol el= ement names unless overwhelming working group sentiment emerges to change t= hem. They are already working fine as-is in production deployments. Section 7 When a client_secret expires is it the intent that clients do an update or = refresh to get a new client secret? Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this. Either is a reasonable behavior on the behalf of clients, depending upon co= ntext. I support adding text to clarify this. Again, thanks for the very thorough read through. Have you implemented any = of the spec yet, either as-is or with any of your suggested changes? Yes. Much of the feedback is coming from our development community. Ah, very cool. Developer experience is the most valuable feedback, in my op= inion. If you can't actually build the blasted thing, what good is it? :) Glad to hear that you=92re working with developers building the spec. Plea= se thank them for the feedback. -- Justin Best wishes, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394367748E19TK5EX14MBXC283r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
No information is being thrown away.  Developers can use dynamic = registration to obtain a client_id and then have all the client instances u= se that client_id if they choose - just like they can do when doing ou= t-of-band registration with a site=92s developer portal.  The only difference is that they don=92t have to do out-of-b= and registration anymore!
 
-- Mike
 
 
From: Phil Hunt
Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD8=FD:=FD02= =FD =FDAM
To: Justin Richer
Cc: oauth@ietf.org WG
 
Regarding charter. 

The charter is a one-liner. To say associating clients is not in the c= harter while saying every other 'new' thing that is in the spec (eg client = auth type) is in is laughable. After all the entire draft is new functional= ity. 

The item i have asked for is not new. It preserves information that wa= s available without reg. Namely a way to recognize multiple clients as a co= mmon public client as in 6749 they share a client_id.  The draft throw= s this information away preventing security admins from making any judgements since all clients are now anonymized.

Where in the charter does it say you can anonymize the clients? <= /div>

Phil

On 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org= > wrote:


On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org= > wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up = a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously reg= istering and receiving tokens without any ability to correlate applications= between applications.

I think that herein lies a very big disconnect in assumptions. I see a huge= benefit in anonymously registered clients getting tokens because there is = an end-user in the loop during the authorization phase (long after registra= tion has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm jus= t fine with that.
<Ph>Then what you describe is NOT anonymous but rather a profile not = covered by the spec as there is no discussion of user authenticated registr= ation. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more explicit:= the user is not authenticating the registration. The user is not involved = in the registration. The user might not even know that a registration happe= ned. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi,= I'm a client!".

The "authorization" that I mentioned happens later and is a norma= l OAuth authorization, which has a user involved like usual. The authorizat= ion step in OAuth depends on *some* kind of registration happening beforeha= nd, dynamic or otherwise. This is all perfectly within the model of OAuth.


>From the RFC6749 perspective, a "client" is not a particular piec= e of code, it is a particular copy of a piece of code with a particular cli= ent_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the ol= d definition and behavior from 6749. In the old way every instance of softw= are shared a client_id. In this draft, u throw that away without preserving= the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but = when you add new functionality, the mechanics change a bit. A "client_= id" was always pairwise between a client and an AS. If a client had to= talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a conf= idential client, you need to get a client_id and client_secret to each copy= . That's still the case. What's different is that we've made it *easier* fo= r a particular piece of code to get different client_ids when it's talking to the same or a different auth= server, at runtime. When you have to manually register every client, you'r= e going to just do it once. If you can do it dynamically, you have more opt= ions.

Note that you can *still* have a public client with a known client_id if yo= u want to. You don't even need to use dynamic registration for that. Heck, = you don't need to use dynamic registration for any kind of client if you do= n't want to, since most services will probably still offer manual registration through some portal kind of = page.



A "client" is, conceptually, a pairwise association between = two running codebases. When you have a particular piece of code talking onl= y to one auth server and being manually configured at said auth server with= its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic= registration, which is why I think that we need to have introductory text = about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk = to the same auth server, each copy of that code getting its own client_id.
 - a particular copy of a particular piece of code can now be expected= to talk to multiple auth servers, each auth server giving the piece of cod= e its own client_id.

Both of these are cases of what defines an "instance" in most peo= ple's heads, even though it's the same software, even sometimes the same ru= nning copy of the same software. But as far as RFC6749's definition of &quo= t;client" is concerned, these are all completely separate "client"s with no way to tie them together out of the b= ox. And that's fine.


Associating client_id's with known client applications to allow admins= to know who is running what version of clients seems to be the most fundam= ental part of the reason for dynamic reg. How can you revoke access to part= icular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often lif= e and death situations where particular sets of clients need to be revoked.=  
While it's very useful, I wouldn't (and haven't) classified it quite like t= hat. Nor would I say that the BB+ profile is a complete solution -- our= Registry component does not actually push revocation notifications down to= Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for thi= ngs to cascade. We've been talking about adding some form of callback to pr= oviders, but we don't want to boil that particular ocean right now. However= , the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in = structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requ= irement going forwards. If the spec is published as is, it will be quickly = invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the = Dynamic Registration spec as-is. I would encourage folks to read what we're= doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred et= c to pass in signed data. I don't want a hack for a solution. I want intero= p.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ brea= ks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we ne= ed to fix there. It is our intent to be fully compatible with OAuth Dyn Reg= , and we are even explicitly calling for open registration as mandatory to implement for authorization servers with= in BB+, even though we have additional mechanisms as well for what we'r= e calling "trusted registrations". For those trusted registration= s, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication*= mechanism (which is to say, an OAuth token) for its intended purpose: auth= orizing the holder of this token access to the registration endpoint. In BB= +, we're profiling exactly what that means. To wit, we define the content of the token (which is fully com= patible with DynReg which doesn't care what's in the token) and how the AS = can verify it (which DynReg doesn't care how it happens) and we've added so= me additional rules and policies that allow us to tie together instances of the client across the distribut= ed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amo= unt of very specific machinery (signed tokens with known formats and fields= , a Registry with manual pre-registration, a three-tiered discovery service= with information about clients and service providers rooted at the Registry, trust frameworks and network= enforcement policies that all players have to agree to before playing, etc= .), and it's not really doing just registration anymore. In BB+, we nee= ded the Registry and Discovery services to do other functions as well apart from just registration, and so it make= s sense to re-use them.

If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced th= at a good solution for managing client instances across a network requires = a lot more thought and consideration, and I believe that having a fully specified discovery service will help th= is case, like it has helped in BB+. But I think that it's a complex eno= ugh problem that it needs its own set of considerations. With DynReg, we ne= ed to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, ge= neral case for want of a special case.


  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily a= way everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly ou= t of scope for the dynamic registration protocol. I intended to have text t= o that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of = scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abo= ut registration is this:

And dynamic clie= nt registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And:

Sep 2013 Submit = 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration = as a Proposed Standard
There's nothing in there at all about tying together client instances. I ha= ve not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client = registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it re= quired for everybody's use case.

There are other important pieces of functionality that the WG isn't picking= up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for thos= e to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree = not do this now. Well, then the new draft that does solve it would likely b= e 95% overlap.  Thus I see this issue as within charter and should be = solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it= 's a lot more than 5% once you have in all the assurance and safety mechani= sms in place to avoid self-asserted values causing race conditions, and wha= t not.

<ph> Two drafts to do registration is not the way to go. It implies c= omplexity where there should be none. There is no technical reason for two = drafts.
[JR] There is a need when there's a special case that requires a large amou= nt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today).


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry fo= r the delayed response =96 I was pretty fully engaged at the European Ident= ity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green=85
 
(Perhaps if any of you reply to this thread, you could= also choose a distinct <= /span>color for your inline replies, so that it will be easily evident who said what. = ; As it is, just the back-and-forth between Phil and Justin is already very= difficult to follow.  Thanks.)
 
From:<= span class=3D"Apple-converted-space"> oauth-bounces@ietf.or= g [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Phil Hunt<= br> Sent: Thursday, Ma= y 16, 2013 12:54 PM
To: Richer, Justin= P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUT= H-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement= first.  For example, I think we need to have a away to recognize two = pieces of software as being the same (even if self-asserted).  Once de= fined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful= indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote= :
 
It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is fo= r! My apologies for not getting many of these concerns to the WG much earli= er.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to stan= dards based, open source based, and commercial based deployments where ther= e are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when= deployed against a particular SP endpoint?  Should clients actually a= ssert an application_id UUID that never changes and possibly a version id t= hat does change with versions?
 
In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a partic= ular OpenID Connect provider, then you can define semantics for tying toget= her classes of clients (see below for more discussion on this very point). But in general, a client is just goin= g to show up as a new instance to the AS and get issued a new, unique clien= t_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For= me, there are applications and there are instances of that application. &n= bsp;It is useful to understand that a client application represents a set o= f code that should behave in a consistent way.  It seems to me the first time a new application shows up is very dif= ferent from the subsequent instances that register. For example, after the = first registration, subsequent instances don't need special review or appro= val to the same degree.
 
But without other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other cl= ient instance. Therefore, from the perspective of an AS, the first instance= of an application (i.e., particular configuration of a set of code) to register is no different to subsequent = instances of that same application. How were you envisioning an AS knowing = the difference between the first and subsequent instances of an application= , specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves:= Who issues the application_id, some server or the application itself? Is i= t validated at all? Should it be considered secret? What happens when someo= ne simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the ap= plication_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would = be helpful in clearing this up, I'll make a note to add text to that effect= . (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the a= pplication ID.  Though I would allow for cases where the application I= D is assigned when the client developer and the APIs owner do a formal assi= gnment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you describe= d as the initial client credential in Blue Button+ where you encoded ex= tra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as t= he same "thing" that should have similar heuristics/behaviours. &= nbsp;This is very useful if you want to be able to revoke access to a set o= f clients identified by application id (or a version of that app).
 
While I=92m sympathetic to the OAuth working group eventuall= y doing work on differentiating between instances of an OAuth client, I=92l= l note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which= are identified by client_id values.  If we want to do work on client = instances, we should recharter to add this new work as a working group deli= verable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we shou= ld have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg= is there to register clients as defined in RFC 6749.  It=92s not the = right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credent= ials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by th= e expires_at member of the response. If a client's secret expires, it calls= the read operation on the Client Configuration Endpoint (=A74.2) to get it= s new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings= ), then I welcome suggestions and specific text as to how to make that clea= r. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own= section?
 
I'm starting to think credential management is a key part of the draft= . It may be worth introducing a specific section outling the registration l= ife-cycle, registration access token usage, and client token usage and boot= strapping.
 
I think that adding a discussion on this would be fine,= as it could help developers understand the workflow of registering, using,= and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the r= egistration service?
 
This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either:
  - Not authenticate at all (this is the true public, open registratio= n, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer tok= en). How the client gets that bearer token and what the bearer token means = to the AS beyond "this client is authorized to register" is out o= f scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that= is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I = think that the rest of it is already in there in =A73. I'd welcome suggesti= ons on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is = in the thread =93Client Credential Expiry and new Registration Access Token= - draft-ietf-oauth-dyn-reg-10=94.  I will work with Justin to apply these clarifications to the specification.&= nbsp; This may go into the proposed credential management overview section = discussed above.
 
3.  How is versioning of clients managed? Should each new version of a= client require a change in client registration including possibly changing= client_id and authentication credential? I don't have a strong feeling, bu= t it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy= would ever fly here. Especially if you consider that the entire notion of = "version" is more fluid these days than it ever has been. I would= n't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both cl= ient developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the = old credentials. What is the intent then of registration.  Since you h= ave an update are clients expected to update /re-register or not?  I'm= not sure this is a security consideration but more part of the whole change management function dynamic registration= supports.
 
If your upgraded version of the client still has access to its old credenti= als, why wouldn't it just use those? I don't see a reason for forcing a re-= registration. Nor do I see any way that an AS would even be able to tell th= at a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getti= ng a new client_id. 
I think the concern here is that rotation of client credential is not somet= hing discussed before. Before we put it in the spec we should consider the = reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for = whatever reason they feel is appropriate.  The version upgrade thing s= uggests that when a client is upgraded it should go to the registration ser= ver to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or n= ew credential.  
 
One of the best benefits I can think of is if you discover a version of a c= lient has a problem, being able to select a group of clients by software an= d version is important. Thus if client_id doesn't trace to a particular sof= tware and version, that makes it hard to do.  I  think you talked about this as an issue for Blue= Button+
 
Again, RFC 6749 defines no client instances or groups of cli= ents, therefore I believe that it=92s inappropriate to do so here.  We= don=92t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol eleme= nts to use and express them, that=92s the time for the working group to con= sider that possibility =96 not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its= life-cycle?  When is it issued, when is it changed? When is it delete= d?
 
See the response above above and the definition in =A71.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture= or part of the introduction that describes what the spec does. The third p= oint doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoi=
nt: The OAuth 2.0 Endpoint through which
      a Client can request new registration=
.  The means of the Client
      obtaining the URL for this endpoint a=
re out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 En=
dpoint through
      which a specific Client can manage it=
s registration information,
      provided by the Authorization Server =
to the Client.  This URL for
      this endpoint is communicated to the =
client by the Authorization
      Server in the Client Information Resp=
onse.
 
   o  Registration Access Token: An OAuth 2.0 Bearer =
Token issued by the
      Authorization Server through the Clie=
nt Registration Endpoint
      which is used by the Client to authen=
ticate itself during read,
      update, and delete operations.  =
This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explain= ed in greater detail throughout the rest of the document. Yes, it's a bit a= rchitecture, but only in the sense that you need to define the terms that m= ake up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is= I naturally skipped the terminology section, as I wasn't expecting protoco= l components to be there.  "terminology" is something I thin= k people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like tos_uri).  I think token_endpo= int_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiate= d or be different for the same client software? Should not all instances us= e the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change p= er instance. And instance, you should keep in mind, is defined as any one c= opy of the client code connecting to any new authorization server. That pairing creates the client_id, and t= herefore the instance, and therefore the registration access token, and the= refore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the A= S find out about it?
 
We still disagree on this. It is my assertion that clients should NEVE= R ask for a particular token auth method. Since it is the AS that is authen= ticating the client, then it is the AS's right to set the authentication po= licy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that durin= g the first time a piece of software is registered (the first instance), th= ere could be some OOB discussion by an administrator to approve the particu= lar authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it= is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is t= he server informing the client what it must do. But the other half is the c= lient informing the server what it *can* do, or what it *wants* to do. = ;
 
And again, there's no way to distinguish a first instance from a subsequent= instance unless you're doing something in addition. Nothing is stopping th= e same application from registering a new instance of itself for every sing= le user or every single token that it wants to get access for. That's complicated and wasteful and not a grea= t idea, sure, but  there's no useful way to prevent that kind of behav= ior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done= .
 
As I mentioned in the other thread, if a developer chooses to limit the cap= abilities of the client it must do so by looking to the developer or standa= rd behind the API.  Otherwise they are taking the chance.  There'= s no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect = in the absence of an API standard dictating what should be supported, the d= eveloper will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what = it supports. A developer who takes the route of limiting implementation tak= es the chance that the server will not accept.  So why negotiate withi= n registration?
 
And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will probably= ask for the same token_endpoint_auth_method from all auth servers they tal= k to, right? And each AS will tell each instance that registers with it to use a particular auth method. Ther= e is no way to tie together different instances across (or within) auth ser= vers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some cir= cumstances to tie together different instances of the same code across (or = within) auth servers. This is why, with Blue Button+, we specified a sp= ecific token format for the initial access token that the clients use to call the registration endpoint the first tim= e,  as well as a discovery protocol against a centralized server that = handles pre-registration. All of this machinery is, in my opinion, a stupen= dous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing= to abstract out and make its own spec that extends the Dyn Reg spec in a f= ully compatible way. Furthermore, even in Blue Button+ we specify that = all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says= "hey, here are my parameters." The auth server has no way to kno= w in this case any kind of out-of-band negotiation for different things. In= BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these di= fferent cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its own= . I believe it would be far too limiting.

 
See my previous comments on differentiating client inst= ances being out of scope without rechartering to do this new work and on wh= at the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued= to the party registering the client, enabling it to subsequently retrieve = information about the client registration and to potentially update the reg= istration information for that registered client.  Again, I=92ll work with Justin to make sure that this is as = clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource = registration draft comes from) uses ETags, hence their inclusion there. I p= ersonally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this l= ate.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't h= ave a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change d= etection when there are multiple writers to a particular resource.  In= the design of dynamic registration endpoint, there should only be one writ= er -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration acc= ess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as desc= ribed in =A74.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for t= he resource reg draft if adopted.<= /span>
 
ETags seem like an unnecessary addition (and potential compl= ication) to the specification.  It=92s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client auth= entication.  Suggest renaming parameter to "token_endpoint_client= _auth_method"
 
This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes withou= t very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious= to us as experienced OAuth persons, but to new developers it seems unclear= .  Also, now that you are introducing registration authentication, the= whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That sa= id, I wouldn't mind shorter names (maybe not quite as short as the JOSE stu= ff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the= WG *really* wants to.
 
I agree with Justin here.  I=92m fine clarifying the de= scription of this parameter to resolve the potential ambiguities that you c= ite, Phil.  I=92m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array. &nbs= p;If the purpose is to allow the client to know what auth methods it suppor= ts, this should be an array indicated what methods the client supports - or= it should not be used.
 
I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it w= as decided that a single value was simpler and sufficient for the purpose. = The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this= very issue in the WG here but didn't receive any traction on it, so single= it remains.
 
I can get behind multiple values. In this case, it changes the meaning of t= he parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can perfor= m. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =A72, represents two thi= ngs: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last= word anyway. But at least this dictator is nice enough to tell you what th= eir decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to in= terop issues.
 
There is no fuzziness that I can see here. It's parallelism between what go= es in to the endpoint and what comes out of it. The semantics for the reque= st and the response are different, and differentiable by the fact that one = is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not curr= ently specify if particular input values are singular or multiple.  If= an implementer assumes singular and clients assume multiple, we have issue= s.
 
The multiple/single discussion above gets to the heart of wh= at I *do* believe is a deficiency in the specification, as it=92s cu= rrently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorizatio= n Server functionality is out of scope for this specification.  I stro= ngly believe that we need to add a clear statement to this effect in the in= troduction to the specification.
 
The purpose of the Dynamic Client Registration specification= is for the client to register with the Authorization Server and to inform = it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose = of this specification for it to be used by clients in any manner to discove= r features of the Authorization Server.  That should be explicitly out= of scope.
 
Currently, clients are instructed by RFC 6749 to discover in= formation about Authorization Servers they interact with by consulting the = =93service documentation=94 (RFC 6749, Sections 3.1 and 3.2).&n= bsp; They can also learn information about Authorization Servers in specifi= c contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/spec= s/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working g= roup will propose developing a generic OAuth discovery mechanism, which wil= l lead to a rechartering to include this work in the working group=92s set of deliverables.  I would supp= ort doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecem= eal aspects of discovery into the Dynamic Client Registration specification= .  It is distinct functionality and deserves first-class and separable treatment by the working group.  D= iscovery is for potential clients to learn properties of the AS before regi= stration.  Registration is for potential clients to inform the AS of i= ts properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration= sends information about the Client to the AS.  That=92s a clean separ= ation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn=92t try to boil the o= cean.  It specified how to do one thing well in a simple, web-friendly= manner.  We should do the same =96 focusing on specifying interoperable dynamic client registration, while making it c= lear that this is distinct from discovery about Authorization Server proper= ties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other = spec editors for not being 100% clear that discovery functionality is expli= citly out of scope for Dynamic Client Registration.  If we had done so, I=92m sure that many of the current= questions and confusions would not have arisen.  I think we=92d assum= ed that this was obvious, but from the current discussions, it=92s apparent= that it=92s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential = point of confusion.
 
Getting back to the specifics, the only useful purpose of a = multi-valued =93token_endpoint_client_auth_method=94 member would be to enable the client to discover information about the aut= hentication methods supported by the AS after the registration had been per= formed.  But that is a discovery function, and so should be part of th= e discovery work =96 not this specification.  We should resist shoehorning in bits of discovery into this specification.=   It *is* a worthwhile topic, but deserves full consideration b= y the working group in its own right.  Therefore, this member must rem= ain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authen= tication method it will use.  Anything else would be scope creep, and = result in an unnecessarily complicated specification and unnecessarily comp= licated clients.
 
* There is no authn method for "client_secret_saml" or "priv= ate_key_saml".
 
Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an absolute URI) would allow someone else to defi= ne these. Is the definition in the SAML Assertion draft sufficient for thei= r use?
 
I think this is coming from the fact that there is a JWT bearer draft and a= SAML bearer draft.  The truth is you are defining an authentication t= hat isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt&= quot; or "private_key_jwt". Neither of the JWT or SAML Bearer dra= fts referenced cover these types of flows. They only cover bearer flows. &n= bsp;"client_secret_jwt" and "private_key_jwt" seem to h= ave some meaning within OpenID Connect, but I note that OIDC does not fully de= fine these either.
 
The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token.  The assumption is that if a client has the assertion = it has the right to present it.  IOW. The JWT Bearer Draft is most def= initively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:<= /div>
 
While the basics of "how to present a JWT as a client credential"= is defined here: http://tools.ietf.org/id/draft-= ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signat= ure secret source, the audience claim, and other things that the AS would n= eed to check and validate. Right? The dynamic registration draft can define= those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clari= ty).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bi= ts, or dropping the JWT bits, if the WG wants to do any of those actions. M= y objection is that the JWT stuff is already in use and functioning and it'= d be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made= is they assumed everyone had the same definition of bearer token.  To= me a bearer token opaque to the client. It therefore cannot do any signatu= re work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and t= he token issuer, but when the client wields the token, it is handling an op= aque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore o= f course the bearer drafts are a little underspecified when it comes to HoK= profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY stro= ng authentication for clients, yet during the registration process the curr= ent draft isn't able to correlate multiple instances of the same software (= even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth= ?
 
There is no authentication method defined for "client_bearer_saml"= ; or "client_bearer_jwt" or "client_bearer_ref".  = Since the bearer specs say this is acceptable,  the dynamic registrati= on spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) a= nd wield it as an authentication assertion.  The client is NOT creatin= g or modifying the assertion. The client is simply passing one it previousl= y obtained.
 
What you are describing is not bearer. It is holder of key. Very very = different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined.=
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest= of us can implement it in an interoperable way.  Me I prefer not to g= uess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your= suggestion, Phil.  Since they are not completely specified, we will r= emove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification = that do fully specify these and other token endpoint authentication methods= , including potential methods using SAML assertions, to register them in th= e registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we cla= rify or combine them?
 
Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't = figure out which was used for what.  Just passing along the feedback.<= /div>
 
OK, the distinction that I see is that the TOS is contractual, the Policy i= s a statement. Re-reading the definitions in there right now, that can be m= ade much clearer. (It even looks like some OIDC text leaked into the defini= tion of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and = will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolv= e to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.<= /div>
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-= ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant= -type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of = ietf.org right now =85 ?
'
Sorry I meant: urn:ietf:pa= rams:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parall= el the JWT support, I'd be OK with that.
 
=93As such, a server supporting these fields SHOULD take steps to= ensure that a client cannot register itself into an inconsistent state.=94=

We may want to define more detailed HTTP error response. E.g. 400 stat= us code + defined error code (=93invalid_client_metadata=94)?
 
I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of cl= ient_secret_jwt and private_key_jwt in favor of the registry=85  I=92l= l do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When =93#=94 language tag is missing, (e.g. =93#en=94 is mi= ssing in =93client_name=94, instead of =93client_name#en=94) the OAuth= server may use interpret the language used based on server confi= guration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make any assumptions about the language, character set, or = script of the string value, and the string value MUST be used as-is whereve= r it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy.
 
I will discuss with our developers. I'm not sure the as-is works. &nbs= p;
 
Is it the intent that when the client has localized "client_name&= quot; for example, it should pass all language variations in a JSON array?<= /div>
 
Or, should part of the registration be to indicate which interface lan= guage the client wishes to use?  Then it only passes a single value fo= r that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect = has this in its example:
 
   "client_name": "My Exampl=
e",
   "client_name#ja-Jpan-JP":

     "クライアン|=
88;名",





Should we add that to at least one of the examples in DynReg? (The language=
 tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any a= ssumption about what language it is. Think of this as the internationalized= value of the field while the language tags are the localized versions of t= he field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of a= nything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the= like) is only going to lead to pain for implementors of both clients and s= ervers, and it's going to hurt the interoperability of the human-readable f= ields. 
 
I think what I meant is since you are allowing each client to register diff= erent things, AND the client likely already knows the user's preferred lang= uage, why wouldn't the client just pass text values in one language and ano= ther parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use= the preferred language of the resource owner rather then the client user? = I wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it=92s har= d to know what to think about this comment.  Unless a specific propose= d text change is sent to the list with clear rationale for why it=92s better than what=92s there now and reviewed by th= e working group, I don=92t believe we should change the specification in re= sponse to this comment.
 
Section 3
 
Existing text:

=93In order to support open registration and facilitate wider in= teroperability, the Client Registration Endpoint SHOULD allow ini= tial registration requests with no authentication.  The= se requests MAY be rate-limited or otherwise limited to prevent a deni= al-of-service attack on the Client Registration Endpoint.=94

I would suggest to change the first =93SHOULD=94 to =93MAY=94.   = In most cloud services, the first client is registered by a human user= . Then, other clients can be further used to automate other clien= t registration.  So, the first request would typically come = with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I bel= ieve that turning off open registration at the AS (which is what this is ta= lking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end o= f the sentence is "no authentication".  You are implying tha= t NO Authentication us what should normally be done. I think you intend ano= nymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registra= tion should be default. 
 
I disagree.  Again,  the spec seems contradictory. It sugges= ts strong client auth methods and at the same time anonymous registration. =  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

=93The Client Registration Endpoint MAY accept an initial a= uthorization credential in the form of an OAuth 2.0 [RFC6749] access t= oken 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 thi= s specification.=94

I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= .

That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion toke= n.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that o= pen registrations are enabled.  The exception case is that specific pe= rmissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond=

   with HTTP 401 Unauthorized, and the Registration Access=
 Token used to
   make this request SHOULD be immediately revoked.=
 
If the Client does not exist on this server, shouldn't it return = a "404 Not Found"?

If revoking the registration access token, is it bound to a single client r= egistration?  This is not clear.  What is the lifecycle around re= gistration access token? Only hint is in the Client Information Response in= section 5.1.
 
The language about the 401 here (and in other nearby sections) is spec= ifically so that you treat a missing client and a bad registration access t= oken the same way. You see, returning a 404 here actually indicates th= ings were in an inconsistent state. Namely, that the registration access token was still valid but the client that the= registration access token was attached to doesn't exist anymore. The regis= tration access token in meant to be tied to a client's instance (or registr= ation), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at = least some implementations (specifically ours at MITRE that's built on SECO= AUTH in Java), you'd never be able to reach the 404 state due to consistenc= y checking with the inbound token.
 
Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begin= s at the issuance of a new client_id with that instance. That token might b= e revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the cli= ent needs to be prepared for that -- same as the client_secret), and it wil= l be revoked when the client is deleted either with a Delete call to the Cl= ient Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sin= ce I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it=92s generally not good to distingui= sh between =93not found=94 and =93unauthorized=94 errors in responses, as t= hat can provide the attacker an oracle to probe whether a particular entity exists  I don=92t think a change is calle= d for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple= instances?   If shared, then registration_access_token can't be revok= ed on delete of client.
 
The registration_access_token is unique to a registered= client, in the RFC 6749 sense of =93client=94.  Again, if we want to = do work on =93client instances=94, we need to recharter and take this distinct work item up explicitly.

Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, 
Suggest to rename =93issued_at=94 to =93id_issued_at=94
 
While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readab= le,


I don't want to change the syntax during last call unless there is a c= lear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. = ;
 
Same reasoning as earlier. You now have multiple tokens (registration acces= s and client) in play. The spec needs to be clear which one it is talking a= bout.
 
I'm fine with the suggested change but I would like more feedback from othe= r people before moving forward with it. There's a lot of value in "jus= t pick a name and ship it" as well though, and I don't want to devolve= into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate= on names.)
 
Again, this was a problem raised by people new to the specification. They f= ound it confusing. I tend to agree. We're not talking about what colour to = paint the shed. We're talking about whether the bike shed is a house. =  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or &= quot;client_secret_expires_at". 

If the definitions of =93expires_at=94 or =93issued_at=94 ar= e unclear, we should clarify them.  If you believe that this is the ca= se Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point = we should stick with the existing protocol element names unless overwhelmin= g working group sentiment emerges to change them.  They are already wo= rking fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, de= pending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my op= inion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you=92re working with developers building = the spec.  Please thank them for the feedback.
 
 -- Justin
 
          =             &nb= sp;            =             &nb= sp;            Best = wishes,
          =             &nb= sp;            =             &nb= sp;            -- Mi= ke




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


--_000_4E1F6AAD24975D4BA5B168042967394367748E19TK5EX14MBXC283r_-- From phil.hunt@oracle.com Tue May 21 11:20:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000EE21F967D for ; Tue, 21 May 2013 11:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRh3RPBPA8fI for ; Tue, 21 May 2013 11:20:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E139F21F9601 for ; Tue, 21 May 2013 11:20:10 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4LIK96A002188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 18:20:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LIK7WF016845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 18:20:08 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4LIK6d9027097; Tue, 21 May 2013 18:20:07 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 May 2013 11:20:03 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4ECF6BC9-E662-46FA-A1E6-5219AE6B8CEB" From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 21 May 2013 11:20:10 -0700 Message-Id: References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org>, <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 18:20:22 -0000 --Apple-Mail=_4ECF6BC9-E662-46FA-A1E6-5219AE6B8CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, There is an operational loss of information in the dynamic registration = spec. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-21, at 10:52 AM, Mike Jones wrote: > No information is being thrown away. Developers can use dynamic = registration to obtain a client_id and then have all the client = instances use that client_id if they choose - just like they can do when = doing out-of-band registration with a site=E2=80=99s developer portal. = The only difference is that they don=E2=80=99t have to do out-of-band = registration anymore! > =20 > -- Mike > =20 > =20 > From: Phil Hunt > Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E21=E2=80= =8E, =E2=80=8E2013 =E2=80=8E8=E2=80=8E:=E2=80=8E02=E2=80=8E =E2=80=8EAM > To: Justin Richer > Cc: oauth@ietf.org WG > =20 > Regarding charter.=20 >=20 > The charter is a one-liner. To say associating clients is not in the = charter while saying every other 'new' thing that is in the spec (eg = client auth type) is in is laughable. After all the entire draft is new = functionality.=20 >=20 > The item i have asked for is not new. It preserves information that = was available without reg. Namely a way to recognize multiple clients as = a common public client as in 6749 they share a client_id. The draft = throws this information away preventing security admins from making any = judgements since all clients are now anonymized. >=20 > Where in the charter does it say you can anonymize the clients?=20 >=20 > Phil >=20 > On 2013-05-21, at 6:46, Justin Richer wrote: >=20 >=20 > On 05/21/2013 02:01 AM, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2013-05-20, at 8:35, Justin Richer wrote: >=20 >=20 > On 05/17/2013 05:27 PM, Phil Hunt wrote: > Mike, >=20 > Rather then embed comments in an extended thread, I'd like to open up = a specific discussion on the objective of dyn reg. >=20 > I see limited to no value in having clients completely anonymously = registering and receiving tokens without any ability to correlate = applications between applications.=20 >=20 > I think that herein lies a very big disconnect in assumptions. I see a = huge benefit in anonymously registered clients getting tokens because = there is an end-user in the loop during the authorization phase (long = after registration has happened). The arity of registrations to = authorizations approaches 1:1 in these cases, and I'm just fine with = that.=20 > Then what you describe is NOT anonymous but rather a profile not = covered by the spec as there is no discussion of user authenticated = registration. Implicitly or explicitly.=20 >=20 > [JR] I think you misunderstand what I said, let me try to be more = explicit: the user is not authenticating the registration. The user is = not involved in the registration. The user might not even know that a = registration happened. The registration is (normally) completely = anonymous and open, the client just shows up and says "Hi, I'm a = client!".=20 >=20 > The "authorization" that I mentioned happens later and is a normal = OAuth authorization, which has a user involved like usual. The = authorization step in OAuth depends on *some* kind of registration = happening beforehand, dynamic or otherwise. This is all perfectly within = the model of OAuth.=20 >=20 >=20 > =46rom the RFC6749 perspective, a "client" is not a particular piece = of code, it is a particular copy of a piece of code with a particular = client_id from the vantage point of a particular authorization server. > actually, i disagree. This spec fundamentally breaks the old = definition and behavior from 6749. In the old way every instance of = software shared a client_id. In this draft, u throw that away without = preserving the information. This is BAD! > [JR] No, we're not throwing that away at all. The concept is the same, = but when you add new functionality, the mechanics change a bit. A = "client_id" was always pairwise between a client and an AS. If a client = had to talk to two AS's before, it would have two client_ids. That's = still the case. If there were multiple copies of a confidential client, = you need to get a client_id and client_secret to each copy. That's still = the case. What's different is that we've made it *easier* for a = particular piece of code to get different client_ids when it's talking = to the same or a different auth server, at runtime. When you have to = manually register every client, you're going to just do it once. If you = can do it dynamically, you have more options.=20 >=20 > Note that you can *still* have a public client with a known client_id = if you want to. You don't even need to use dynamic registration for = that. Heck, you don't need to use dynamic registration for any kind of = client if you don't want to, since most services will probably still = offer manual registration through some portal kind of page. >=20 >=20 >=20 > A "client" is, conceptually, a pairwise association between two = running codebases. When you have a particular piece of code talking only = to one auth server and being manually configured at said auth server = with its client_id, this is fairly clear and straightforward and the = arity is simple. Things get a bit muddy when you introduce dynamic = registration, which is why I think that we need to have introductory = text about this. Specifically: >=20 > - a particular piece of code can be run on multiple devices and talk = to the same auth server, each copy of that code getting its own = client_id.=20 > - a particular copy of a particular piece of code can now be expected = to talk to multiple auth servers, each auth server giving the piece of = code its own client_id.=20 >=20 > Both of these are cases of what defines an "instance" in most people's = heads, even though it's the same software, even sometimes the same = running copy of the same software. But as far as RFC6749's definition of = "client" is concerned, these are all completely separate "client"s with = no way to tie them together out of the box. And that's fine. >=20 >=20 > Associating client_id's with known client applications to allow admins = to know who is running what version of clients seems to be the most = fundamental part of the reason for dynamic reg. How can you revoke = access to particular client app types? As Justin already talked about = in his Blue Button+ scenario, there are often life and death situations = where particular sets of clients need to be revoked. =20 > While it's very useful, I wouldn't (and haven't) classified it quite = like that. Nor would I say that the BB+ profile is a complete solution = -- our Registry component does not actually push revocation = notifications down to Providers (yet), so it's more like invalidating a = root certificate and waiting for caches to time out for things to = cascade. We've been talking about adding some form of callback to = providers, but we don't want to boil that particular ocean right now. = However, the BB+ profile makes use of a well-specified discovery and = Registry set up, as well as data conveyed in structured, signed tokens = (JWTs) at different points in the process. >=20 >=20 > Or put another way. I believe this will be a critical operational = requirement going forwards. If the spec is published as is, it will be = quickly invalidated by one that does at least partially address the = problem. > That's not true at all. BB+ addresses this scenario and still uses the = Dynamic Registration spec as-is. I would encourage folks to read what = we're doing, a work-in-progress found here: > but you are breaking other things and overloading client cred etc = to pass in signed data. I don't want a hack for a solution. I want = interop.=20 > [JR] I'm curious, what exactly are we breaking? If anything in BB+ = breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we = need to fix there. It is our intent to be fully compatible with OAuth = Dyn Reg, and we are even explicitly calling for open registration as = mandatory to implement for authorization servers within BB+, even though = we have additional mechanisms as well for what we're calling "trusted = registrations". For those trusted registrations, we're not using the = client *credentials* to pass in signed data, we're using the initial = *registration authentication* mechanism (which is to say, an OAuth = token) for its intended purpose: authorizing the holder of this token = access to the registration endpoint. In BB+, we're profiling exactly = what that means. To wit, we define the content of the token (which is = fully compatible with DynReg which doesn't care what's in the token) and = how the AS can verify it (which DynReg doesn't care how it happens) and = we've added some additional rules and policies that allow us to tie = together instances of the client across the distributed network.=20 >=20 > So why doesn't DynReg adopt this mechanism? Two reasons: it adds a = huge amount of very specific machinery (signed tokens with known formats = and fields, a Registry with manual pre-registration, a three-tiered = discovery service with information about clients and service providers = rooted at the Registry, trust frameworks and network enforcement = policies that all players have to agree to before playing, etc.), and = it's not really doing just registration anymore. In BB+, we needed the = Registry and Discovery services to do other functions as well apart from = just registration, and so it makes sense to re-use them.=20 >=20 > If there were a simple solution that didn't leave security holes the = size of a small army, I'd be glad to bring it to the table. But I am = convinced that a good solution for managing client instances across a = network requires a lot more thought and consideration, and I believe = that having a fully specified discovery service will help this case, = like it has helped in BB+. But I think that it's a complex enough = problem that it needs its own set of considerations. With DynReg, we = need to leave things open for that work in the future, and I believe we = have, but we shouldn't kill the simple, general case for want of a = special case.=20 >=20 >=20 > http://blue-button.github.io/blue-button-plus-pull/ >=20 > Just because you make something better doesn't mean you throw = necessarily away everything you've done to date. >=20 >=20 > We're ahead of schedule, lets talk through the requirement. > I believe that the requirement of tying instances together is = explicitly out of scope for the dynamic registration protocol. I = intended to have text to that effect in the section I'm adding about the = client lifecycle. >=20 > where is this stated in charter? > [JR] The charter for the working states what's in scope, not what's = out of scope, correct? It has been my understanding of IETF process that = additional functionality needs to be considered separately. All the = charter says about registration is this: >=20 > And dynamic client registration will make > it easier to broadly deploy OAuth clients (performing services to > users). >=20 > And:=20 >=20 > Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for consideration as a Proposed Standard > There's nothing in there at all about tying together client instances. = I have not seen anything to convince me that management of client = instances across a deployed network of auth servers is a necessary part = of basic client registration. It sounds very likely to me that it *is* = required for your use case, but that doesn't make it required for = everybody's use case.=20 >=20 > There are other important pieces of functionality that the WG isn't = picking up right now (such as token chaining and token introspection) = that are absolutely necessary for my own use cases, but I think it makes = sense for those to be separate modules. >=20 >=20 >=20 > As I mentioned in my comments to the other thread. Let's say we agree = not do this now. Well, then the new draft that does solve it would = likely be 95% overlap. Thus I see this issue as within charter and = should be solved now rather then waiting for a V2 dyn reg in the next = charter. > Why wouldn't the new draft just be the extra 5%? I personally think = that it's a lot more than 5% once you have in all the assurance and = safety mechanisms in place to avoid self-asserted values causing race = conditions, and what not. >=20 > Two drafts to do registration is not the way to go. It implies = complexity where there should be none. There is no technical reason for = two drafts.=20 > [JR] There is a need when there's a special case that requires a large = amount of overhead to be done correctly, to allow the general case to = move forward and be used on its own (as it is being used today).=20 >=20 >=20 > -- Justin >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-17, at 1:08 PM, Mike Jones wrote: >=20 > Thanks for the detailed feedback, Phil. Sorry for the delayed = response =E2=80=93 I was pretty fully engaged at the European Identity = Conference (where OAuth 2.0 won the award for best new standard J). My = feedback on the points raised is inline in green=E2=80=A6 > =20 > (Perhaps if any of you reply to this thread, you could also choose a = distinct color for your inline replies, so that it will be easily = evident who said what. As it is, just the back-and-forth between Phil = and Justin is already very difficult to follow. Thanks.) > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, May 16, 2013 12:54 PM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 > =20 > Justin, > =20 > Thanks for the discussion. More comments below... > =20 > BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > =20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: > =20 > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > =20 > Phil, many thanks for the extremely thorough review! It is very useful = indeed.=20 > =20 > My comments and responses to each point are inline.=20 > =20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: > =20 > It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. > =20 > Overall =20 > ----------- > I think dynamic registration is a critical part of the OAuth framework = now that we are starting to consider how individual client applications = should operate when there is one or more deployments of a particular = resource API. We've moved from the simple use case of a single API = provider like Facebook or Flickr and moved on to standards based, open = source based, and commercial based deployments where there are multiple = service endpoints and many clients to manage. > =20 > The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: > =20 > 1. How is a new client application recognized for the first time when = deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? > =20 > In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 > =20 > I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. > =20 > But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? > =20 > I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) > =20 > I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. > =20 > In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. > =20 > What the UUID does is link multiple instances of a client app together = as the same "thing" that should have similar heuristics/behaviours. = This is very useful if you want to be able to revoke access to a set of = clients identified by application id (or a version of that app). > =20 > While I=E2=80=99m sympathetic to the OAuth working group eventually = doing work on differentiating between instances of an OAuth client, = I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as = a client instance. There are only clients, which are identified by = client_id values. If we want to do work on client instances, we should = recharter to add this new work as a working group deliverable. We = should not try to shoehorn bits and pieces of it into the Dynamic = Registration spec, any more than we should have tried to shoehorn it = into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients = as defined in RFC 6749. It=E2=80=99s not the right place to extend what = an OAuth client is in new ways. > =20 > 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? > =20 > The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 > Something like this should be in the draft. > =20 > Should this be up in the introductory text, somewhere else, or have = its own section? > =20 > I'm starting to think credential management is a key part of the = draft. It may be worth introducing a specific section outling the = registration life-cycle, registration access token usage, and client = token usage and bootstrapping. > =20 > I think that adding a discussion on this would be fine, as it could = help developers understand the workflow of registering, using, and = updating registered clients. > =20 > How does a client authenticate the first time and subsequent times to = the registration service? > =20 > This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: > - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. > =20 > Subsequent times that the same registered client (by which we mean the = same instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. > =20 > Something like this should be in the draft. > =20 > OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer. > =20 > See the discussion on what the registration_access_token is in the = thread =E2=80=9CClient Credential Expiry and new Registration Access = Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin = to apply these clarifications to the specification. This may go into = the proposed credential management overview section discussed above. > =20 > 3. How is versioning of clients managed? Should each new version of a = client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. > =20 > This is up to the AS, really, and I don't think that any global policy = would ever fly here. Especially if you consider that the entire notion = of "version" is more fluid these days than it ever has been. I wouldn't = mind adding a discussion in the security considerations if it merits = mentioning though, so that we can help both client developers and server = developers institute reasonably good policy. > =20 > I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. Since you = have an update are clients expected to update /re-register or not? I'm = not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. > =20 > If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= > I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. > =20 > I think this may be just a case of letting people exchange credentials = for whatever reason they feel is appropriate. The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register". Depending on the policy of the server, it may = (or may not) receive a new client_id and/or new credential. =20 > =20 > One of the best benefits I can think of is if you discover a version = of a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ > =20 > Again, RFC 6749 defines no client instances or groups of clients, = therefore I believe that it=E2=80=99s inappropriate to do so here. We = don=E2=80=99t need to boil the ocean. If a new charter item is approved = to do work on client instances and protocol elements to use and express = them, that=E2=80=99s the time for the working group to consider that = possibility =E2=80=93 not as part of Dynamic Client Registration. > =20 > 4. What is the registration access token? Why is is used? What is its = life-cycle? When is it issued, when is it changed? When is it deleted? > =20 > See the response above above and the definition in =C2=A71.2:=20 > =20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. > =20 > If this can be clarified, I welcome text suggestions. > =20 > The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. > =20 > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > =20 > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL = for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > =20 > o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > =20 > This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? > =20 > Probably this is more a matter of style. But, what happened for me is = I naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? > =20 > If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. > =20 > When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. > =20 > I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? > =20 > We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. > =20 > I haven't heard a reason justifying this parameter other then "it is = needed". Why? > =20 > The role of the dynamic registration protocol is twofold: half of that = is the server informing the client what it must do. But the other half = is the client informing the server what it *can* do, or what it *wants* = to do.=20 > =20 > And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 > =20 > I think we've discussed how recognizing subsequent instances is easily = done. > =20 > As I mentioned in the other thread, if a developer chooses to limit = the capabilities of the client it must do so by looking to the developer = or standard behind the API. Otherwise they are taking the chance. = There's no way a developer can query all the potential deployers to ask = what authn types will you use. As I said, the net effect in the absence = of an API standard dictating what should be supported, the developer = will have to implement all methods. > =20 > My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? > =20 > And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. > =20 > Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. >=20 > =20 > See my previous comments on differentiating client instances being out = of scope without rechartering to do this new work and on what the = registration_access_token is. In short, the registration_access_token = is an RFC 6750 bearer token issued to the party registering the client, = enabling it to subsequently retrieve information about the client = registration and to potentially update the registration information for = that registered client. Again, I=E2=80=99ll work with Justin to make = sure that this is as clear as possible in the specification. > =20 > Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? > =20 > That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. > =20 > Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 > =20 > One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. > =20 > There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 > =20 > If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. > =20 > ETags seem like an unnecessary addition (and potential complication) = to the specification. It=E2=80=99s already working fine as-is. > =20 > Specific items: > --------------------- > "token_endpoint_auth_method" > =20 > There is some confusion as to whether this applies to server or client = authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" > =20 > This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. > =20 > The question was raised to me by some new developers. It seems obvious = to us as experienced OAuth persons, but to new developers it seems = unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) > =20 > Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to. > =20 > I agree with Justin here. I=E2=80=99m fine clarifying the description = of this parameter to resolve the potential ambiguities that you cite, = Phil. I=E2=80=99m not OK revising the syntax without a compelling = reason to do so. > =20 > * Currently, the API only supports a single value instead of an array. = If the purpose is to allow the client to know what auth methods it = supports, this should be an array indicated what methods the client = supports - or it should not be used. > =20 > I would rather like this to be an array, personally, and brought it up = with the OpenID Connect working group about six months ago. But there it = was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. > =20 > I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method = based on its own policy. >=20 > Also note that this field, like all others in =C2=A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. > =20 > This is the heart of my objection. This fuzziness is is going to lead = to interop issues. > =20 > There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 > =20 > The inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. = If an implementer assumes singular and clients assume multiple, we have = issues. > =20 > The multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written. The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification. I strongly believe that we need to add a = clear statement to this effect in the introduction to the specification. > =20 > The purpose of the Dynamic Client Registration specification is for = the client to register with the Authorization Server and to inform it of = properties of the client that the AS may want/need to be aware of. It = *is not* the purpose of this specification for it to be used by clients = in any manner to discover features of the Authorization Server. That = should be explicitly out of scope. > =20 > Currently, clients are instructed by RFC 6749 to discover information = about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and = 3.2). They can also learn information about Authorization Servers in = specific contexts through discovery protocols such as OpenID Connect = Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) = and UMA Discovery (TBD). > =20 > I suspect that at some point, someone in the OAuth working group will = propose developing a generic OAuth discovery mechanism, which will lead = to a rechartering to include this work in the working group=E2=80=99s = set of deliverables. I would support doing this work and the necessary = rechartering to do so. > =20 > That being said, I strongly oppose trying to shoehorn piecemeal = aspects of discovery into the Dynamic Client Registration specification. = It is distinct functionality and deserves first-class and separable = treatment by the working group. Discovery is for potential clients to = learn properties of the AS before registration. Registration is for = potential clients to inform the AS of its properties, creating a = registered client. Discovery sends information about the AS to the = Client. Registration sends information about the Client to the AS. = That=E2=80=99s a clean separation. We should strongly resist muddying = the two functions. > =20 > OAuth 2.0 is a success because it didn=E2=80=99t try to boil the = ocean. It specified how to do one thing well in a simple, web-friendly = manner. We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this work. > =20 > I apologize at this point on behalf of myself and the other spec = editors for not being 100% clear that discovery functionality is = explicitly out of scope for Dynamic Client Registration. If we had done = so, I=E2=80=99m sure that many of the current questions and confusions = would not have arisen. I think we=E2=80=99d assumed that this was = obvious, but from the current discussions, it=E2=80=99s apparent that = it=E2=80=99s not obvious. I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion. > =20 > Getting back to the specifics, the only useful purpose of a = multi-valued =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member = would be to enable the client to discover information about the = authentication methods supported by the AS after the registration had = been performed. But that is a discovery function, and so should be part = of the discovery work =E2=80=93 not this specification. We should = resist shoehorning in bits of discovery into this specification. It = *is* a worthwhile topic, but deserves full consideration by the working = group in its own right. Therefore, this member must remain = single-valued, and be clearly specified as the method by which a client = informs the AS which token endpoint authentication method it will use. = Anything else would be scope creep, and result in an unnecessarily = complicated specification and unnecessarily complicated clients. > =20 > * There is no authn method for "client_secret_saml" or = "private_key_saml". > =20 > Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? > =20 > I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. > =20 > There are no profiles referenced or defined for "client_secret_jwt" or = "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced = cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. > =20 > The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. > =20 > Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) > =20 > Regardless, you are introducing a new profile which is undefined. > =20 > I think I see the point that you're making now, let me try to re-state = it: > =20 > While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). > =20 > I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. > =20 > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors = made is they assumed everyone had the same definition of bearer token. = To me a bearer token opaque to the client. It therefore cannot do any = signature work with regards to the token itself. Now, that's not to say = a proof didn't occur between the client and the token issuer, but when = the client wields the token, it is handling an opaque string. > =20 > The concept of client_secret_jwt suggests an HoK profile. Therefore = of course the bearer drafts are a little underspecified when it comes to = HoK profiles. > =20 > So for example, you need a draft like the MAC draft for this.=20 > =20 > I'm having trouble overall here. It seems the authn types suggest ONLY = strong authentication for clients, yet during the registration process = the current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way). If you haven't authenticated = the software at all, why have strong client auth? > =20 > There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. > =20 > I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. > =20 > 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. > =20 > What you are describing is not bearer. It is holder of key. Very very = different.=20 >=20 > A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. > =20 > That's possible, but they are in active use already.=20 > =20 > That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. > =20 > This much I agree with. > =20 > Justin, John, and I discussed this issue and agree with your = suggestion, Phil. Since they are not completely specified, we will = remove the client_secret_jwt and private_key_jwt methods from the = specification and add a registry, enabling specification that do fully = specify these and other token endpoint authentication methods, including = potential methods using SAML assertions, to register them in the = registry, rather than trying to bake them into the Dynamic Client = Registration specification. > =20 > About "tos_uri" and "policy_uri" > =20 > The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? > =20 > Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. > =20 > Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. > =20 > OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) > =20 > I support clarifying the language on these definitions, and will work = with Justin to do so. > =20 > Also, aren't these really URIs or are they meant to be URLs? > =20 > There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. > =20 > Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. > =20 > That's fair, and it's something that the AS can even check if it wants = to. > =20 > Agreed on this clarification. > =20 > About "jwks_uri" > =20 > A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 > =20 > Yes, you're correct, I'll add that. > =20 > Should be URL instead of URI? > =20 > See above. :) > =20 > Agreed on adding this reference. > =20 > Section 2.1 > =20 > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > is missing. > =20 > It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? > ' > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > =20 > Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. > =20 > =E2=80=9CAs such, a server supporting these fields SHOULD take steps = to ensure that a client cannot register itself into an inconsistent = state.=E2=80=9D >=20 > We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? > =20 > I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. > =20 > I *think* that this goes away with the deletion of client_secret_jwt = and private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a = consistency check and verify that when the spec is updated accordingly. > =20 > Section 2.2 > =20 > May want to add: > =20 > When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. > =20 > That seems inconsistent with what we already have: > =20 > If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. > =20 > Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. > =20 > I will discuss with our developers. I'm not sure the as-is works. =20 > =20 > Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? > =20 > Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? > =20 > =20 > No, the client should pass parameters as multiple separate values. = Connect has this in its example: > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) > =20 > An example would definitely help. > If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. > =20 > Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 > =20 > I think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text. > =20 > Is the reason you are passing multiple localizations is so that you = can use the preferred language of the resource owner rather then the = client user? I wonder if that is correct. If the language preferences = are in fact different, what would the user of the client app expect? > =20 > ----> any multi-lingual people have any opinions here? > =20 > Without specific proposed text changes to review, it=E2=80=99s hard to = know what to think about this comment. Unless a specific proposed text = change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and reviewed by the working group, = I don=E2=80=99t believe we should change the specification in response = to this comment. > =20 > Section 3 > =20 > Existing text: >=20 > =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >=20 > I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 > =20 > I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 > =20 > I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? > =20 > No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 > =20 > I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >=20 > On the flip side, the earlier paragraph: >=20 > =E2=80=9CThe 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.=E2=80=9D >=20 > I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D = to =E2=80=9CSHOULD=E2=80=9D. >=20 > That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. > =20 > Again, disagree, for the same reasoning as above. > =20 > Same reasoning.=20 >=20 > I agree with Justin here. The default should be that open = registrations are enabled. The exception case is that specific = permissions are required to perform dynamic client registration. >=20 > About section 4.3: > =20 > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used = to > make this request SHOULD be immediately revoked. > =20 > If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >=20 > If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. > =20 > The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. > =20 > Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 > =20 > Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. > =20 > I think we should look at it. >=20 > For security reasons, it=E2=80=99s generally not good to distinguish = between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D = errors in responses, as that can provide the attacker an oracle to probe = whether a particular entity exists I don=E2=80=99t think a change is = called for here. >=20 > About section 5.1: > Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. > =20 > The registration_access_token is unique to a registered client, in the = RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly. >=20 > Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >=20 > Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D > =20 > While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >=20 >=20 > I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. > =20 > That's why we are having last call. To confirm consensus on the draft.=20= > =20 > Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. > =20 > I'm fine with the suggested change but I would like more feedback from = other people before moving forward with it. There's a lot of value in = "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) > =20 > Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 > =20 > I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >=20 > If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at= =E2=80=9D are unclear, we should clarify them. If you believe that this = is the case Phil, can you supply proposed alternative definition text = that is clearer? That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them. They are = already working fine as-is in production deployments. > =20 > Section 7 > =20 > When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? > =20 > Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. > =20 > Either is a reasonable behavior on the behalf of clients, depending = upon context. I support adding text to clarify this. > =20 > Again, thanks for the very thorough read through. Have you implemented = any of the spec yet, either as-is or with any of your suggested changes? > =20 > Yes. Much of the feedback is coming from our development community.=20 > =20 > Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) > =20 > Glad to hear that you=E2=80=99re working with developers building the = spec. Please thank them for the feedback. > =20 > -- Justin > =20 > Best = wishes, > -- Mike >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4ECF6BC9-E662-46FA-A1E6-5219AE6B8CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Phil

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





On 2013-05-21, at 10:52 AM, Mike Jones wrote:

No information is being thrown = away.  Developers can use dynamic registration to obtain a = client_id and then have all the client instances use that client_id if = they choose - just like they can do when doing out-of-band = registration with a site=E2=80=99s developer portal.  The only = difference is that they don=E2=80=99t have to do out-of-band = registration anymore!
 
-- = Mike
 
 
From: Phil = Hunt
Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E= =E2=80=8E21=E2=80=8E, =E2=80=8E2013 =E2=80=8E8=E2=80=8E:=E2=80=8E02=E2=80= =8E =E2=80=8EAM
To: Justin Richer
Cc: oauth@ietf.org = WG
 
Regarding = charter. 

The charter is a one-liner. To = say associating clients is not in the charter while saying every other = 'new' thing that is in the spec (eg client auth type) is in is = laughable. After all the entire draft is new = functionality. 

The item i have asked for = is not new. It preserves information that was available without reg. = Namely a way to recognize multiple clients as a common public client as = in 6749 they share a client_id.  The draft throws this information = away preventing security admins from making any judgements since all = clients are now anonymized.

Where in the = charter does it say you can anonymize the = clients? 

Phil

On = 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org> = wrote:


On 05/21/2013 02:01 AM, = Phil Hunt wrote:


Phil

On 2013-05-20, at = 8:35, Justin Richer <jricher@mitre.org> = wrote:


On 05/17/2013 05:27 PM, = Phil Hunt wrote:
Mike,

Rather then embed = comments in an extended thread, I'd like to open up a specific = discussion on the objective of dyn reg.

I see = limited to no value in having clients completely anonymously registering = and receiving tokens without any ability to correlate applications = between applications. 

I = think that herein lies a very big disconnect in assumptions. I see a = huge benefit in anonymously registered clients getting tokens because = there is an end-user in the loop during the authorization phase (long = after registration has happened). The arity of registrations to = authorizations approaches 1:1 in these cases, and I'm just fine with = that. 
<Ph= >Then what you describe is NOT anonymous but rather a profile not = covered by the spec as there is no discussion of user authenticated = registration. Implicitly or explicitly. 

[JR] I = think you misunderstand what I said, let me try to be more explicit: the = user is not authenticating the registration. The user is not involved in = the registration. The user might not even know that a registration = happened. The registration is (normally) completely anonymous and open, = the client just shows up and says "Hi, I'm a client!". 

The "authorization" = that I mentioned happens later and is a normal OAuth authorization, = which has a user involved like usual. The authorization step in OAuth = depends on *some* kind of registration happening beforehand, dynamic or = otherwise. This is all perfectly within the model of OAuth. 


=46rom the = RFC6749 perspective, a "client" is not a particular piece of code, it is = a particular copy of a piece of code with a particular client_id from = the vantage point of a particular authorization = server.
<ph> actually, i disagree. This = spec fundamentally breaks the old definition and behavior from 6749. In = the old way every instance of software shared a client_id. In this = draft, u throw that away without preserving the information. This is = BAD!
[JR] No, we're not throwing that away at all. The = concept is the same, but when you add new functionality, the mechanics = change a bit. A "client_id" was always pairwise between a client and an = AS. If a client had to talk to two AS's before, it would have two = client_ids. That's still the case. If there were multiple copies of a = confidential client, you need to get a client_id and client_secret to = each copy. That's still the case. What's different is that we've made it = *easier* for a particular piece of code to get different client_ids when = it's talking to the same or a different auth server, at runtime. When = you have to manually register every client, you're going to just do it = once. If you can do it dynamically, you have more options. 

Note that you can = *still* have a public client with a known client_id if you want to. You = don't even need to use dynamic registration for that. Heck, you don't = need to use dynamic registration for any kind of client if you don't = want to, since most services will probably still offer manual = registration through some portal kind of page.

A "client" is, conceptually, a pairwise = association between two running codebases. When you have a particular = piece of code talking only to one auth server and being manually = configured at said auth server with its client_id, this is fairly clear = and straightforward and the arity is simple. Things get a bit muddy when = you introduce dynamic registration, which is why I think that we need to = have introductory text about this. Specifically:

 - a = particular piece of code can be run on multiple devices and talk to the = same auth server, each copy of that code getting its own client_id. 
 - a particular = copy of a particular piece of code can now be expected to talk to = multiple auth servers, each auth server giving the piece of code its own = client_id. 

Both = of these are cases of what defines an "instance" in most people's heads, = even though it's the same software, even sometimes the same running copy = of the same software. But as far as RFC6749's definition of "client" is = concerned, these are all completely separate "client"s with no way to = tie them together out of the box. And that's fine.

 
While = it's very useful, I wouldn't (and haven't) classified it quite like = that. Nor would I say that the BB+ profile is a complete solution -- our = Registry component does not actually push revocation notifications down = to Providers (yet), so it's more like invalidating a root certificate = and waiting for caches to time out for things to cascade. We've been = talking about adding some form of callback to providers, but we don't = want to boil that particular ocean right now. However, the BB+ profile = makes use of a well-specified discovery and Registry set up, as well as = data conveyed in structured, signed tokens (JWTs) at different points in = the process.


Or put another way. I believe this will be a = critical operational requirement going forwards. If the spec is = published as is, it will be quickly invalidated by one that does at = least partially address the problem.
That's not true = at all. BB+ addresses this scenario and still uses the Dynamic = Registration spec as-is. I would encourage folks to read what we're = doing, a work-in-progress found here:
<ph> = but you are breaking other things and overloading client cred etc to = pass in signed data. I don't want a hack for a solution. I want = interop. 
[JR] I'm = curious, what exactly are we breaking? If anything in BB+ breaks = compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need = to fix there. It is our intent to be fully compatible with OAuth Dyn = Reg, and we are even explicitly calling for open registration as = mandatory to implement for authorization servers within BB+, even though = we have additional mechanisms as well for what we're calling "trusted = registrations". For those trusted registrations, we're not using the = client *credentials* to pass in signed data, we're using the initial = *registration authentication* mechanism (which is to say, an OAuth = token) for its intended purpose: authorizing the holder of this token = access to the registration endpoint. In BB+, we're profiling exactly = what that means. To wit, we define the content of the token (which is = fully compatible with DynReg which doesn't care what's in the token) and = how the AS can verify it (which DynReg doesn't care how it happens) and = we've added some additional rules and policies that allow us to tie = together instances of the client across the distributed network. 

So why doesn't = DynReg adopt this mechanism? Two reasons: it adds a huge amount of very = specific machinery (signed tokens with known formats and fields, a = Registry with manual pre-registration, a three-tiered discovery service = with information about clients and service providers rooted at the = Registry, trust frameworks and network enforcement policies that all = players have to agree to before playing, etc.), and it's not really = doing just registration anymore. In BB+, we needed the Registry and = Discovery services to do other functions as well apart from just = registration, and so it makes sense to re-use them. 

If there were a = simple solution that didn't leave security holes the size of a small = army, I'd be glad to bring it to the table. But I am convinced that a = good solution for managing client instances across a network requires a = lot more thought and consideration, and I believe that having a fully = specified discovery service will help this case, like it has helped in = BB+. But I think that it's a complex enough problem that it needs its = own set of considerations. With DynReg, we need to leave things open for = that work in the future, and I believe we have, but we shouldn't kill = the simple, general case for want of a special case. 


  http://blue-button.github.io/blue-button-plus-pull/=

Just because you make something better doesn't mean you throw = necessarily away everything you've done to date.

 

Sep 2013 Submit 'OAuth = Dynamic Client Registration Protocol' to the IESG for consideration as a = Proposed Standard
There's nothing in there at all about = tying together client instances. I have not seen anything to convince me = that management of client instances across a deployed network of auth = servers is a necessary part of basic client registration. It sounds very = likely to me that it *is* required for your use case, but that doesn't = make it required for everybody's use case. 

There are other = important pieces of functionality that the WG isn't picking up right now = (such as token chaining and token introspection) that are absolutely = necessary for my own use cases, but I think it makes sense for those to = be separate modules.



As I mentioned in my comments = to the other thread. Let's say we agree not do this now. Well, then the = new draft that does solve it would likely be 95% overlap.  Thus I = see this issue as within charter and should be solved now rather then = waiting for a V2 dyn reg in the next charter.
Why = wouldn't the new draft just be the extra 5%? I personally think that = it's a lot more than 5% once you have in all the assurance and safety = mechanisms in place to avoid self-asserted values causing race = conditions, and what = not.

<ph> Two drafts to do = registration is not the way to go. It implies complexity where there = should be none. There is no technical reason for two drafts. 
[JR] There = is a need when there's a special case that requires a large amount of = overhead to be done correctly, to allow the general case to move forward = and be used on its own (as it is being used today). 


 -- = Justin
www.independentid.com
phil.hunt@oracle.com





On 2013-05-17, = at 1:08 PM, Mike Jones wrote:

Thanks for the = detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 = I was pretty fully engaged at the European Identity Conference = (where OAuth 2.0 won the = award for best new standard ).  My = feedback on the points raised is inline in = green=E2=80=A6
(Perhaps if any of = you reply to this thread, you could also choose a distinct color  
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, May 16, 2013 = 12:54 PM
To: Richer, Justin = P.
Cc:  WG
Subject: Re: [OAUTH-WG] Last call = review of = draft-ietf-oauth-dyn-reg-10
But without other = mechanisms to tie things together, there's no way for an authorization = server to know if any client instance is tied to any other client = instance. Therefore, from the perspective of an AS, the first instance = of an application (i.e., particular configuration of a set of code) to = register is no different to subsequent instances of that same = application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere?
What the UUID does is link multiple instances of a client app = together as the same "thing" that should have similar = heuristics/behaviours.  This is very useful if you want to be able = to revoke access to a set of clients identified by application id (or a = version of that app).While I=E2=80=99m = sympathetic to the OAuth working group eventually doing work on = differentiating between instances of an OAuth client, I=E2=80=99ll note = that in RFC 6749 or RFC 6750 there is no such thing as a client = instance.  There are only clients, which are identified by = client_id values.  If we want to do work on client instances, we = should recharter to add this new work as a working group = deliverable.  We should not try to shoehorn bits and pieces of it = into the Dynamic Registration spec, any more than we should have tried = to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there = to register clients as defined in RFC 6749.  It=E2=80=99s not the = right place to extend what an OAuth client is in new = ways.
How does a = client authenticate the first time and subsequent times to the = registration service?
This is a separate question all = together, as it does not involve the client_secret or client_id at all. = Rather, the first time the client shows up to the registration service, = it may either:
  - Not authenticate = at all (this is the true public, open registration, and it is = recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a = bearer token). How the client gets that bearer token and what the bearer = token means to the AS beyond "this client is authorized to register" is = out of scope for the spec, by design.
 
Subsequent times that the = same registered client (by which we mean the same instance of a client = with a particular client_id) shows up at the registration endpoint = (actually, the Client Configuration Endpoint), it uses its Registration = Access Token that it was issued on initial registration. This is an = OAuth 2.0 Bearer token that is unique to the client = instance.
 
=
Something like this should be in the = draft.
And = there's no way other than per-instance for the server to tell the client = which token_endpoint_auth_method to use. All instances will probably ask = for the same token_endpoint_auth_method from all auth servers they talk = to, right? And each AS will tell each instance that registers with it to = use a particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a = significant amount of other = machinery.
 

Which is not to say that it's not useful in some = circumstances to tie together different instances of the same code = across (or within) auth servers. This is why, with Blue Button+, we = specified a specific token format for the initial access token that the = clients use to call the registration endpoint the first time,  as = well as a discovery protocol against a centralized server that handles = pre-registration. All of this machinery is, in my opinion, a stupendous = overkill for the general case, though if some folks find use for it = outside of BB+ then it'd be a good thing to abstract out and make its = own spec that extends the Dyn Reg spec in a fully compatible way. = Furthermore, even in Blue Button+ we specify that all auth servers MUST = also accept open registration, without an initial access token, where = the client simply shows up and says "hey, here are my parameters." The = auth server has no way to know in this case any kind of out-of-band = negotiation for different things. In BB+ we are writing very specific = policy guidelines about how to present the UX and things to the end user = for all of these different cases. But again, all of this is specific to = the BB+ use case, and I don't see value in dragging it in to the = registration spec on its own. I believe it would be far too = limiting.

 
See my = previous comments on differentiating client instances being out of scope = without rechartering to do this new work and on what the = registration_access_token is.  In short, the = registration_access_token is an RFC 6750 bearer token issued to the = party registering the client, enabling it to subsequently retrieve = information about the client registration and to potentially update the = registration information for that registered client.  Again, I=E2=80=99= ll work with Justin to make sure that this is as clear as possible in = the specification.
Specific items:
---------------------
 
There is some confusion as = to whether this applies to server or client authentication. =  Suggest renaming parameter to = "token_endpoint_client_auth_method"
 
This is the first I've heard of this particular = confusion. I'm fine with either name but at this stage I don't want to = make syntax changes without very, very compelling reasons to do = so.
 
Th= e question was raised to me by some new developers. It seems obvious to = us as experienced OAuth persons, but to new developers it seems unclear. =  Also, now that you are introducing registration authentication, = the whole thing gets very confusing. So it is useful disambiguate all = the parameters where possible.  That said, I wouldn't mind shorter = names (maybe not quite as short as the JOSE stuff = ;-)
* Currently, = the API only supports a single value instead of an array.  If the = purpose is to allow the client to know what auth methods it supports, = this should be an array indicated what methods the client supports - or = it should not be = used.
 
I would = rather like this to be an array, personally, and brought it up with the = OpenID Connect working group about six months ago. But there it was = decided that a single value was simpler and sufficient for the purpose. = The IETF draft has inherited this decision. I *believe* (though am not = 100% positive) that I brought up this very issue in the WG here but = didn't receive any traction on it, so single it = remains.
 
I can get behind multiple values. In this case, it changes the = meaning of the parameter. Instead of the client forcing the server to = use a particular method, the client is informing the server about what = methods it can perform. This allows the server to assign the appropriate = method based on its own policy.

Also note that this field, like all = others in =C2=A72, represents two things: the client telling the server = "I want to use this value for this field", and the server telling the = client "this is the value you have for this field". It's not exactly a = negotiation, more like making a polite request to an absolute dictator = who has the last word anyway. But at least this dictator is nice enough = to tell you what their decision was instead of just decapitating = you.
 
This is the heart of my objection. This fuzziness is is going to = lead to interop issues.
=
Actually my interpretation is the JWT draft assumes the JWT = Bearer is a bearer token.  The assumption is that if a client has = the assertion it has the right to present it.  IOW. The JWT Bearer = Draft is most definitively not a JWT HoK Draft. =  :-)
 
Regardless, = you are introducing a new profile which is = undefined.
While the basics of "how to = present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section= .2.2 , it's not = completely specified in that it doesn't fully restrict the signature = secret source, the audience claim, and other things that the AS would = need to check and validate. Right? The dynamic registration draft can = define those cases in greater detail if needed (though I think it does = so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the = SAML bit, going into greater detail on the JWT bits, or dropping the JWT = bits, if the WG wants to do any of those actions. My objection is that = the JWT stuff is already in use and functioning and it'd be a shame to = leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts = authors made is they assumed everyone had the same definition of bearer = token.  To me a bearer token opaque to the client. It therefore = cannot do any signature work with regards to the token itself. =  Now, that's not to say a proof didn't occur between the client and = the token issuer, but when the client wields the token, it is handling = an opaque string.
 
The concept of client_secret_jwt suggests an HoK profile. =  Therefore of course the bearer drafts are a little underspecified = when it comes to HoK profiles.
So for example, you need a draft like = the MAC draft for this. 
I'm having trouble overall here. It = seems the authn types suggest ONLY strong authentication for clients, = yet during the registration process the current draft isn't able to = correlate multiple instances of the same software (even in a = self-asserted way).  If you haven't authenticated the software at = all, why have strong client auth?
There is no authentication = method defined for "client_bearer_saml" or "client_bearer_jwt" or = "client_bearer_ref".  Since the bearer specs say this is = acceptable,  the dynamic registration spec should accept = these.
 
I don't understand this bit -- where are these defined in = RFC6750? I don't even know what client_bearer_ref would refer = to.
 
6750 = says you can use a bearer assertion (e.g. obtained from an IDP) and = wield it as an authentication assertion.  The client is NOT = creating or modifying the assertion. The client is simply passing one it = previously = obtained.
 
What you are = describing is not bearer. It is holder of key. Very very = different. 

A possible suggestion is to = remove client_secret_jwt and private_key_jwt and define those as = register extensions since these profiles are not = defined.
 
That's possible, but they are in active use = already. 
 
That = may be true. But then you need to write another draft so the rest of us = can implement it in an interoperable way.  Me I prefer not to guess = what you are doing.
 
This much I agree = with.
Justin, John, and I = discussed this issue and agree with your suggestion, Phil.  Since = they are not completely specified, we will remove the client_secret_jwt = and private_key_jwt methods from the specification and add a registry, = enabling specification that do fully specify these and other token = endpoint authentication methods, including potential methods using SAML = assertions, to register them in the registry, rather than trying to bake = them into the Dynamic Client Registration = specification.
About = "tos_uri" and "policy_uri"
The distinction between tos_uri and = policy_uri is unclear.  Can we clarify or combine = them?
 
Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be = split.
 
Seve= ral developers were confused by this. In particular they couldn't figure = out which was used for what.  Just passing along the = feedback.
 
OK, the distinction that I see is that the TOS is contractual, = the Policy is a statement. Re-reading the definitions in there right = now, that can be made much clearer. (It even looks like some OIDC text = leaked into the definition of policy_uri and that hadn't been caught = yet.)
I support = clarifying the language on these definitions, and will work with Justin = to do so.
Also, aren't these really = URIs or are they meant to be URLs?
 
There was already = discussion about this on the list: The IETF is apparently trying to = deprecate URL in favor of URI in new specs. So in practice they'll = nearly always be URLs, but since all URLs are URIs we're not technically = incorrect in following the new policy. And it makes the IESG less mad at = us, which is a = plus.
 
Arg. = Nice.  Then the text should say the value passed must resolve to a = valid web page, document, whatever.
 
That's fair, and it's = something that the AS can even check if it wants to.
Agreed on this = clarification.
'
Sorry I = meant: urn:ietf:params:oauth:grant-type:saml-bea= rer
Ah, that makes more sense. If the WG = wants to add in SAML support to parallel the JWT support, I'd be OK with = that.
=E2=80=9CAs = such, a server supporting these fields SHOULD take steps to ensure = that a client cannot register itself into an inconsistent = state.=E2=80=9D

We may want to define more detailed HTTP error = response. E.g. 400 status code + defined error code = (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?
 
I'd be fine with defining a = more explicit error state in this case. I think it would help interop = for the servers that want to enforce grant-type and response-type = restrictions, but servers that can't or don't care about restricting = grants types and whatnot don't have to do anything = special.
I *think* = that this goes away with the deletion of client_secret_jwt and = private_key_jwt in favor of the registry=E2=80=A6  I=E2=80=99ll do = a consistency check and verify that when the spec is updated = accordingly.
Section 2.2
 
May want to = add:
 
That seems inconsistent = with what we already have:
 
Which is to say, treat it = as a raw byte-value-string and don't try to get = fancy.
 
I will discuss with our developers. I'm not sure the as-is = works.  
 
Is it the = intent that when the client has localized "client_name" for example, it = should pass all language variations in a JSON = array?
 
Or, should part = of the registration be to indicate which interface language the client = wishes to use?  Then it only passes a single value for that = registration?
 
 
No, the client should pass = parameters as multiple separate values. Connect has this in its = example:
 
   =
"client_name#ja-Jpan-JP":
     "
Should we add that to at least one of the =
examples in DynReg? (The language tags are a late addition, so the =
examples don't reflect =
it.)
An example would definitely = help.
If the client passes only a = single unadorned field, the AS can't make any assumption about what = language it is. Think of this as the internationalized value of the = field while the language tags are the localized versions of the field. = This is why we recommend that the bare-value always be sent by the = client, so that in the lack of anything more specific, the AS can at = least do *something* with it.
Passing in a "default" language field = (like default_locale or the like) is only going to lead to pain for = implementors of both clients and servers, and it's going to hurt the = interoperability of the human-readable = fields. 
 
I think what I meant is = since you are allowing each client to register different things, AND the = client likely already knows the user's preferred language, why wouldn't = the client just pass text values in one language and another parameter = indicating preferred language in the case of any service generated = text.
 
Is the reason = you are passing multiple localizations is so that you can use the = preferred language of the resource owner rather then the client user? I = wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app = expect?
 
----> any multi-lingual people have any opinions = here?
Without specific = proposed text changes to review, it=E2=80=99s hard to know what to think = about this comment.  Unless a specific proposed text change is sent = to the list with clear rationale for why it=E2=80=99s better than = what=E2=80=99s there now and reviewed by the working group, I don=E2=80=99= t believe we should change the specification in response to this = comment.
 
I think the weight of = "SHOULD" is appropriate here, because I believe that turning off open = registration at the AS (which is what this is talking about) really = ought to be the exception rather than the = rule. 
 
I think you are reading it wrong -- a double-negative issue. The end of = the sentence is "no authentication".  You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you?
 
No, I think that anonymous authentication should be the rule. = Open registration should be = default. 
 
I disagree.  Again, =  the spec seems contradictory. It suggests strong client auth = methods and at the same time anonymous registration.  Yes you gain = uniqueness, but that's about it.

On the = flip side, the earlier paragraph:

=E2=80=9CThe 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.=E2=80=9D

I tend to think it would be better = to change this =E2=80=9CMAY=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.

T= hat access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.Same reasoning. 

I agree with Justin = here.  The default should be that open registrations are = enabled.  The exception case is that specific permissions are = required to perform dynamic client registration.

About section 4.3:
 
If the =
client does not exist on this server, the server MUST =
respond
   with HTTP 401 Unauthorized, and the Registration =
Access Token used to
   make this request SHOULD be =
immediately =
revoked.
 
If the = Client does not exist on this server, shouldn't it return a "404 = Not Found"?

If revoking the registration access token, is it = bound to a single client registration?  This is not clear. =  What is the lifecycle around registration access token? Only hint = is in the Client Information Response in section = 5.1.
 =
The language about the 401 here (and in other = nearby sections) is specifically so that you treat a missing client and = a bad registration access token the same way. You see, returning a = 404 here actually indicates things were in an inconsistent state. = Namely, that the registration access token was still valid but the = client that the registration access token was attached to doesn't exist = anymore. The registration access token in meant to be tied to a client's = instance (or registration), so it's actually more sensible to act as = though the registration access token isn't valid anymore. In at least = some implementations (specifically ours at MITRE that's built on = SECOAUTH in Java), you'd never be able to reach the 404 state due to = consistency checking with the inbound = token.
 
Since the intent = of the registration access token is that it's bound to a single = instance, its lifecycle is generally tied to the lifecycle begins at the = issuance of a new client_id with that instance. That token might be = revoked and a new one issued on Read and Update requests to the Client = Configuration Endpoint (and the client needs to be prepared for that -- = same as the client_secret), and it will be revoked when the client is = deleted either with a Delete call to the Client Configuration Endpoint = or something happening out-of-band to kill the = client. 
 
Should we = add more explanatory text to the definition in the terminology section? = Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd = like.
 
I think we should look at it.


About section = 5.1: 
The = registration_access_token is unique to a registered client, in the RFC = 6749 sense of =E2=80=9Cclient=E2=80=9D.  Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly.

Suggest = rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to = rename =E2=80=9Cissued_at=E2=80=9D to = =E2=80=9Cid_issued_at=E2=80=9D
 
While I do like the = suggestion of changing these to client_secret_expires_at and = client_id_issued_at, and I think these are more clear and = readable,


I don't want = to change the syntax during last call unless there is a clear need and a = clear consensus for doing = so.
 
That's why we = are having last call. To confirm consensus on the = draft. 
 
Same reasoning as earlier. You now have multiple tokens = (registration access and client) in play. The spec needs to be clear = which one it is talking about.
 
I'm fine with the suggested = change but I would like more feedback from other people before moving = forward with it. There's a lot of value in "just pick a name and ship = it" as well though, and I don't want to devolve into bike shedding. (I'm = not accusing you of bike shedding quite yet, btw, just afraid of getting = into a long debate on names.)
 
Again, this was a problem raised by = people new to the specification. They found it confusing. I tend to = agree. We're not talking about what colour to paint the shed. We're = talking about whether the bike shed is a = house.  :-) 
I'm not too fussed about whether you = call it "cl_sec_expiry" or = "client_secret_expires_at". 

If the definitions = of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2=80=9D are = unclear, we should clarify them.  If you believe that this is the = case Phil, can you supply proposed alternative definition text that is = clearer?  That being said, I believe that at this point we should = stick with the existing protocol element names unless overwhelming = working group sentiment emerges to change them.  They are already = working fine as-is in production deployments.
 
Yes, the client is supposed = to either call the read or update methods on the client configuration = endpoint to get its new secret. As discussed above, I'm not sure that's = as clear as it needs to be, and I welcome suggestions on how to clarify = this.
 
Either is a reasonable behavior on the = behalf of clients, depending upon context.  I support adding text = to clarify this.
Yes. Much of the feedback is coming from our development = community. 
Ah, very cool. Developer experience is = the most valuable feedback, in my opinion. If you can't actually build = the blasted thing, what good is it? :)
Glad to hear that = you=E2=80=99re working with developers building the spec.  Please = thank them for the feedback.
 -- Justin
 

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

= --Apple-Mail=_4ECF6BC9-E662-46FA-A1E6-5219AE6B8CEB-- From Michael.Jones@microsoft.com Tue May 21 11:32:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112AE11E80D2 for ; Tue, 21 May 2013 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l81zDFiHUSbe for ; Tue, 21 May 2013 11:31:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id A110621F95FF for ; Tue, 21 May 2013 11:31:55 -0700 (PDT) Received: from BL2FFO11FD025.protection.gbl (10.173.161.203) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.698.0; Tue, 21 May 2013 18:28:33 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Tue, 21 May 2013 18:28:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Tue, 21 May 2013 18:28:19 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOVjRC7EIUuQ3MakO6lkHhIS5M25kP62cxgAAH2ACAAAJGrQ== Date: Tue, 21 May 2013 18:28:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367749249@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org>, <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367749249TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(54094003)(51444003)(479174002)(50854003)(24454002)(51914003)(15454003)(66654002)(377424003)(199002)(189002)(85644002)(377454002)(74502001)(51856001)(16601075002)(15202345002)(20776003)(44976003)(56776001)(63696002)(46102001)(31966008)(53806001)(74876001)(59766001)(15974865001)(76482001)(80022001)(15395725003)(54316002)(79102001)(65816001)(74662001)(81342001)(77982001)(56816002)(47736001)(16406001)(50986001)(81542001)(49866001)(54356001)(69226001)(4396001)(47976001)(74366001)(71186001)(16236675002)(6806003)(47446002)(33656001)(74706001)(55846006)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08534B37A7 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 18:32:29 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367749249TK5EX14MBXC283r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable What is the loss of information that you=92re concerned about? It seems od= d to me that you=92re asserting that there's information loss when the oper= ations performed by Dynamic Client Registration are equivalent to those tha= t are performed by out-of-band OAuth developer portals today. It=92s just = automating a formerly manual process. -- Mike From: Phil Hunt Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD11=FD:=FD20=FD =FDAM To: Mike Jones Cc: Justin P. Richer, oauth@ietf.org WG Mike, There is an operational loss of information in the dynamic registration spe= c. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-21, at 10:52 AM, Mike Jones wrote: No information is being thrown away. Developers can use dynamic registrati= on to obtain a client_id and then have all the client instances use that cl= ient_id if they choose - just like they can do when doing out-of-band regis= tration with a site=92s developer portal. The only difference is that they= don=92t have to do out-of-band registration anymore! -- Mike From: Phil Hunt Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD8=FD:=FD02=FD =FDAM To: Justin Richer Cc: oauth@ietf.org WG Regarding charter. The charter is a one-liner. To say associating clients is not in the charte= r while saying every other 'new' thing that is in the spec (eg client auth = type) is in is laughable. After all the entire draft is new functionality. The item i have asked for is not new. It preserves information that was ava= ilable without reg. Namely a way to recognize multiple clients as a common = public client as in 6749 they share a client_id. The draft throws this inf= ormation away preventing security admins from making any judgements since a= ll clients are now anonymized. Where in the charter does it say you can anonymize the clients? Phil On 2013-05-21, at 6:46, Justin Richer > wrote: On 05/21/2013 02:01 AM, Phil Hunt wrote: Phil On 2013-05-20, at 8:35, Justin Richer > wrote: On 05/17/2013 05:27 PM, Phil Hunt wrote: Mike, Rather then embed comments in an extended thread, I'd like to open up a spe= cific discussion on the objective of dyn reg. I see limited to no value in having clients completely anonymously register= ing and receiving tokens without any ability to correlate applications betw= een applications. I think that herein lies a very big disconnect in assumptions. I see a huge= benefit in anonymously registered clients getting tokens because there is = an end-user in the loop during the authorization phase (long after registra= tion has happened). The arity of registrations to authorizations approaches= 1:1 in these cases, and I'm just fine with that. Then what you describe is NOT anonymous but rather a profile not covere= d by the spec as there is no discussion of user authenticated registration.= Implicitly or explicitly. [JR] I think you misunderstand what I said, let me try to be more explicit:= the user is not authenticating the registration. The user is not involved = in the registration. The user might not even know that a registration happe= ned. The registration is (normally) completely anonymous and open, the clie= nt just shows up and says "Hi, I'm a client!". The "authorization" that I mentioned happens later and is a normal OAuth au= thorization, which has a user involved like usual. The authorization step i= n OAuth depends on *some* kind of registration happening beforehand, dynami= c or otherwise. This is all perfectly within the model of OAuth. >From the RFC6749 perspective, a "client" is not a particular piece of code,= it is a particular copy of a piece of code with a particular client_id fro= m the vantage point of a particular authorization server. actually, i disagree. This spec fundamentally breaks the old definitio= n and behavior from 6749. In the old way every instance of software shared = a client_id. In this draft, u throw that away without preserving the inform= ation. This is BAD! [JR] No, we're not throwing that away at all. The concept is the same, but = when you add new functionality, the mechanics change a bit. A "client_id" w= as always pairwise between a client and an AS. If a client had to talk to t= wo AS's before, it would have two client_ids. That's still the case. If the= re were multiple copies of a confidential client, you need to get a client_= id and client_secret to each copy. That's still the case. What's different = is that we've made it *easier* for a particular piece of code to get differ= ent client_ids when it's talking to the same or a different auth server, at= runtime. When you have to manually register every client, you're going to = just do it once. If you can do it dynamically, you have more options. Note that you can *still* have a public client with a known client_id if yo= u want to. You don't even need to use dynamic registration for that. Heck, = you don't need to use dynamic registration for any kind of client if you do= n't want to, since most services will probably still offer manual registrat= ion through some portal kind of page. A "client" is, conceptually, a pairwise association between two running cod= ebases. When you have a particular piece of code talking only to one auth s= erver and being manually configured at said auth server with its client_id,= this is fairly clear and straightforward and the arity is simple. Things g= et a bit muddy when you introduce dynamic registration, which is why I thin= k that we need to have introductory text about this. Specifically: - a particular piece of code can be run on multiple devices and talk to th= e same auth server, each copy of that code getting its own client_id. - a particular copy of a particular piece of code can now be expected to t= alk to multiple auth servers, each auth server giving the piece of code its= own client_id. Both of these are cases of what defines an "instance" in most people's head= s, even though it's the same software, even sometimes the same running copy= of the same software. But as far as RFC6749's definition of "client" is co= ncerned, these are all completely separate "client"s with no way to tie the= m together out of the box. And that's fine. Associating client_id's with known client applications to allow admins to k= now who is running what version of clients seems to be the most fundamental= part of the reason for dynamic reg. How can you revoke access to particula= r client app types? As Justin already talked about in his Blue Button+ sce= nario, there are often life and death situations where particular sets of c= lients need to be revoked. While it's very useful, I wouldn't (and haven't) classified it quite like t= hat. Nor would I say that the BB+ profile is a complete solution -- our Reg= istry component does not actually push revocation notifications down to Pro= viders (yet), so it's more like invalidating a root certificate and waiting= for caches to time out for things to cascade. We've been talking about add= ing some form of callback to providers, but we don't want to boil that part= icular ocean right now. However, the BB+ profile makes use of a well-specif= ied discovery and Registry set up, as well as data conveyed in structured, = signed tokens (JWTs) at different points in the process. Or put another way. I believe this will be a critical operational requireme= nt going forwards. If the spec is published as is, it will be quickly inval= idated by one that does at least partially address the problem. That's not true at all. BB+ addresses this scenario and still uses the Dyna= mic Registration spec as-is. I would encourage folks to read what we're doi= ng, a work-in-progress found here: but you are breaking other things and overloading client cred etc to p= ass in signed data. I don't want a hack for a solution. I want interop. [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks c= ompatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fi= x there. It is our intent to be fully compatible with OAuth Dyn Reg, and we= are even explicitly calling for open registration as mandatory to implemen= t for authorization servers within BB+, even though we have additional mech= anisms as well for what we're calling "trusted registrations". For those tr= usted registrations, we're not using the client *credentials* to pass in si= gned data, we're using the initial *registration authentication* mechanism = (which is to say, an OAuth token) for its intended purpose: authorizing the= holder of this token access to the registration endpoint. In BB+, we're pr= ofiling exactly what that means. To wit, we define the content of the token= (which is fully compatible with DynReg which doesn't care what's in the to= ken) and how the AS can verify it (which DynReg doesn't care how it happens= ) and we've added some additional rules and policies that allow us to tie t= ogether instances of the client across the distributed network. So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amo= unt of very specific machinery (signed tokens with known formats and fields= , a Registry with manual pre-registration, a three-tiered discovery service= with information about clients and service providers rooted at the Registr= y, trust frameworks and network enforcement policies that all players have = to agree to before playing, etc.), and it's not really doing just registrat= ion anymore. In BB+, we needed the Registry and Discovery services to do ot= her functions as well apart from just registration, and so it makes sense t= o re-use them. If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced th= at a good solution for managing client instances across a network requires = a lot more thought and consideration, and I believe that having a fully spe= cified discovery service will help this case, like it has helped in BB+. Bu= t I think that it's a complex enough problem that it needs its own set of c= onsiderations. With DynReg, we need to leave things open for that work in t= he future, and I believe we have, but we shouldn't kill the simple, general= case for want of a special case. http://blue-button.github.io/blue-button-plus-pull/ Just because you make something better doesn't mean you throw necessarily a= way everything you've done to date. We're ahead of schedule, lets talk through the requirement. I believe that the requirement of tying instances together is explicitly ou= t of scope for the dynamic registration protocol. I intended to have text t= o that effect in the section I'm adding about the client lifecycle. where is this stated in charter? [JR] The charter for the working states what's in scope, not what's out of = scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abo= ut registration is this: And dynamic client registration will make it easier to broadly deploy OAuth clients (performing services to users). And: Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG fo= r consideration as a Proposed Standard There's nothing in there at all about tying together client instances. I ha= ve not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client = registration. It sounds very likely to me that it *is* required for your us= e case, but that doesn't make it required for everybody's use case. There are other important pieces of functionality that the WG isn't picking= up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for thos= e to be separate modules. As I mentioned in my comments to the other thread. Let's say we agree not d= o this now. Well, then the new draft that does solve it would likely be 95%= overlap. Thus I see this issue as within charter and should be solved now= rather then waiting for a V2 dyn reg in the next charter. Why wouldn't the new draft just be the extra 5%? I personally think that it= 's a lot more than 5% once you have in all the assurance and safety mechani= sms in place to avoid self-asserted values causing race conditions, and wha= t not. Two drafts to do registration is not the way to go. It implies complex= ity where there should be none. There is no technical reason for two drafts= . [JR] There is a need when there's a special case that requires a large amou= nt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today). -- Justin Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-17, at 1:08 PM, Mike Jones wrote: Thanks for the detailed feedback, Phil. Sorry for the delayed response =96= I was pretty fully engaged at the European Identity Conference (where OAut= h 2.0 won the award for best new standard :)). My feedback on the points raised is inline in green=85 (Perhaps if any of you reply to this thread, you could also choose a distin= ct color for your inline replies, so that it will be easily evident who sai= d what. As it is, just the back-and-forth between Phil and Justin is alrea= dy very difficult to follow. Thanks.) From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 16, 2013 12:54 PM To: Richer, Justin P. Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 Justin, Thanks for the discussion. More comments below... BTW. I'm happy to contribute text. Just want to get to some rough agreement= first. For example, I think we need to have a away to recognize two piece= s of software as being the same (even if self-asserted). Once defined, I c= an put together some intro text, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: Phil, many thanks for the extremely thorough review! It is very useful inde= ed. My comments and responses to each point are inline. On May 15, 2013, at 4:30 PM, Phil Hunt > wrote: It seems unfortunate that I have not gotten a chance to get into this level= of detail much earlier. But then, I guess that's what LC review is for! My= apologies for not getting many of these concerns to the WG much earlier. Overall ----------- I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Faceboo= k or Flickr and moved on to standards based, open source based, and commerc= ial based deployments where there are multiple service endpoints and many c= lients to manage. The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec: 1. How is a new client application recognized for the first time when depl= oyed against a particular SP endpoint? Should clients actually assert an a= pplication_id UUID that never changes and possibly a version id that does c= hange with versions? In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a particular= OpenID Connect provider, then you can define semantics for tying together = classes of clients (see below for more discussion on this very point). But = in general, a client is just going to show up as a new instance to the AS a= nd get issued a new, unique client_id, and that's that. I think we have to define more clearly what an "instance" is. For me, there= are applications and there are instances of that application. It is usefu= l to understand that a client application represents a set of code that sho= uld behave in a consistent way. It seems to me the first time a new applic= ation shows up is very different from the subsequent instances that registe= r. For example, after the first registration, subsequent instances don't ne= ed special review or approval to the same degree. But without other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other cl= ient instance. Therefore, from the perspective of an AS, the first instance= of an application (i.e., particular configuration of a set of code) to reg= ister is no different to subsequent instances of that same application. How= were you envisioning an AS knowing the difference between the first and su= bsequent instances of an application, specifically? If there's an "applicat= ion_id" like you mention above, I think it raises more questions than it re= solves: Who issues the application_id, some server or the application itsel= f? Is it validated at all? Should it be considered secret? What happens whe= n someone simply steals an application_id? Does an AS have to do anything t= o check with any other AS to see if the application_id has already been use= d elsewhere? I do agree that a discussion of "instance vs. application" would be helpful= in clearing this up, I'll make a note to add text to that effect. (We had = to do something similar for BB+) I think it is simple enough to at least add a self generated UUID for the a= pplication ID. Though I would allow for cases where the application ID is = assigned when the client developer and the APIs owner do a formal assignmen= t of application IDs. In a sense this is just a lower tech way of doing it than what you describe= d as the initial client credential in Blue Button+ where you encoded extra = claims into the initial app credential. What the UUID does is link multiple instances of a client app together as t= he same "thing" that should have similar heuristics/behaviours. This is ve= ry useful if you want to be able to revoke access to a set of clients ident= ified by application id (or a version of that app). While I=92m sympathetic to the OAuth working group eventually doing work on= differentiating between instances of an OAuth client, I=92ll note that in = RFC 6749 or RFC 6750 there is no such thing as a client instance. There ar= e only clients, which are identified by client_id values. If we want to do= work on client instances, we should recharter to add this new work as a wo= rking group deliverable. We should not try to shoehorn bits and pieces of = it into the Dynamic Registration spec, any more than we should have tried t= o shoehorn it into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to registe= r clients as defined in RFC 6749. It=92s not the right place to extend wha= t an OAuth client is in new ways. 2. How are client credentials managed. Are we assuming client credentials = have a limited lifetime or rotation policy? The intent was that client_secret could be rotated, as indicated by the exp= ires_at member of the response. If a client's secret expires, it calls the = read operation on the Client Configuration Endpoint (=A74.2) to get its new= client_secret. If this is unclear in the current text (which I suspect it = may be after multiple refactorings), then I welcome suggestions and specifi= c text as to how to make that clear. Something like this should be in the draft. Should this be up in the introductory text, somewhere else, or have its own= section? I'm starting to think credential management is a key part of the draft. It = may be worth introducing a specific section outling the registration life-c= ycle, registration access token usage, and client token usage and bootstrap= ping. I think that adding a discussion on this would be fine, as it could help de= velopers understand the workflow of registering, using, and updating regist= ered clients. How does a client authenticate the first time and subsequent times to the r= egistration service? This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either: - Not authenticate at all (this is the true public, open registration, an= d it is recommended that servers do this) - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to th= e AS beyond "this client is authorized to register" is out of scope for the= spec, by design. Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is= an OAuth 2.0 Bearer token that is unique to the client instance. Something like this should be in the draft. OK, the definition of the registration access token can be expanded, but I = think that the rest of it is already in there in =A73. I'd welcome suggesti= ons on which bits of this could be made clearer. See the discussion on what the registration_access_token is in the thread = =93Client Credential Expiry and new Registration Access Token - draft-ietf-= oauth-dyn-reg-10=94. I will work with Justin to apply these clarifications= to the specification. This may go into the proposed credential management= overview section discussed above. 3. How is versioning of clients managed? Should each new version of a clie= nt require a change in client registration including possibly changing clie= nt_id and authentication credential? I don't have a strong feeling, but it = is something that implementors should consider. This is up to the AS, really, and I don't think that any global policy woul= d ever fly here. Especially if you consider that the entire notion of "vers= ion" is more fluid these days than it ever has been. I wouldn't mind adding= a discussion in the security considerations if it merits mentioning though= , so that we can help both client developers and server developers institut= e reasonably good policy. I guess the issue is that when a client upgrades it may have access to the = old credentials. What is the intent then of registration. Since you have a= n update are clients expected to update /re-register or not? I'm not sure = this is a security consideration but more part of the whole change manageme= nt function dynamic registration supports. If your upgraded version of the client still has access to its old credenti= als, why wouldn't it just use those? I don't see a reason for forcing a re-= registration. Nor do I see any way that an AS would even be able to tell th= at a client had been upgraded. An upgraded client always has the *option* o= f re-registering itself and getting a new client_id. I think the concern here is that rotation of client credential is not somet= hing discussed before. Before we put it in the spec we should consider the = reasons for doing it and what problems it solves. I think this may be just a case of letting people exchange credentials for = whatever reason they feel is appropriate. The version upgrade thing sugges= ts that when a client is upgraded it should go to the registration server t= o "re-register". Depending on the policy of the server, it may (or may not= ) receive a new client_id and/or new credential. One of the best benefits I can think of is if you discover a version of a c= lient has a problem, being able to select a group of clients by software an= d version is important. Thus if client_id doesn't trace to a particular sof= tware and version, that makes it hard to do. I think you talked about thi= s as an issue for Blue Button+ Again, RFC 6749 defines no client instances or groups of clients, therefore= I believe that it=92s inappropriate to do so here. We don=92t need to boi= l the ocean. If a new charter item is approved to do work on client instan= ces and protocol elements to use and express them, that=92s the time for th= e working group to consider that possibility =96 not as part of Dynamic Cli= ent Registration. 4. What is the registration access token? Why is is used? What is its life= -cycle? When is it issued, when is it changed? When is it deleted? See the response above above and the definition in =A71.2: Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client. If this can be clarified, I welcome text suggestions. The latter part of 1.2 didn't seem like terminology but rather architecture= or part of the introduction that describes what the spec does. The third p= oint doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration acce= ss tokens. Client Registration Endpoint: The OAuth 2.0 Endpoint through which a Client can request new registration. The means of the Client obtaining the URL for this endpoint are out of scope for this specification. o Client Configuration Endpoint: The OAuth 2.0 Endpoint through which a specific Client can manage its registration information, provided by the Authorization Server to the Client. This URL for this endpoint is communicated to the client by the Authorization Server in the Client Information Response. o Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client. This section is meant to just introduce the new terms that are then explain= ed in greater detail throughout the rest of the document. Yes, it's a bit a= rchitecture, but only in the sense that you need to define the terms that m= ake up your architecture. How would you suggest that it change? Probably this is more a matter of style. But, what happened for me is I na= turally skipped the terminology section, as I wasn't expecting protocol com= ponents to be there. "terminology" is something I think people tend to use= as a dictionary rather than as protocol component description. Maybe the = chairs can advise? If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like = tos_uri). I think token_endpoint_auth_method is one thing that should not = be negotiated per instance. When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiated or be di= fferent for the same client software? Should not all instances use the same= authentication method. I'm confused by this -- as far as the dynamic registration spec is concerne= d, all instances are separate from each other. All parameters change per in= stance. And instance, you should keep in mind, is defined as any one copy o= f the client code connecting to any new authorization server. That pairing = creates the client_id, and therefore the instance, and therefore the regist= ration access token, and therefore the registration itself at a conceptual = level. So there is no way other than per-instance for a client to ask for a= particular token_endpoint_auth_method. Where else would the AS find out ab= out it? We still disagree on this. It is my assertion that clients should NEVER ask= for a particular token auth method. Since it is the AS that is authenticat= ing the client, then it is the AS's right to set the authentication policy.= The role of dynamic reg endpoint is to inform the client what it must do.= My assumption is that during the first time a piece of software is regist= ered (the first instance), there could be some OOB discussion by an adminis= trator to approve the particular authentication type for the AS in question= . I haven't heard a reason justifying this parameter other then "it is needed= ". Why? The role of the dynamic registration protocol is twofold: half of that is t= he server informing the client what it must do. But the other half is the c= lient informing the server what it *can* do, or what it *wants* to do. And again, there's no way to distinguish a first instance from a subsequent= instance unless you're doing something in addition. Nothing is stopping th= e same application from registering a new instance of itself for every sing= le user or every single token that it wants to get access for. That's compl= icated and wasteful and not a great idea, sure, but there's no useful way = to prevent that kind of behavior if you also want open registration of clie= nts. I think we've discussed how recognizing subsequent instances is easily done= . As I mentioned in the other thread, if a developer chooses to limit the cap= abilities of the client it must do so by looking to the developer or standa= rd behind the API. Otherwise they are taking the chance. There's no way a= developer can query all the potential deployers to ask what authn types wi= ll you use. As I said, the net effect in the absence of an API standard dic= tating what should be supported, the developer will have to implement all m= ethods. My point here is that none of this is helped by the client app saying what = it supports. A developer who takes the route of limiting implementation tak= es the chance that the server will not accept. So why negotiate within reg= istration? And there's no way other than per-instance for the server to tell the clien= t which token_endpoint_auth_method to use. All instances will probably ask = for the same token_endpoint_auth_method from all auth servers they talk to,= right? And each AS will tell each instance that registers with it to use a= particular auth method. There is no way to tie together different instance= s across (or within) auth servers without specifying a significant amount o= f other machinery. Which is not to say that it's not useful in some circumstances to tie toget= her different instances of the same code across (or within) auth servers. T= his is why, with Blue Button+, we specified a specific token format for the= initial access token that the clients use to call the registration endpoin= t the first time, as well as a discovery protocol against a centralized se= rver that handles pre-registration. All of this machinery is, in my opinion= , a stupendous overkill for the general case, though if some folks find use= for it outside of BB+ then it'd be a good thing to abstract out and make i= ts own spec that extends the Dyn Reg spec in a fully compatible way. Furthe= rmore, even in Blue Button+ we specify that all auth servers MUST also acce= pt open registration, without an initial access token, where the client sim= ply shows up and says "hey, here are my parameters." The auth server has no= way to know in this case any kind of out-of-band negotiation for different= things. In BB+ we are writing very specific policy guidelines about how to= present the UX and things to the end user for all of these different cases= . But again, all of this is specific to the BB+ use case, and I don't see v= alue in dragging it in to the registration spec on its own. I believe it wo= uld be far too limiting. See my previous comments on differentiating client instances being out of s= cope without rechartering to do this new work and on what the registration_= access_token is. In short, the registration_access_token is an RFC 6750 be= arer token issued to the party registering the client, enabling it to subse= quently retrieve information about the client registration and to potential= ly update the registration information for that registered client. Again, = I=92ll work with Justin to make sure that this is as clear as possible in t= he specification. Finally, there seems to be an inconsistent style approach with draft-hardjo= no-oauth-resource-reg which uses ETags. Should this draft do so as well? That's an individual submission, not a working group draft. Nobody has, unt= il now, even mentioned the use of ETags here. UMA (where the resource regis= tration draft comes from) uses ETags, hence their inclusion there. I person= ally don't see their utility here, though, and I wouldn't want to include a= wholly new mechanism this late. Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't h= ave a point. It's worth discussing. One could argue that the point of an ETag is that it is useful for change d= etection when there are multiple writers to a particular resource. In the = design of dynamic registration endpoint, there should only be one writer --= the client. This is an important observation. There are other mechanisms that handle this -- namely, the registration acc= ess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as desc= ribed in =A74.1. If everyone agrees, I'm in agreement. But it will likely mean changes for t= he resource reg draft if adopted. ETags seem like an unnecessary addition (and potential complication) to the= specification. It=92s already working fine as-is. Specific items: --------------------- "token_endpoint_auth_method" There is some confusion as to whether this applies to server or client auth= entication. Suggest renaming parameter to "token_endpoint_client_auth_meth= od" This is the first I've heard of this particular confusion. I'm fine with ei= ther name but at this stage I don't want to make syntax changes without ver= y, very compelling reasons to do so. The question was raised to me by some new developers. It seems obvious to u= s as experienced OAuth persons, but to new developers it seems unclear. Al= so, now that you are introducing registration authentication, the whole thi= ng gets very confusing. So it is useful disambiguate all the parameters whe= re possible. That said, I wouldn't mind shorter names (maybe not quite as = short as the JOSE stuff ;-) Fair enough, but again, I only want to do syntax changes if the rest of the= WG *really* wants to. I agree with Justin here. I=92m fine clarifying the description of this pa= rameter to resolve the potential ambiguities that you cite, Phil. I=92m no= t OK revising the syntax without a compelling reason to do so. * Currently, the API only supports a single value instead of an array. If = the purpose is to allow the client to know what auth methods it supports, t= his should be an array indicated what methods the client supports - or it s= hould not be used. I would rather like this to be an array, personally, and brought it up with= the OpenID Connect working group about six months ago. But there it was de= cided that a single value was simpler and sufficient for the purpose. The I= ETF draft has inherited this decision. I *believe* (though am not 100% posi= tive) that I brought up this very issue in the WG here but didn't receive a= ny traction on it, so single it remains. I can get behind multiple values. In this case, it changes the meaning of t= he parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can perfor= m. This allows the server to assign the appropriate method based on its own= policy. Also note that this field, like all others in =A72, represents two things: = the client telling the server "I want to use this value for this field", an= d the server telling the client "this is the value you have for this field"= . It's not exactly a negotiation, more like making a polite request to an a= bsolute dictator who has the last word anyway. But at least this dictator i= s nice enough to tell you what their decision was instead of just decapitat= ing you. This is the heart of my objection. This fuzziness is is going to lead to in= terop issues. There is no fuzziness that I can see here. It's parallelism between what go= es in to the endpoint and what comes out of it. The semantics for the reque= st and the response are different, and differentiable by the fact that one = is a request and the other is a response. The inter-op issue I would like to point out is that the spec does not curr= ently specify if particular input values are singular or multiple. If an i= mplementer assumes singular and clients assume multiple, we have issues. The multiple/single discussion above gets to the heart of what I *do* belie= ve is a deficiency in the specification, as it=92s currently written. The = authors, myself included, have failed to make it 100% clear that discovery = of Authorization Server functionality is out of scope for this specificatio= n. I strongly believe that we need to add a clear statement to this effect= in the introduction to the specification. The purpose of the Dynamic Client Registration specification is for the cli= ent to register with the Authorization Server and to inform it of propertie= s of the client that the AS may want/need to be aware of. It *is not* the = purpose of this specification for it to be used by clients in any manner to= discover features of the Authorization Server. That should be explicitly = out of scope. Currently, clients are instructed by RFC 6749 to discover information about= Authorization Servers they interact with by consulting the =93service docu= mentation=94 (RFC 6749, Sections 3.1 and 3.2). They can also learn informa= tion about Authorization Servers in specific contexts through discovery pro= tocols such as OpenID Connect Discovery (http://openid.net/specs/openid-con= nect-discovery-1_0.html) and UMA Discovery (TBD). I suspect that at some point, someone in the OAuth working group will propo= se developing a generic OAuth discovery mechanism, which will lead to a rec= hartering to include this work in the working group=92s set of deliverables= . I would support doing this work and the necessary rechartering to do so. That being said, I strongly oppose trying to shoehorn piecemeal aspects of = discovery into the Dynamic Client Registration specification. It is distin= ct functionality and deserves first-class and separable treatment by the wo= rking group. Discovery is for potential clients to learn properties of the= AS before registration. Registration is for potential clients to inform t= he AS of its properties, creating a registered client. Discovery sends inf= ormation about the AS to the Client. Registration sends information about = the Client to the AS. That=92s a clean separation. We should strongly res= ist muddying the two functions. OAuth 2.0 is a success because it didn=92t try to boil the ocean. It speci= fied how to do one thing well in a simple, web-friendly manner. We should = do the same =96 focusing on specifying interoperable dynamic client registr= ation, while making it clear that this is distinct from discovery about Aut= horization Server properties, and making it clear that discovery is out of = scope for this work. I apologize at this point on behalf of myself and the other spec editors fo= r not being 100% clear that discovery functionality is explicitly out of sc= ope for Dynamic Client Registration. If we had done so, I=92m sure that ma= ny of the current questions and confusions would not have arisen. I think = we=92d assumed that this was obvious, but from the current discussions, it= =92s apparent that it=92s not obvious. I will personally commit to clarify= ing the specification at this point to eliminate this potential point of co= nfusion. Getting back to the specifics, the only useful purpose of a multi-valued = =93token_endpoint_client_auth_method=94 member would be to enable the clien= t to discover information about the authentication methods supported by the= AS after the registration had been performed. But that is a discovery fun= ction, and so should be part of the discovery work =96 not this specificati= on. We should resist shoehorning in bits of discovery into this specificat= ion. It *is* a worthwhile topic, but deserves full consideration by the wo= rking group in its own right. Therefore, this member must remain single-va= lued, and be clearly specified as the method by which a client informs the = AS which token endpoint authentication method it will use. Anything else w= ould be scope creep, and result in an unnecessarily complicated specificati= on and unnecessarily complicated clients. * There is no authn method for "client_secret_saml" or "private_key_saml". Nobody has really asked that these two be included or specified. The extens= ion mechanism (using an absolute URI) would allow someone else to define th= ese. Is the definition in the SAML Assertion draft sufficient for their use= ? I think this is coming from the fact that there is a JWT bearer draft and a= SAML bearer draft. The truth is you are defining an authentication that i= sn't even defined. There are no profiles referenced or defined for "client_secret_jwt" or "pri= vate_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover th= ese types of flows. They only cover bearer flows. "client_secret_jwt" and = "private_key_jwt" seem to have some meaning within OpenID Connect, but I no= te that OIDC does not fully define these either. The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically. Actually my interpretation is the JWT draft assumes the JWT Bearer is a bea= rer token. The assumption is that if a client has the assertion it has the= right to present it. IOW. The JWT Bearer Draft is most definitively not a= JWT HoK Draft. :-) Regardless, you are introducing a new profile which is undefined. I think I see the point that you're making now, let me try to re-state it: While the basics of "how to present a JWT as a client credential" is define= d here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.se= ction.2.2 , it's not completely specified in that it doesn't fully restrict= the signature secret source, the audience claim, and other things that the= AS would need to check and validate. Right? The dynamic registration draft= can define those cases in greater detail if needed (though I think it does= so sufficiently as-is, I welcome more clarity). I'd be OK with adding the SAML bit, going into greater detail on the JWT bi= ts, or dropping the JWT bits, if the WG wants to do any of those actions. M= y objection is that the JWT stuff is already in use and functioning and it'= d be a shame to leave it out. I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made= is they assumed everyone had the same definition of bearer token. To me a= bearer token opaque to the client. It therefore cannot do any signature wo= rk with regards to the token itself. Now, that's not to say a proof didn't= occur between the client and the token issuer, but when the client wields = the token, it is handling an opaque string. The concept of client_secret_jwt suggests an HoK profile. Therefore of cou= rse the bearer drafts are a little underspecified when it comes to HoK prof= iles. So for example, you need a draft like the MAC draft for this. I'm having trouble overall here. It seems the authn types suggest ONLY stro= ng authentication for clients, yet during the registration process the curr= ent draft isn't able to correlate multiple instances of the same software (= even in a self-asserted way). If you haven't authenticated the software at= all, why have strong client auth? There is no authentication method defined for "client_bearer_saml" or "clie= nt_bearer_jwt" or "client_bearer_ref". Since the bearer specs say this is = acceptable, the dynamic registration spec should accept these. I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to. 6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wi= eld it as an authentication assertion. The client is NOT creating or modif= ying the assertion. The client is simply passing one it previously obtained= . What you are describing is not bearer. It is holder of key. Very very diffe= rent. A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined. That's possible, but they are in active use already. That may be true. But then you need to write another draft so the rest of u= s can implement it in an interoperable way. Me I prefer not to guess what = you are doing. This much I agree with. Justin, John, and I discussed this issue and agree with your suggestion, Ph= il. Since they are not completely specified, we will remove the client_sec= ret_jwt and private_key_jwt methods from the specification and add a regist= ry, enabling specification that do fully specify these and other token endp= oint authentication methods, including potential methods using SAML asserti= ons, to register them in the registry, rather than trying to bake them into= the Dynamic Client Registration specification. About "tos_uri" and "policy_uri" The distinction between tos_uri and policy_uri is unclear. Can we clarify = or combine them? Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for the= m to be split. Several developers were confused by this. In particular they couldn't figur= e out which was used for what. Just passing along the feedback. OK, the distinction that I see is that the TOS is contractual, the Policy i= s a statement. Re-reading the definitions in there right now, that can be m= ade much clearer. (It even looks like some OIDC text leaked into the defini= tion of policy_uri and that hadn't been caught yet.) I support clarifying the language on these definitions, and will work with = Justin to do so. Also, aren't these really URIs or are they meant to be URLs? There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at u= s, which is a plus. Arg. Nice. Then the text should say the value passed must resolve to a val= id web page, document, whatever. That's fair, and it's something that the AS can even check if it wants to. Agreed on this clarification. About "jwks_uri" A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-key-09 is needed. Yes, you're correct, I'll add that. Should be URL instead of URI? See above. :) Agreed on adding this reference. Section 2.1 In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing. It's there in the copy of -10 I'm reading off of ietf.org= right now =85 ? ' Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer Ah, that makes more sense. If the WG wants to add in SAML support to parall= el the JWT support, I'd be OK with that. =93As such, a server supporting these fields SHOULD take steps to ensure th= at a client cannot register itself into an inconsistent state.=94 We may want to define more detailed HTTP error response. E.g. 400 status co= de + defined error code (=93invalid_client_metadata=94)? I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special. I *think* that this goes away with the deletion of client_secret_jwt and pr= ivate_key_jwt in favor of the registry=85 I=92ll do a consistency check an= d verify that when the spec is updated accordingly. Section 2.2 May want to add: When =93#=94 language tag is missing, (e.g. =93#en=94 is missing in =93clie= nt_name=94, instead of =93client_name#en=94) the OAuth server may use inter= pret the language used based on server configuration or heuristics. That seems inconsistent with what we already have: If any human-readable field is sent without a language tag, parties using i= t MUST NOT make any assumptions about the language, character set, or scrip= t of the string value, and the string value MUST be used as-is wherever it = is presented in a user interface. Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy. I will discuss with our developers. I'm not sure the as-is works. Is it the intent that when the client has localized "client_name" for examp= le, it should pass all language variations in a JSON array? Or, should part of the registration be to indicate which interface language= the client wishes to use? Then it only passes a single value for that reg= istration? No, the client should pass parameters as multiple separate values. Connect = has this in its example: "client_name": "My Example", "client_name#ja-Jpan-JP": "???????", Should we add that to at least one of the examples in DynReg? (The language= tags are a late addition, so the examples don't reflect it.) An example would definitely help. If the client passes only a single unadorned field, the AS can't make any a= ssumption about what language it is. Think of this as the internationalized= value of the field while the language tags are the localized versions of t= he field. This is why we recommend that the bare-value always be sent by th= e client, so that in the lack of anything more specific, the AS can at leas= t do *something* with it. Passing in a "default" language field (like default_locale or the like) is = only going to lead to pain for implementors of both clients and servers, an= d it's going to hurt the interoperability of the human-readable fields. I think what I meant is since you are allowing each client to register diff= erent things, AND the client likely already knows the user's preferred lang= uage, why wouldn't the client just pass text values in one language and ano= ther parameter indicating preferred language in the case of any service gen= erated text. Is the reason you are passing multiple localizations is so that you can use= the preferred language of the resource owner rather then the client user? = I wonder if that is correct. If the language preferences are in fact diffe= rent, what would the user of the client app expect? ----> any multi-lingual people have any opinions here? Without specific proposed text changes to review, it=92s hard to know what = to think about this comment. Unless a specific proposed text change is sen= t to the list with clear rationale for why it=92s better than what=92s ther= e now and reviewed by the working group, I don=92t believe we should change= the specification in response to this comment. Section 3 Existing text: =93In order to support open registration and facilitate wider interoperabil= ity, the Client Registration Endpoint SHOULD allow initial registration req= uests with no authentication. These requests MAY be rate-limited or otherw= ise limited to prevent a denial-of-service attack on the Client Registratio= n Endpoint.=94 I would suggest to change the first =93SHOULD=94 to =93MAY=94. In most cl= oud services, the first client is registered by a human user. Then, other c= lients can be further used to automate other client registration. So, the = first request would typically come with an authenticated user identity. I think the weight of "SHOULD" is appropriate here, because I believe that = turning off open registration at the AS (which is what this is talking abou= t) really ought to be the exception rather than the rule. I think you are reading it wrong -- a double-negative issue. The end of the= sentence is "no authentication". You are implying that NO Authentication = us what should normally be done. I think you intend anonymous authenticatio= n to be the exception rather than the rule don't you? No, I think that anonymous authentication should be the rule. Open registra= tion should be default. I disagree. Again, the spec seems contradictory. It suggests strong clien= t auth methods and at the same time anonymous registration. Yes you gain u= niqueness, but that's about it. On the flip side, the earlier paragraph: =93The Client Registration Endpoint MAY accept an initial authorization cre= dential in the form of an OAuth 2.0 [RFC6749] access token in order to limi= t registration to only previously authorized parties. The method by which t= his access token is obtained by the registrant is generally out-of-band and= is out of scope of this specification.=94 I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= . That access token would carry a human user authenticated identity somehow. = In some cases, it can be a pure authenticated user assertion token. Again, disagree, for the same reasoning as above. Same reasoning. I agree with Justin here. The default should be that open registrations ar= e enabled. The exception case is that specific permissions are required to= perform dynamic client registration. About section 4.3: If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the Registration Access Token used to make this request SHOULD be immediately revoked. If the Client does not exist on this server, shouldn't it return a "404 Not= Found"? If revoking the registration access token, is it bound to a single client r= egistration? This is not clear. What is the lifecycle around registration= access token? Only hint is in the Client Information Response in section 5= .1. The language about the 401 here (and in other nearby sections) is specifica= lly so that you treat a missing client and a bad registration access token = the same way. You see, returning a 404 here actually indicates things were = in an inconsistent state. Namely, that the registration access token was st= ill valid but the client that the registration access token was attached to= doesn't exist anymore. The registration access token in meant to be tied t= o a client's instance (or registration), so it's actually more sensible to = act as though the registration access token isn't valid anymore. In at leas= t some implementations (specifically ours at MITRE that's built on SECOAUTH= in Java), you'd never be able to reach the 404 state due to consistency ch= ecking with the inbound token. Since the intent of the registration access token is that it's bound to a s= ingle instance, its lifecycle is generally tied to the lifecycle begins at = the issuance of a new client_id with that instance. That token might be rev= oked and a new one issued on Read and Update requests to the Client Configu= ration Endpoint (and the client needs to be prepared for that -- same as th= e client_secret), and it will be revoked when the client is deleted either = with a Delete call to the Client Configuration Endpoint or something happen= ing out-of-band to kill the client. Should we add more explanatory text to the definition in the terminology se= ction? Elsewhere? I'm very open to concrete suggestions with this, since I = don't think it's as clear as we'd like. I think we should look at it. For security reasons, it=92s generally not good to distinguish between =93n= ot found=94 and =93unauthorized=94 errors in responses, as that can provide= the attacker an oracle to probe whether a particular entity exists I don= =92t think a change is called for here. About section 5.1: Is registration_access_token unique? Or is it shared by multiple instances= ? If shared, then registration_access_token can't be revoked on delete of= client. The registration_access_token is unique to a registered client, in the RFC = 6749 sense of =93client=94. Again, if we want to do work on =93client inst= ances=94, we need to recharter and take this distinct work item up explicit= ly. Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, Suggest to rename =93issued_at=94 to =93id_issued_at=94 While I do like the suggestion of changing these to client_secret_expires_a= t and client_id_issued_at, and I think these are more clear and readable, I don't want to change the syntax during last call unless there is a clear = need and a clear consensus for doing so. That's why we are having last call. To confirm consensus on the draft. Same reasoning as earlier. You now have multiple tokens (registration acces= s and client) in play. The spec needs to be clear which one it is talking a= bout. I'm fine with the suggested change but I would like more feedback from othe= r people before moving forward with it. There's a lot of value in "just pic= k a name and ship it" as well though, and I don't want to devolve into bike= shedding. (I'm not accusing you of bike shedding quite yet, btw, just afra= id of getting into a long debate on names.) Again, this was a problem raised by people new to the specification. They f= ound it confusing. I tend to agree. We're not talking about what colour to = paint the shed. We're talking about whether the bike shed is a house. :-) I'm not too fussed about whether you call it "cl_sec_expiry" or "client_sec= ret_expires_at". If the definitions of =93expires_at=94 or =93issued_at=94 are unclear, we s= hould clarify them. If you believe that this is the case Phil, can you sup= ply proposed alternative definition text that is clearer? That being said,= I believe that at this point we should stick with the existing protocol el= ement names unless overwhelming working group sentiment emerges to change t= hem. They are already working fine as-is in production deployments. Section 7 When a client_secret expires is it the intent that clients do an update or = refresh to get a new client secret? Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this. Either is a reasonable behavior on the behalf of clients, depending upon co= ntext. I support adding text to clarify this. Again, thanks for the very thorough read through. Have you implemented any = of the spec yet, either as-is or with any of your suggested changes? Yes. Much of the feedback is coming from our development community. Ah, very cool. Developer experience is the most valuable feedback, in my op= inion. If you can't actually build the blasted thing, what good is it? :) Glad to hear that you=92re working with developers building the spec. Plea= se thank them for the feedback. -- Justin Best wishes, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394367749249TK5EX14MBXC283r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
What is the loss of information that you=92re concerned about?  I= t seems odd to me that you=92re asserting that there's information loss whe= n the operations performed by Dynamic Client Registration are equivalent to= those that are performed by out-of-band OAuth developer portals today.  It=92s just automating a formerly man= ual process.
 
-- Mike
 
 
From: Phil Hunt
Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD11=FD:=FD20= =FD =FDAM
To: Mike Jones
Cc: Justin P. Richer, oauth@ietf.org WG
 
Mike,

There is an operational loss of information in the dynamic registratio= n spec.

On 2013-05-21, at 10:52 AM, Mike = Jones wrote:

No information is being thrown away.  Developers can use dynamic = registration to obtain a client_id and then have all the client instances u= se that client_id if they choose - just like they can do when doing ou= t-of-band registration with a site=92s developer portal.  The only difference is that they don=92t have to do out-of-b= and registration anymore!
 
-- Mike
 
 
From: Phil Hunt
Sent: =FDTuesday=FD, =FDMay=FD =FD21=FD, =FD2013 =FD8=FD:=FD02= =FD =FDAM
To: Justin Richer
Cc: oauth@ietf.org WG
 
Regarding charter. 

The charter is a one-liner. To say associating clients is not in the c= harter while saying every other 'new' thing that is in the spec (eg client = auth type) is in is laughable. After all the entire draft is new functional= ity. 

The item i have asked for is not new. It preserves information that wa= s available without reg. Namely a way to recognize multiple clients as a co= mmon public client as in 6749 they share a client_id.  The draft throw= s this information away preventing security admins from making any judgements since all clients are now anonymized.

Where in the charter does it say you can anonymize the clients? <= /div>

Phil

On 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org= > wrote:


On 05/21/2013 02:01 AM, Phil Hunt wrote:


Phil

On 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org= > wrote:


On 05/17/2013 05:27 PM, Phil Hunt wrote:
Mike,

Rather then embed comments in an extended thread, I'd like to open up = a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously reg= istering and receiving tokens without any ability to correlate applications= between applications. 

I think that herein lies a very big disconnect in assumptions. I see a huge= benefit in anonymously registered clients getting tokens because there is = an end-user in the loop during the authorization phase (long after registra= tion has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm jus= t fine with that. 
<Ph>Then what you describe is NOT anonymous but rather a profile not = covered by the spec as there is no discussion of user authenticated registr= ation. Implicitly or explicitly. = ;

[JR] I think you misunderstand what I said, let me try to be more explicit:= the user is not authenticating the registration. The user is not involved = in the registration. The user might not even know that a registration happe= ned. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi,= I'm a client!". 
The "authorization" that I mentioned happens later and is a norma= l OAuth authorization, which has a user involved like usual. The authorizat= ion step in OAuth depends on *some* kind of registration happening beforeha= nd, dynamic or otherwise. This is all perfectly within the model of OAuth. 


>From the RFC6749 perspective, a "client" is not a particular piec= e of code, it is a particular copy of a piece of code with a particular cli= ent_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the ol= d definition and behavior from 6749. In the old way every instance of softw= are shared a client_id. In this draft, u throw that away without preserving= the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, but = when you add new functionality, the mechanics change a bit. A "client_= id" was always pairwise between a client and an AS. If a client had to= talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a conf= idential client, you need to get a client_id and client_secret to each copy= . That's still the case. What's different is that we've made it *easier* fo= r a particular piece of code to get different client_ids when it's talking to the same or a different auth= server, at runtime. When you have to manually register every client, you'r= e going to just do it once. If you can do it dynamically, you have more opt= ions. 

Note that you can *still* have a public client with a known client_id if yo= u want to. You don't even need to use dynamic registration for that. Heck, = you don't need to use dynamic registration for any kind of client if you do= n't want to, since most services will probably still offer manual registration through some portal kind of = page.



A "client" is, conceptually, a pairwise association between = two running codebases. When you have a particular piece of code talking onl= y to one auth server and being manually configured at said auth server with= its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic= registration, which is why I think that we need to have introductory text = about this. Specifically:

 - a particular piece of code can be run on multiple devices and talk = to the same auth server, each copy of that code getting its own client_id.<= span class=3D"Apple-converted-space"> 
 - a particular copy of a particular piece of code can now be expected= to talk to multiple auth servers, each auth server giving the piece of cod= e its own client_id. 

Both of these are cases of what defines an "instance" in most peo= ple's heads, even though it's the same software, even sometimes the same ru= nning copy of the same software. But as far as RFC6749's definition of &quo= t;client" is concerned, these are all completely separate "client"s with no way to tie them together out of the b= ox. And that's fine.


Associating client_id's with known client applications to allow admins= to know who is running what version of clients seems to be the most fundam= ental part of the reason for dynamic reg. How can you revoke access to part= icular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often lif= e and death situations where particular sets of clients need to be revoked.=   
While it's very useful, I wouldn't (and haven't) classified it quite like t= hat. Nor would I say that the BB+ profile is a complete solution -- our= Registry component does not actually push revocation notifications down to= Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for thi= ngs to cascade. We've been talking about adding some form of callback to pr= oviders, but we don't want to boil that particular ocean right now. However= , the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in = structured, signed tokens (JWTs) at different points in the process.


Or put another way. I believe this will be a critical operational requ= irement going forwards. If the spec is published as is, it will be quickly = invalidated by one that does at least partially address the problem.
That's not true at all. BB+ addresses this scenario and still uses the = Dynamic Registration spec as-is. I would encourage folks to read what we're= doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred et= c to pass in signed data. I don't want a hack for a solution. I want intero= p. 
[JR] I'm curious, what exactly are we breaking? If anything in BB+ brea= ks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we ne= ed to fix there. It is our intent to be fully compatible with OAuth Dyn Reg= , and we are even explicitly calling for open registration as mandatory to implement for authorization servers with= in BB+, even though we have additional mechanisms as well for what we'r= e calling "trusted registrations". For those trusted registration= s, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication*= mechanism (which is to say, an OAuth token) for its intended purpose: auth= orizing the holder of this token access to the registration endpoint. In BB= +, we're profiling exactly what that means. To wit, we define the content of the token (which is fully com= patible with DynReg which doesn't care what's in the token) and how the AS = can verify it (which DynReg doesn't care how it happens) and we've added so= me additional rules and policies that allow us to tie together instances of the client across the distribut= ed network. 

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amo= unt of very specific machinery (signed tokens with known formats and fields= , a Registry with manual pre-registration, a three-tiered discovery service= with information about clients and service providers rooted at the Registry, trust frameworks and network= enforcement policies that all players have to agree to before playing, etc= .), and it's not really doing just registration anymore. In BB+, we nee= ded the Registry and Discovery services to do other functions as well apart from just registration, and so it make= s sense to re-use them. <= br>
If there were a simple solution that didn't leave security holes the size o= f a small army, I'd be glad to bring it to the table. But I am convinced th= at a good solution for managing client instances across a network requires = a lot more thought and consideration, and I believe that having a fully specified discovery service will help th= is case, like it has helped in BB+. But I think that it's a complex eno= ugh problem that it needs its own set of considerations. With DynReg, we ne= ed to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, ge= neral case for want of a special case. 


  http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw necessarily a= way everything you've done to date.


We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly ou= t of scope for the dynamic registration protocol. I intended to have text t= o that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
[JR] The charter for the working states what's in scope, not what's out of = scope, correct? It has been my understanding of IETF process that additiona= l functionality needs to be considered separately. All the charter says abo= ut registration is this:

And dynamic clie= nt registration will make
it easier to broadly deploy OAuth clients (performing services to
users).

And: 

Sep 2013 Submit = 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration = as a Proposed Standard
There's nothing in there at all about tying together client instances. I ha= ve not seen anything to convince me that management of client instances acr= oss a deployed network of auth servers is a necessary part of basic client = registration. It sounds very likely to me that it *is* required for your use case, but that doesn't make it re= quired for everybody's use case. = ;

There are other important pieces of functionality that the WG isn't picking= up right now (such as token chaining and token introspection) that are abs= olutely necessary for my own use cases, but I think it makes sense for thos= e to be separate modules.



As I mentioned in my comments to the other thread. Let's say we agree = not do this now. Well, then the new draft that does solve it would likely b= e 95% overlap.  Thus I see this issue as within charter and should be = solved now rather then waiting for a V2 dyn reg in the next charter.
Why wouldn't the new draft just be the extra 5%? I personally think that it= 's a lot more than 5% once you have in all the assurance and safety mechani= sms in place to avoid self-asserted values causing race conditions, and wha= t not.

<ph> Two drafts to do registration is not the way to go. It implies c= omplexity where there should be none. There is no technical reason for two = drafts. 
[JR] There is a need when there's a special case that requires a large amou= nt of overhead to be done correctly, to allow the general case to move forw= ard and be used on its own (as it is being used today). 


 -- Justin


On 2013-05-17, at 1:08 PM, Mike Jones wrote:

Thanks for the detailed feedback, Phil.  Sorry fo= r the delayed response =96 I was pretty fully engaged at the European Ident= ity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green=85
 
(Perhaps if any of you reply to this thread, you could= also choose a distinct <= /span>color for your inline replies, so that it will be easily evident who said what. = ; As it is, just the back-and-forth between Phil and Justin is already very= difficult to follow.  Thanks.)
 
From:<= span class=3D"Apple-converted-space"> oauth-bounces@ietf.or= g [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Phil Hunt<= br> Sent: Thursday, Ma= y 16, 2013 12:54 PM
To: Richer, Justin= P.
Cc: oauth@ietf.org WG
Subject: Re: [OAUT= H-WG] Last call review of draft-ietf-oauth-dyn-reg-10
 
Justin,
 
Thanks for the discussion. More comments below...
 
BTW. I'm happy to contribute text. Just want to get to some rough agreement= first.  For example, I think we need to have a away to recognize two = pieces of software as being the same (even if self-asserted).  Once de= fined, I can put together some intro text, etc.
 
 
On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
 
On May 15, 2013, at 10:30 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:
 
On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
 
Phil, many thanks for the extremely thorough review! It is very useful= indeed. 
 
My comments and responses to each point are inline. 
 
On May 15, 2013, at 4:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote= :
 
It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is fo= r! My apologies for not getting many of these concerns to the WG much earli= er.
 
Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now = that we are starting to consider how individual client applications should = operate when there is one or more deployments of a particular resource API.= We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to stan= dards based, open source based, and commercial based deployments where ther= e are multiple service endpoints and many clients to manage.
 
The dynamic registration spec is actually dealing with a couple of issues t= hat I would like to see made more clear in early part of the spec:
 
1.  How is a new client application recognized for the first time when= deployed against a particular SP endpoint?  Should clients actually a= ssert an application_id UUID that never changes and possibly a version id t= hat does change with versions?
 
In the general case, why is any recognition required? If you're doing thing= s as part of a larger protocol ecosystem, like Blue Button+ or a partic= ular OpenID Connect provider, then you can define semantics for tying toget= her classes of clients (see below for more discussion on this very point). But in general, a client is just goin= g to show up as a new instance to the AS and get issued a new, unique clien= t_id, and that's that. 
 
I think we have to define more clearly what an "instance" is. For= me, there are applications and there are instances of that application. &n= bsp;It is useful to understand that a client application represents a set o= f code that should behave in a consistent way.  It seems to me the first time a new application shows up is very dif= ferent from the subsequent instances that register. For example, after the = first registration, subsequent instances don't need special review or appro= val to the same degree.
 
But without other mechanisms to tie things together, there's no way for an = authorization server to know if any client instance is tied to any other cl= ient instance. Therefore, from the perspective of an AS, the first instance= of an application (i.e., particular configuration of a set of code) to register is no different to subsequent = instances of that same application. How were you envisioning an AS knowing = the difference between the first and subsequent instances of an application= , specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves:= Who issues the application_id, some server or the application itself? Is i= t validated at all? Should it be considered secret? What happens when someo= ne simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the ap= plication_id has already been used elsewhere?
 
I do agree that a discussion of "instance vs. application" would = be helpful in clearing this up, I'll make a note to add text to that effect= . (We had to do something similar for BB+)
 
I think it is simple enough to at least add a self generated UUID for the a= pplication ID.  Though I would allow for cases where the application I= D is assigned when the client developer and the APIs owner do a formal assi= gnment of application IDs.
 
In a sense this is just a lower tech way of doing it than what you describe= d as the initial client credential in Blue Button+ where you encoded ex= tra claims into the initial app credential.
 
What the UUID does is link multiple instances of a client app together as t= he same "thing" that should have similar heuristics/behaviours. &= nbsp;This is very useful if you want to be able to revoke access to a set o= f clients identified by application id (or a version of that app).
 
While I=92m sympathetic to the OAuth working group eventuall= y doing work on differentiating between instances of an OAuth client, I=92l= l note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which= are identified by client_id values.  If we want to do work on client = instances, we should recharter to add this new work as a working group deli= verable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we shou= ld have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg= is there to register clients as defined in RFC 6749.  It=92s not the = right place to extend what an OAuth client is in new ways.
 
2.  How are client credentials managed. Are we assuming client credent= ials have a limited lifetime or rotation policy?
 
The intent was that client_secret could be rotated, as indicated by th= e expires_at member of the response. If a client's secret expires, it calls= the read operation on the Client Configuration Endpoint (=A74.2) to get it= s new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings= ), then I welcome suggestions and specific text as to how to make that clea= r. 
Something like this should be in the draft.
 
Should this be up in the introductory text, somewhere else, or have its own= section?
 
I'm starting to think credential management is a key part of the draft= . It may be worth introducing a specific section outling the registration l= ife-cycle, registration access token usage, and client token usage and boot= strapping.
 
I think that adding a discussion on this would be fine,= as it could help developers understand the workflow of registering, using,= and updating registered clients.
 
How does a client authenticate the first time and subsequent times to the r= egistration service?
 
This is a separate question all together, as it does not involve the client= _secret or client_id at all. Rather, the first time the client shows up to = the registration service, it may either:
  - Not authenticate at all (this is the true public, open registratio= n, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer tok= en). How the client gets that bearer token and what the bearer token means = to the AS beyond "this client is authorized to register" is out o= f scope for the spec, by design.
 
Subsequent times that the same registered client (by which we mean the same= instance of a client with a particular client_id) shows up at the registra= tion endpoint (actually, the Client Configuration Endpoint), it uses its Re= gistration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that= is unique to the client instance.
 
Something like this should be in the draft.
 
OK, the definition of the registration access token can be expanded, but I = think that the rest of it is already in there in =A73. I'd welcome suggesti= ons on which bits of this could be made clearer.
 
See the discussion on what the registration_access_token is = in the thread =93Client Credential Expiry and new Registration Access Token= - draft-ietf-oauth-dyn-reg-10=94.  I will work with Justin to apply these clarifications to the specification.&= nbsp; This may go into the proposed credential management overview section = discussed above.
 
3.  How is versioning of clients managed? Should each new version of a= client require a change in client registration including possibly changing= client_id and authentication credential? I don't have a strong feeling, bu= t it is something that implementors should consider.
 
This is up to the AS, really, and I don't think that any global policy= would ever fly here. Especially if you consider that the entire notion of = "version" is more fluid these days than it ever has been. I would= n't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both cl= ient developers and server developers institute reasonably good policy.
 
I guess the issue is that when a client upgrades it may have access to the = old credentials. What is the intent then of registration.  Since you h= ave an update are clients expected to update /re-register or not?  I'm= not sure this is a security consideration but more part of the whole change management function dynamic registration= supports.
 
If your upgraded version of the client still has access to its old credenti= als, why wouldn't it just use those? I don't see a reason for forcing a re-= registration. Nor do I see any way that an AS would even be able to tell th= at a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getti= ng a new client_id. 
I think the concern here is that rotation of client credential is not somet= hing discussed before. Before we put it in the spec we should consider the = reasons for doing it and what problems it solves.
 
I think this may be just a case of letting people exchange credentials for = whatever reason they feel is appropriate.  The version upgrade thing s= uggests that when a client is upgraded it should go to the registration ser= ver to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or n= ew credential.  
 
One of the best benefits I can think of is if you discover a version of a c= lient has a problem, being able to select a group of clients by software an= d version is important. Thus if client_id doesn't trace to a particular sof= tware and version, that makes it hard to do.  I  think you talked about this as an issue for Blue= Button+
 
Again, RFC 6749 defines no client instances or groups of cli= ents, therefore I believe that it=92s inappropriate to do so here.  We= don=92t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol eleme= nts to use and express them, that=92s the time for the working group to con= sider that possibility =96 not as part of Dynamic Client Registration.
 
4.  What is the registration access token? Why is is used? What is its= life-cycle?  When is it issued, when is it changed? When is it delete= d?
 
See the response above above and the definition in =A71.2: 
 
Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authoriz= ation Server through the Client Registration Endpoint which is used by the = Client to authenticate itself during read, update, and delete operations. T= his token is associated with a particular Client.
 
If this can be clarified, I welcome text suggestions.
 
The latter part of 1.2 didn't seem like terminology but rather architecture= or part of the introduction that describes what the spec does. The third p= oint doesn't seem to fit with the other two except to say that the dynamic = registration endpoints use their own access tokens called registration access tokens.
 
Client Registration Endpoi=
nt: The OAuth 2.0 Endpoint through which
      a Client can request new registration=
.  The means of the Client
      obtaining the URL for this endpoint a=
re out of scope for this
      specification.
 
   o  Client Configuration Endpoint: The OAuth 2.0 En=
dpoint through
      which a specific Client can manage it=
s registration information,
      provided by the Authorization Server =
to the Client.  This URL for
      this endpoint is communicated to the =
client by the Authorization
      Server in the Client Information Resp=
onse.
 
   o  Registration Access Token: An OAuth 2.0 Bearer =
Token issued by the
      Authorization Server through the Clie=
nt Registration Endpoint
      which is used by the Client to authen=
ticate itself during read,
      update, and delete operations.  =
This token is associated with a
      particular Client.
 
This section is meant to just introduce the new terms that are then explain= ed in greater detail throughout the rest of the document. Yes, it's a bit a= rchitecture, but only in the sense that you need to define the terms that m= ake up your architecture. How would you suggest that it change?
 
Probably this is more a matter of style.  But, what happened for me is= I naturally skipped the terminology section, as I wasn't expecting protoco= l components to be there.  "terminology" is something I thin= k people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?
 
If we distinguish between first time registration of a particular client so= ftware package, it is possible that somethings like authentication method c= an be negotiate in or out-of-band at that time. Subsequent registrations sh= ould only have parameters for items that could change per deployment (like tos_uri).  I think token_endpo= int_auth_method is one thing that should not be negotiated per instance.
 
When subsequent instances register, I have to ask the question, for example= when would things like "token_endpoint_auth_method" be negotiate= d or be different for the same client software? Should not all instances us= e the same authentication method.
 
I'm confused by this -- as far as the dynamic registration spec is con= cerned, all instances are separate from each other. All parameters change p= er instance. And instance, you should keep in mind, is defined as any one c= opy of the client code connecting to any new authorization server. That pairing creates the client_id, and t= herefore the instance, and therefore the registration access token, and the= refore the registration itself at a conceptual level. So there is no way ot= her than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the A= S find out about it?
 
We still disagree on this. It is my assertion that clients should NEVE= R ask for a particular token auth method. Since it is the AS that is authen= ticating the client, then it is the AS's right to set the authentication po= licy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that durin= g the first time a piece of software is registered (the first instance), th= ere could be some OOB discussion by an administrator to approve the particu= lar authentication type for the AS in question.
 
I haven't heard a reason justifying this parameter other then "it= is needed".  Why?
 
The role of the dynamic registration protocol is twofold: half of that is t= he server informing the client what it must do. But the other half is the c= lient informing the server what it *can* do, or what it *wants* to do. = ;
 
And again, there's no way to distinguish a first instance from a subsequent= instance unless you're doing something in addition. Nothing is stopping th= e same application from registering a new instance of itself for every sing= le user or every single token that it wants to get access for. That's complicated and wasteful and not a grea= t idea, sure, but  there's no useful way to prevent that kind of behav= ior if you also want open registration of clients. 
 
I think we've discussed how recognizing subsequent instances is easily done= .
 
As I mentioned in the other thread, if a developer chooses to limit the cap= abilities of the client it must do so by looking to the developer or standa= rd behind the API.  Otherwise they are taking the chance.  There'= s no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect = in the absence of an API standard dictating what should be supported, the d= eveloper will have to implement all methods.
 
My point here is that none of this is helped by the client app saying what = it supports. A developer who takes the route of limiting implementation tak= es the chance that the server will not accept.  So why negotiate withi= n registration?
 
And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will probably= ask for the same token_endpoint_auth_method from all auth servers they tal= k to, right? And each AS will tell each instance that registers with it to use a particular auth method. Ther= e is no way to tie together different instances across (or within) auth ser= vers without specifying a significant amount of other machinery.
 

Which is not to say that it's not useful in some cir= cumstances to tie together different instances of the same code across (or = within) auth servers. This is why, with Blue Button+, we specified a sp= ecific token format for the initial access token that the clients use to call the registration endpoint the first tim= e,  as well as a discovery protocol against a centralized server that = handles pre-registration. All of this machinery is, in my opinion, a stupen= dous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing= to abstract out and make its own spec that extends the Dyn Reg spec in a f= ully compatible way. Furthermore, even in Blue Button+ we specify that = all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says= "hey, here are my parameters." The auth server has no way to kno= w in this case any kind of out-of-band negotiation for different things. In= BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these di= fferent cases. But again, all of this is specific to the BB+ use case, = and I don't see value in dragging it in to the registration spec on its own= . I believe it would be far too limiting.

 
See my previous comments on differentiating client inst= ances being out of scope without rechartering to do this new work and on wh= at the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued= to the party registering the client, enabling it to subsequently retrieve = information about the client registration and to potentially update the reg= istration information for that registered client.  Again, I=92ll work with Justin to make sure that this is as = clear as possible in the specification.
 
Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?
 
That's an individual submission, not a working group draft. Nobody has= , until now, even mentioned the use of ETags here. UMA (where the resource = registration draft comes from) uses ETags, hence their inclusion there. I p= ersonally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this l= ate.
 
Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't h= ave a point. It's worth discussing. 
 
One could argue that the point of an ETag is that it is useful for change d= etection when there are multiple writers to a particular resource.  In= the design of dynamic registration endpoint, there should only be one writ= er -- the client. This is an important observation.
 
There are other mechanisms that handle this -- namely, the registration acc= ess token and the client_id. Many instances include the client_id in some f= orm in the client configuration endpoint's URL for sanity checking, as desc= ribed in =A74.1. 
 
If everyone agrees, I'm in agreement. But it will likely mean changes for t= he resource reg draft if adopted.<= /span>
 
ETags seem like an unnecessary addition (and potential compl= ication) to the specification.  It=92s already working fine as-is.
 
Specific items:
---------------------
"token_endpoint_auth_method"
 
There is some confusion as to whether this applies to server or client auth= entication.  Suggest renaming parameter to "token_endpoint_client= _auth_method"
 
This is the first I've heard of this particular confusion. I'm fine wi= th either name but at this stage I don't want to make syntax changes withou= t very, very compelling reasons to do so.
 
The question was raised to me by some new developers. It seems obvious= to us as experienced OAuth persons, but to new developers it seems unclear= .  Also, now that you are introducing registration authentication, the= whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That sa= id, I wouldn't mind shorter names (maybe not quite as short as the JOSE stu= ff ;-)
 
Fair enough, but again, I only want to do syntax changes if the rest of the= WG *really* wants to.
 
I agree with Justin here.  I=92m fine clarifying the de= scription of this parameter to resolve the potential ambiguities that you c= ite, Phil.  I=92m not OK revising the syntax without a compelling reason to do so.
 
* Currently, the API only supports a single value instead of an array. &nbs= p;If the purpose is to allow the client to know what auth methods it suppor= ts, this should be an array indicated what methods the client supports - or= it should not be used.
 
I would rather like this to be an array, personally, and brought it up= with the OpenID Connect working group about six months ago. But there it w= as decided that a single value was simpler and sufficient for the purpose. = The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this= very issue in the WG here but didn't receive any traction on it, so single= it remains.
 
I can get behind multiple values. In this case, it changes the meaning of t= he parameter. Instead of the client forcing the server to use a particular = method, the client is informing the server about what methods it can perfor= m. This allows the server to assign the appropriate method based on its own policy.

Also note that this field, like all others in =A72, represents two thi= ngs: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you = have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last= word anyway. But at least this dictator is nice enough to tell you what th= eir decision was instead of just decapitating you.
 
This is the heart of my objection. This fuzziness is is going to lead to in= terop issues.
 
There is no fuzziness that I can see here. It's parallelism between what go= es in to the endpoint and what comes out of it. The semantics for the reque= st and the response are different, and differentiable by the fact that one = is a request and the other is a response. 
 
The inter-op issue I would like to point out is that the spec does not curr= ently specify if particular input values are singular or multiple.  If= an implementer assumes singular and clients assume multiple, we have issue= s.
 
The multiple/single discussion above gets to the heart of wh= at I *do* believe is a deficiency in the specification, as it=92s cu= rrently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorizatio= n Server functionality is out of scope for this specification.  I stro= ngly believe that we need to add a clear statement to this effect in the in= troduction to the specification.
 
The purpose of the Dynamic Client Registration specification= is for the client to register with the Authorization Server and to inform = it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose = of this specification for it to be used by clients in any manner to discove= r features of the Authorization Server.  That should be explicitly out= of scope.
 
Currently, clients are instructed by RFC 6749 to discover in= formation about Authorization Servers they interact with by consulting the = =93service documentation=94 (RFC 6749, Sections 3.1 and 3.2).&n= bsp; They can also learn information about Authorization Servers in specifi= c contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/spec= s/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).
 
I suspect that at some point, someone in the OAuth working g= roup will propose developing a generic OAuth discovery mechanism, which wil= l lead to a rechartering to include this work in the working group=92s set of deliverables.  I would supp= ort doing this work and the necessary rechartering to do so.
 
That being said, I strongly oppose trying to shoehorn piecem= eal aspects of discovery into the Dynamic Client Registration specification= .  It is distinct functionality and deserves first-class and separable treatment by the working group.  D= iscovery is for potential clients to learn properties of the AS before regi= stration.  Registration is for potential clients to inform the AS of i= ts properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration= sends information about the Client to the AS.  That=92s a clean separ= ation.  We should strongly resist muddying the two functions.
 
OAuth 2.0 is a success because it didn=92t try to boil the o= cean.  It specified how to do one thing well in a simple, web-friendly= manner.  We should do the same =96 focusing on specifying interoperable dynamic client registration, while making it c= lear that this is distinct from discovery about Authorization Server proper= ties, and making it clear that discovery is out of scope for this work.
 
I apologize at this point on behalf of myself and the other = spec editors for not being 100% clear that discovery functionality is expli= citly out of scope for Dynamic Client Registration.  If we had done so, I=92m sure that many of the current= questions and confusions would not have arisen.  I think we=92d assum= ed that this was obvious, but from the current discussions, it=92s apparent= that it=92s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential = point of confusion.
 
Getting back to the specifics, the only useful purpose of a = multi-valued =93token_endpoint_client_auth_method=94 member would be to enable the client to discover information about the aut= hentication methods supported by the AS after the registration had been per= formed.  But that is a discovery function, and so should be part of th= e discovery work =96 not this specification.  We should resist shoehorning in bits of discovery into this specification.=   It *is* a worthwhile topic, but deserves full consideration b= y the working group in its own right.  Therefore, this member must rem= ain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authen= tication method it will use.  Anything else would be scope creep, and = result in an unnecessarily complicated specification and unnecessarily comp= licated clients.
 
* There is no authn method for "client_secret_saml" or "priv= ate_key_saml".
 
Nobody has really asked that these two be included or specified. The e= xtension mechanism (using an absolute URI) would allow someone else to defi= ne these. Is the definition in the SAML Assertion draft sufficient for thei= r use?
 
I think this is coming from the fact that there is a JWT bearer draft and a= SAML bearer draft.  The truth is you are defining an authentication t= hat isn't even defined.
 
There are no profiles referenced or defined for "client_secret_jwt&= quot; or "private_key_jwt". Neither of the JWT or SAML Bearer dra= fts referenced cover these types of flows. They only cover bearer flows. &n= bsp;"client_secret_jwt" and "private_key_jwt" seem to h= ave some meaning within OpenID Connect, but I note that OIDC does not fully de= fine these either.
 
The JWT assertion draft does say how to use a JWT for client authentication= , and the DynReg text differentiates between a client signing said JWT with= its own secret symmetrically vs. a client using its own private key, asymm= etrically.
 
Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token.  The assumption is that if a client has the assertion = it has the right to present it.  IOW. The JWT Bearer Draft is most def= initively not a JWT HoK Draft.  :-)
 
Regardless, you are introducing a new profile which is undefined.
 
I think I see the point that you're making now, let me try to re-state it:<= /div>
 
While the basics of "how to present a JWT as a client credential"= is defined here: http://tools.ietf.org/id/draft-= ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signat= ure secret source, the audience claim, and other things that the AS would n= eed to check and validate. Right? The dynamic registration draft can define= those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clari= ty).
 
I'd be OK with adding the SAML bit, going into greater detail on the JWT bi= ts, or dropping the JWT bits, if the WG wants to do any of those actions. M= y objection is that the JWT stuff is already in use and functioning and it'= d be a shame to leave it out.
 
I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made= is they assumed everyone had the same definition of bearer token.  To= me a bearer token opaque to the client. It therefore cannot do any signatu= re work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and t= he token issuer, but when the client wields the token, it is handling an op= aque string.
 
The concept of client_secret_jwt suggests an HoK profile.  Therefore o= f course the bearer drafts are a little underspecified when it comes to HoK= profiles.
 
So for example, you need a draft like the MAC draft for this. 
 
I'm having trouble overall here. It seems the authn types suggest ONLY stro= ng authentication for clients, yet during the registration process the curr= ent draft isn't able to correlate multiple instances of the same software (= even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth= ?
 
There is no authentication method defined for "client_bearer_saml"= ; or "client_bearer_jwt" or "client_bearer_ref".  = Since the bearer specs say this is acceptable,  the dynamic registrati= on spec should accept these.
 
I don't understand this bit -- where are these defined in RFC6750? I don't = even know what client_bearer_ref would refer to.
 
6750 says you can use a bearer assertion (e.g. obtained from an IDP) a= nd wield it as an authentication assertion.  The client is NOT creatin= g or modifying the assertion. The client is simply passing one it previousl= y obtained.
 
What you are describing is not bearer. It is holder of key. Very very = different. 

A possible suggestion is to remove client_secret_jwt and private_key_jwt an= d define those as register extensions since these profiles are not defined.=
 
That's possible, but they are in active use already. 
 
That may be true. But then you need to write another draft so the rest= of us can implement it in an interoperable way.  Me I prefer not to g= uess what you are doing.
 
This much I agree with.
 
Justin, John, and I discussed this issue and agree with your= suggestion, Phil.  Since they are not completely specified, we will r= emove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification = that do fully specify these and other token endpoint authentication methods= , including potential methods using SAML assertions, to register them in th= e registry, rather than trying to bake them into the Dynamic Client Registration specification.
 
About "tos_uri" and "policy_uri"
 
The distinction between tos_uri and policy_uri is unclear.  Can we cla= rify or combine them?
 
Terms of service and policy are two different documents. One is something t= hat a user accepts (generally describing what the user will do), one is a s= tatement of what the service provider (in this case, the client) will do. M= ore importantly, we used to have only one, and several people asked for them to be split.
 
Several developers were confused by this. In particular they couldn't = figure out which was used for what.  Just passing along the feedback.<= /div>
 
OK, the distinction that I see is that the TOS is contractual, the Policy i= s a statement. Re-reading the definitions in there right now, that can be m= ade much clearer. (It even looks like some OIDC text leaked into the defini= tion of policy_uri and that hadn't been caught yet.)
 
I support clarifying the language on these definitions, and = will work with Justin to do so.
 
Also, aren't these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is apparently= trying to deprecate URL in favor of URI in new specs. So in practice they'= ll nearly always be URLs, but since all URLs are URIs we're not technically= incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.
 
Arg. Nice.  Then the text should say the value passed must resolv= e to a valid web page, document, whatever.
 
That's fair, and it's something that the AS can even check if it wants to.<= /div>
 
Agreed on this clarification.
 
About "jwks_uri"
 
A normative reference for http://tools.ietf.org/html/draft-= ietf-jose-json-web-key-09 is needed. 
 
Yes, you're correct, I'll add that.
 
Should be URL instead of URI?
 
See above. :)
 
Agreed on adding this reference.
 
Section 2.1
 
In the table urn:ietf:params:oauth:grant= -type:jwt-bearer
is missing.
 
It's there in the copy of -10 I'm reading off of = ietf.org right now =85 ?
'
Sorry I meant: urn:ietf:pa= rams:oauth:grant-type:saml-bearer
 
Ah, that makes more sense. If the WG wants to add in SAML support to parall= el the JWT support, I'd be OK with that.
 
=93As such, a server supporting these fields SHOULD take steps to= ensure that a client cannot register itself into an inconsistent state.=94=

We may want to define more detailed HTTP error response. E.g. 400 stat= us code + defined error code (=93invalid_client_metadata=94)?
 
I'd be fine with defining a more explicit error state in this case. I think= it would help interop for the servers that want to enforce grant-type and = response-type restrictions, but servers that can't or don't care about rest= ricting grants types and whatnot don't have to do anything special.
 
I *think* that this goes away with the deletion of cl= ient_secret_jwt and private_key_jwt in favor of the registry=85  I=92l= l do a consistency check and verify that when the spec is updated accordingly.
 
Section 2.2
 
May want to add:
 
When =93#=94 language tag is missing, (e.g. =93#en=94 is mi= ssing in =93client_name=94, instead of =93client_name#en=94) the OAuth= server may use interpret the language used based on server confi= guration or heuristics.
 
That seems inconsistent with what we already have:
 
If any human-readable field is sent without a language tag, parties us= ing it MUST NOT make any assumptions about the language, character set, or = script of the string value, and the string value MUST be used as-is whereve= r it is presented in a user interface.
 
Which is to say, treat it as a raw byte-value-string and don't try to get f= ancy.
 
I will discuss with our developers. I'm not sure the as-is works. &nbs= p;
 
Is it the intent that when the client has localized "client_name&= quot; for example, it should pass all language variations in a JSON array?<= /div>
 
Or, should part of the registration be to indicate which interface lan= guage the client wishes to use?  Then it only passes a single value fo= r that registration?
 
 
No, the client should pass parameters as multiple separate values. Connect = has this in its example:
 
   "client_name": "My Exampl=
e",
   "client_name#ja-Jpan-JP":

     "クライアン|=
88;名",





Should we add that to at least one of the examples in DynReg? (The language=
 tags are a late addition, so the examples don't reflect it.)
 
An example would definitely help.
If the client passes only a single unadorned field, the AS can't make any a= ssumption about what language it is. Think of this as the internationalized= value of the field while the language tags are the localized versions of t= he field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of a= nything more specific, the AS can at least do *something* with it.
 
Passing in a "default" language field (like default_locale or the= like) is only going to lead to pain for implementors of both clients and s= ervers, and it's going to hurt the interoperability of the human-readable f= ields. 
 
I think what I meant is since you are allowing each client to register diff= erent things, AND the client likely already knows the user's preferred lang= uage, why wouldn't the client just pass text values in one language and ano= ther parameter indicating preferred language in the case of any service generated text.
 
Is the reason you are passing multiple localizations is so that you can use= the preferred language of the resource owner rather then the client user? = I wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app expect?
 
----> any multi-lingual people have any opinions here?
 
Without specific proposed text changes to review, it=92s har= d to know what to think about this comment.  Unless a specific propose= d text change is sent to the list with clear rationale for why it=92s better than what=92s there now and reviewed by th= e working group, I don=92t believe we should change the specification in re= sponse to this comment.
 
Section 3
 
Existing text:

=93In order to support open registration and facilitate wider in= teroperability, the Client Registration Endpoint SHOULD allow ini= tial registration requests with no authentication.  The= se requests MAY be rate-limited or otherwise limited to prevent a deni= al-of-service attack on the Client Registration Endpoint.=94

I would suggest to change the first =93SHOULD=94 to =93MAY=94.   = In most cloud services, the first client is registered by a human user= . Then, other clients can be further used to automate other clien= t registration.  So, the first request would typically come = with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I bel= ieve that turning off open registration at the AS (which is what this is ta= lking about) really ought to be the exception rather than the rule. 
 
I think you are reading it wrong -- a double-negative issue. The end o= f the sentence is "no authentication".  You are implying tha= t NO Authentication us what should normally be done. I think you intend ano= nymous authentication to be the exception rather than the rule don't you?
 
No, I think that anonymous authentication should be the rule. Open registra= tion should be default. 
 
I disagree.  Again,  the spec seems contradictory. It sugges= ts strong client auth methods and at the same time anonymous registration. =  Yes you gain uniqueness, but that's about it.

On the flip side, the earlier paragraph:

=93The Client Registration Endpoint MAY accept an initial a= uthorization credential in the form of an OAuth 2.0 [RFC6749] access t= oken 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 thi= s specification.=94

I tend to think it would be better to change this =93MAY=94 to =93SHOULD=94= .

That access token would carry a human user authenticated identity some= how. In some cases, it can be a pure authenticated user assertion toke= n.
 
Again, disagree, for the same reasoning as above.
 
Same reasoning. 

I agree with Justin here.  The default should be that o= pen registrations are enabled.  The exception case is that specific pe= rmissions are required to perform dynamic client registration.

About section 4.3:
 
If the client does not exist on this server, the server MUST respond=

   with HTTP 401 Unauthorized, and the Registration Access=
 Token used to
   make this request SHOULD be immediately revoked.=
 
If the Client does not exist on this server, shouldn't it return = a "404 Not Found"?

If revoking the registration access token, is it bound to a single client r= egistration?  This is not clear.  What is the lifecycle around re= gistration access token? Only hint is in the Client Information Response in= section 5.1.
 
The language about the 401 here (and in other nearby sections) is spec= ifically so that you treat a missing client and a bad registration access t= oken the same way. You see, returning a 404 here actually indicates th= ings were in an inconsistent state. Namely, that the registration access token was still valid but the client that the= registration access token was attached to doesn't exist anymore. The regis= tration access token in meant to be tied to a client's instance (or registr= ation), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at = least some implementations (specifically ours at MITRE that's built on SECO= AUTH in Java), you'd never be able to reach the 404 state due to consistenc= y checking with the inbound token.
 
Since the intent of the registration access token is that it's bound t= o a single instance, its lifecycle is generally tied to the lifecycle begin= s at the issuance of a new client_id with that instance. That token might b= e revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the cli= ent needs to be prepared for that -- same as the client_secret), and it wil= l be revoked when the client is deleted either with a Delete call to the Cl= ient Configuration Endpoint or something happening out-of-band to kill the client. 
 
Should we add more explanatory text to the definition in the terminolo= gy section? Elsewhere? I'm very open to concrete suggestions with this, sin= ce I don't think it's as clear as we'd like.
 
I think we should look at it.

For security reasons, it=92s generally not good to distingui= sh between =93not found=94 and =93unauthorized=94 errors in responses, as t= hat can provide the attacker an oracle to probe whether a particular entity exists  I don=92t think a change is calle= d for here.

About section 5.1:
Is registration_access_token unique?  Or is it shared by multiple= instances?   If shared, then registration_access_token can't be revok= ed on delete of client.
 
The registration_access_token is unique to a registered= client, in the RFC 6749 sense of =93client=94.  Again, if we want to = do work on =93client instances=94, we need to recharter and take this distinct work item up explicitly.

Suggest rename =93expires_at=94 to =93client_secret_expires_at=94, 
Suggest to rename =93issued_at=94 to =93id_issued_at=94
 
While I do like the suggestion of changing these to client_secret_expi= res_at and client_id_issued_at, and I think these are more clear and readab= le,


I don't want to change the syntax during last call unless there is a c= lear need and a clear consensus for doing so.
 
That's why we are having last call. To confirm consensus on the draft. = ;
 
Same reasoning as earlier. You now have multiple tokens (registration acces= s and client) in play. The spec needs to be clear which one it is talking a= bout.
 
I'm fine with the suggested change but I would like more feedback from othe= r people before moving forward with it. There's a lot of value in "jus= t pick a name and ship it" as well though, and I don't want to devolve= into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate= on names.)
 
Again, this was a problem raised by people new to the specification. They f= ound it confusing. I tend to agree. We're not talking about what colour to = paint the shed. We're talking about whether the bike shed is a house. =  :-) 
 
I'm not too fussed about whether you call it "cl_sec_expiry" or &= quot;client_secret_expires_at". 

If the definitions of =93expires_at=94 or =93issued_at=94 ar= e unclear, we should clarify them.  If you believe that this is the ca= se Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point = we should stick with the existing protocol element names unless overwhelmin= g working group sentiment emerges to change them.  They are already wo= rking fine as-is in production deployments.
 
Section 7
 
When a client_secret expires is it the intent that clients do an updat= e or refresh to get a new client secret?
 
Yes, the client is supposed to either call the read or update methods on th= e client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome suggestions o= n how to clarify this.
 
Either is a reasonable behavior on the behalf of clients, de= pending upon context.  I support adding text to clarify this.
 
Again, thanks for the very thorough read through. Have you implemented= any of the spec yet, either as-is or with any of your suggested changes?
 
Yes. Much of the feedback is coming from our development community. 
 
Ah, very cool. Developer experience is the most valuable feedback, in my op= inion. If you can't actually build the blasted thing, what good is it? :)
 
Glad to hear that you=92re working with developers building = the spec.  Please thank them for the feedback.
 
 -- Justin
 
          =             &nb= sp;            =             &nb= sp;            Best = wishes,
          =             &nb= sp;            =             &nb= sp;            -- Mi= ke




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

--_000_4E1F6AAD24975D4BA5B168042967394367749249TK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Tue May 21 13:28:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8748811E80D2 for ; Tue, 21 May 2013 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHNbpQdPQCU2 for ; Tue, 21 May 2013 13:28:29 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BF50311E80DE for ; Tue, 21 May 2013 13:28:28 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so3031981iec.20 for ; Tue, 21 May 2013 13:28:27 -0700 (PDT) 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=mbcNnusMAAIGJICNHeaGKjzKCft1YpKyxXMuavfHGiA=; b=VdpQOrdiSxKp77tUVxSGVMLw7VhZ6fLiKht07kkAQyjqQ/CgsABTpGHcZ5mdfygEcw JbXeQd1Z/r+7lmHsyUgdi3akedPE53jOcIKqy7sD9+lrUMHZL3H0obklN5dt+p+lSnrl YSJaMRq3bIDvPpm7YKxiJhC0Oqi8ZUhfxAZkbBXR5aH0nP7yUpq49T4OTbQP6o65zzA6 jU4aqxyfws6QTmbstBc5OuyXsDv2PNxlHsll9zaeY6YlPp9/6RBieGCO9szrjZaS/bSb 29/rvSIOTFdffvEwwF2Trfhfck2x4IQhBH+DO6jL4c9Camg3nyVZI4C39S1uY0syG5jB eY+w== X-Received: by 10.50.119.67 with SMTP id ks3mr2294562igb.90.1369168107440; Tue, 21 May 2013 13:28:27 -0700 (PDT) Received: from [192.168.1.36] (190-20-39-239.baf.movistar.cl. [190.20.39.239]) by mx.google.com with ESMTPSA id r20sm3876836ign.8.2013.05.21.13.28.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 13:28:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1FFBF6C9-44B0-446A-B140-9D8094FAFC0C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367749249@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 21 May 2013 16:28:11 -0400 Message-Id: References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org>, <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com>, <4E1F6AAD24975D4BA5B168042967394367749249@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmq1cM/ybZwOmB2GpWFqfbiuSzYNjWejFAX+vgGxl3caZVjPrIu5gBwv+nVMBQGAqAMehWK Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2013 20:28:36 -0000 --Apple-Mail=_1FFBF6C9-44B0-446A-B140-9D8094FAFC0C Content-Type: multipart/alternative; boundary="Apple-Mail=_50DF9D20-A207-4738-835C-C950A07ECF19" --Apple-Mail=_50DF9D20-A207-4738-835C-C950A07ECF19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Mike, I don't think we are loosing anything, only gaining. I think it is a false statement to say that having multiple client = instances with the same client_id and secret is a feature. In reality with public clients or public clients masquerading as private = ones the only real way for the AS to tell them apart in OAuth is by = redirect_uri. We are not changing that, though we are perhaps making it = cleaner that client_id for public clients can't be relied upon in any = way. Previously we had what was more or less assumed to be a one to = one mapping of client_id to redirect for native clients. Once we start assigning unique client_id to instances of clients that = are all going to be using the same redirect_uri there are a lot of = question a AS has to decide, such as can two client_id register the same = redirect_uri? That could well cause all sorts of race conditions on the = device if you have two apps fighting over the same custom scheme. So I think in reality the piece of information that a registration = server that is going to need to look at is the custom url scheme for = apps, probably disallowing multiple anonymous registrations for the = same custom scheme. =20 Getting into the details of how app stores allocate schemes to = developers etc is out of scope for this spec. Someone can build = something more sophisticated on top of dynamic registration, but there = are a lot of issues outside of the simple how is a client registering = for a client_id and secret without forcing a manual step through a web = portal. I honestly don't think adding some new application identifier solves the = problem. That information is in the redirect_uri for native apps, and = the problem doesn't exist for web server clients. John B. On 2013-05-21, at 2:28 PM, Mike Jones = wrote: > What is the loss of information that you=E2=80=99re concerned about? = It seems odd to me that you=E2=80=99re asserting that there's = information loss when the operations performed by Dynamic Client = Registration are equivalent to those that are performed by out-of-band = OAuth developer portals today. It=E2=80=99s just automating a formerly = manual process. > =20 > -- Mike > =20 > =20 > From: Phil Hunt > Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E21=E2=80= =8E, =E2=80=8E2013 =E2=80=8E11=E2=80=8E:=E2=80=8E20=E2=80=8E =E2=80=8EAM > To: Mike Jones > Cc: Justin P. Richer, oauth@ietf.org WG > =20 > Mike, >=20 > There is an operational loss of information in the dynamic = registration spec. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com > On 2013-05-21, at 10:52 AM, Mike Jones wrote: >=20 > No information is being thrown away. Developers can use dynamic = registration to obtain a client_id and then have all the client = instances use that client_id if they choose - just like they can do when = doing out-of-band registration with a site=E2=80=99s developer portal. = The only difference is that they don=E2=80=99t have to do out-of-band = registration anymore! > =20 > -- Mike > =20 > =20 > From: Phil Hunt > Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E21=E2=80= =8E, =E2=80=8E2013 =E2=80=8E8=E2=80=8E:=E2=80=8E02=E2=80=8E =E2=80=8EAM > To: Justin Richer > Cc: oauth@ietf.org WG > =20 > Regarding charter.=20 >=20 > The charter is a one-liner. To say associating clients is not in the = charter while saying every other 'new' thing that is in the spec (eg = client auth type) is in is laughable. After all the entire draft is new = functionality.=20 >=20 > The item i have asked for is not new. It preserves information that = was available without reg. Namely a way to recognize multiple clients as = a common public client as in 6749 they share a client_id. The draft = throws this information away preventing security admins from making any = judgements since all clients are now anonymized. >=20 > Where in the charter does it say you can anonymize the clients?=20 >=20 > Phil >=20 > On 2013-05-21, at 6:46, Justin Richer wrote: >=20 >=20 > On 05/21/2013 02:01 AM, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2013-05-20, at 8:35, Justin Richer wrote: >=20 >=20 > On 05/17/2013 05:27 PM, Phil Hunt wrote: > Mike, >=20 > Rather then embed comments in an extended thread, I'd like to open up = a specific discussion on the objective of dyn reg. >=20 > I see limited to no value in having clients completely anonymously = registering and receiving tokens without any ability to correlate = applications between applications.=20 >=20 > I think that herein lies a very big disconnect in assumptions. I see a = huge benefit in anonymously registered clients getting tokens because = there is an end-user in the loop during the authorization phase (long = after registration has happened). The arity of registrations to = authorizations approaches 1:1 in these cases, and I'm just fine with = that.=20 > Then what you describe is NOT anonymous but rather a profile not = covered by the spec as there is no discussion of user authenticated = registration. Implicitly or explicitly.=20 >=20 > [JR] I think you misunderstand what I said, let me try to be more = explicit: the user is not authenticating the registration. The user is = not involved in the registration. The user might not even know that a = registration happened. The registration is (normally) completely = anonymous and open, the client just shows up and says "Hi, I'm a = client!".=20 >=20 > The "authorization" that I mentioned happens later and is a normal = OAuth authorization, which has a user involved like usual. The = authorization step in OAuth depends on *some* kind of registration = happening beforehand, dynamic or otherwise. This is all perfectly within = the model of OAuth.=20 >=20 >=20 > =46rom the RFC6749 perspective, a "client" is not a particular piece = of code, it is a particular copy of a piece of code with a particular = client_id from the vantage point of a particular authorization server. > actually, i disagree. This spec fundamentally breaks the old = definition and behavior from 6749. In the old way every instance of = software shared a client_id. In this draft, u throw that away without = preserving the information. This is BAD! > [JR] No, we're not throwing that away at all. The concept is the same, = but when you add new functionality, the mechanics change a bit. A = "client_id" was always pairwise between a client and an AS. If a client = had to talk to two AS's before, it would have two client_ids. That's = still the case. If there were multiple copies of a confidential client, = you need to get a client_id and client_secret to each copy. That's still = the case. What's different is that we've made it *easier* for a = particular piece of code to get different client_ids when it's talking = to the same or a different auth server, at runtime. When you have to = manually register every client, you're going to just do it once. If you = can do it dynamically, you have more options.=20 >=20 > Note that you can *still* have a public client with a known client_id = if you want to. You don't even need to use dynamic registration for = that. Heck, you don't need to use dynamic registration for any kind of = client if you don't want to, since most services will probably still = offer manual registration through some portal kind of page. >=20 >=20 >=20 > A "client" is, conceptually, a pairwise association between two = running codebases. When you have a particular piece of code talking only = to one auth server and being manually configured at said auth server = with its client_id, this is fairly clear and straightforward and the = arity is simple. Things get a bit muddy when you introduce dynamic = registration, which is why I think that we need to have introductory = text about this. Specifically: >=20 > - a particular piece of code can be run on multiple devices and talk = to the same auth server, each copy of that code getting its own = client_id.=20 > - a particular copy of a particular piece of code can now be expected = to talk to multiple auth servers, each auth server giving the piece of = code its own client_id.=20 >=20 > Both of these are cases of what defines an "instance" in most people's = heads, even though it's the same software, even sometimes the same = running copy of the same software. But as far as RFC6749's definition of = "client" is concerned, these are all completely separate "client"s with = no way to tie them together out of the box. And that's fine. >=20 >=20 > Associating client_id's with known client applications to allow admins = to know who is running what version of clients seems to be the most = fundamental part of the reason for dynamic reg. How can you revoke = access to particular client app types? As Justin already talked about = in his Blue Button+ scenario, there are often life and death situations = where particular sets of clients need to be revoked. =20 > While it's very useful, I wouldn't (and haven't) classified it quite = like that. Nor would I say that the BB+ profile is a complete solution = -- our Registry component does not actually push revocation = notifications down to Providers (yet), so it's more like invalidating a = root certificate and waiting for caches to time out for things to = cascade. We've been talking about adding some form of callback to = providers, but we don't want to boil that particular ocean right now. = However, the BB+ profile makes use of a well-specified discovery and = Registry set up, as well as data conveyed in structured, signed tokens = (JWTs) at different points in the process. >=20 >=20 > Or put another way. I believe this will be a critical operational = requirement going forwards. If the spec is published as is, it will be = quickly invalidated by one that does at least partially address the = problem. > That's not true at all. BB+ addresses this scenario and still uses the = Dynamic Registration spec as-is. I would encourage folks to read what = we're doing, a work-in-progress found here: > but you are breaking other things and overloading client cred etc = to pass in signed data. I don't want a hack for a solution. I want = interop.=20 > [JR] I'm curious, what exactly are we breaking? If anything in BB+ = breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we = need to fix there. It is our intent to be fully compatible with OAuth = Dyn Reg, and we are even explicitly calling for open registration as = mandatory to implement for authorization servers within BB+, even though = we have additional mechanisms as well for what we're calling "trusted = registrations". For those trusted registrations, we're not using the = client *credentials* to pass in signed data, we're using the initial = *registration authentication* mechanism (which is to say, an OAuth = token) for its intended purpose: authorizing the holder of this token = access to the registration endpoint. In BB+, we're profiling exactly = what that means. To wit, we define the content of the token (which is = fully compatible with DynReg which doesn't care what's in the token) and = how the AS can verify it (which DynReg doesn't care how it happens) and = we've added some additional rules and policies that allow us to tie = together instances of the client across the distributed network.=20 >=20 > So why doesn't DynReg adopt this mechanism? Two reasons: it adds a = huge amount of very specific machinery (signed tokens with known formats = and fields, a Registry with manual pre-registration, a three-tiered = discovery service with information about clients and service providers = rooted at the Registry, trust frameworks and network enforcement = policies that all players have to agree to before playing, etc.), and = it's not really doing just registration anymore. In BB+, we needed the = Registry and Discovery services to do other functions as well apart from = just registration, and so it makes sense to re-use them.=20 >=20 > If there were a simple solution that didn't leave security holes the = size of a small army, I'd be glad to bring it to the table. But I am = convinced that a good solution for managing client instances across a = network requires a lot more thought and consideration, and I believe = that having a fully specified discovery service will help this case, = like it has helped in BB+. But I think that it's a complex enough = problem that it needs its own set of considerations. With DynReg, we = need to leave things open for that work in the future, and I believe we = have, but we shouldn't kill the simple, general case for want of a = special case.=20 >=20 >=20 > http://blue-button.github.io/blue-button-plus-pull/ >=20 > Just because you make something better doesn't mean you throw = necessarily away everything you've done to date. >=20 >=20 > We're ahead of schedule, lets talk through the requirement. > I believe that the requirement of tying instances together is = explicitly out of scope for the dynamic registration protocol. I = intended to have text to that effect in the section I'm adding about the = client lifecycle. >=20 > where is this stated in charter? > [JR] The charter for the working states what's in scope, not what's = out of scope, correct? It has been my understanding of IETF process that = additional functionality needs to be considered separately. All the = charter says about registration is this: >=20 > And dynamic client registration will make > it easier to broadly deploy OAuth clients (performing services to > users). >=20 > And:=20 >=20 > Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for consideration as a Proposed Standard > There's nothing in there at all about tying together client instances. = I have not seen anything to convince me that management of client = instances across a deployed network of auth servers is a necessary part = of basic client registration. It sounds very likely to me that it *is* = required for your use case, but that doesn't make it required for = everybody's use case.=20 >=20 > There are other important pieces of functionality that the WG isn't = picking up right now (such as token chaining and token introspection) = that are absolutely necessary for my own use cases, but I think it makes = sense for those to be separate modules. >=20 >=20 >=20 > As I mentioned in my comments to the other thread. Let's say we agree = not do this now. Well, then the new draft that does solve it would = likely be 95% overlap. Thus I see this issue as within charter and = should be solved now rather then waiting for a V2 dyn reg in the next = charter. > Why wouldn't the new draft just be the extra 5%? I personally think = that it's a lot more than 5% once you have in all the assurance and = safety mechanisms in place to avoid self-asserted values causing race = conditions, and what not. >=20 > Two drafts to do registration is not the way to go. It implies = complexity where there should be none. There is no technical reason for = two drafts.=20 > [JR] There is a need when there's a special case that requires a large = amount of overhead to be done correctly, to allow the general case to = move forward and be used on its own (as it is being used today).=20 >=20 >=20 > -- Justin >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-17, at 1:08 PM, Mike Jones wrote: >=20 > Thanks for the detailed feedback, Phil. Sorry for the delayed = response =E2=80=93 I was pretty fully engaged at the European Identity = Conference (where OAuth 2.0 won the award for best new standard J). My = feedback on the points raised is inline in green=E2=80=A6 > =20 > (Perhaps if any of you reply to this thread, you could also choose a = distinct color for your inline replies, so that it will be easily = evident who said what. As it is, just the back-and-forth between Phil = and Justin is already very difficult to follow. Thanks.) > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, May 16, 2013 12:54 PM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Last call review of = draft-ietf-oauth-dyn-reg-10 > =20 > Justin, > =20 > Thanks for the discussion. More comments below... > =20 > BTW. I'm happy to contribute text. Just want to get to some rough = agreement first. For example, I think we need to have a away to = recognize two pieces of software as being the same (even if = self-asserted). Once defined, I can put together some intro text, etc. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote: > =20 > On May 15, 2013, at 10:30 PM, Phil Hunt > wrote: > =20 > On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote: > =20 > Phil, many thanks for the extremely thorough review! It is very useful = indeed.=20 > =20 > My comments and responses to each point are inline.=20 > =20 > On May 15, 2013, at 4:30 PM, Phil Hunt wrote: > =20 > It seems unfortunate that I have not gotten a chance to get into this = level of detail much earlier. But then, I guess that's what LC review is = for! My apologies for not getting many of these concerns to the WG much = earlier. > =20 > Overall =20 > ----------- > I think dynamic registration is a critical part of the OAuth framework = now that we are starting to consider how individual client applications = should operate when there is one or more deployments of a particular = resource API. We've moved from the simple use case of a single API = provider like Facebook or Flickr and moved on to standards based, open = source based, and commercial based deployments where there are multiple = service endpoints and many clients to manage. > =20 > The dynamic registration spec is actually dealing with a couple of = issues that I would like to see made more clear in early part of the = spec: > =20 > 1. How is a new client application recognized for the first time when = deployed against a particular SP endpoint? Should clients actually = assert an application_id UUID that never changes and possibly a version = id that does change with versions? > =20 > In the general case, why is any recognition required? If you're doing = things as part of a larger protocol ecosystem, like Blue Button+ or a = particular OpenID Connect provider, then you can define semantics for = tying together classes of clients (see below for more discussion on this = very point). But in general, a client is just going to show up as a new = instance to the AS and get issued a new, unique client_id, and that's = that.=20 > =20 > I think we have to define more clearly what an "instance" is. For me, = there are applications and there are instances of that application. It = is useful to understand that a client application represents a set of = code that should behave in a consistent way. It seems to me the first = time a new application shows up is very different from the subsequent = instances that register. For example, after the first registration, = subsequent instances don't need special review or approval to the same = degree. > =20 > But without other mechanisms to tie things together, there's no way = for an authorization server to know if any client instance is tied to = any other client instance. Therefore, from the perspective of an AS, the = first instance of an application (i.e., particular configuration of a = set of code) to register is no different to subsequent instances of that = same application. How were you envisioning an AS knowing the difference = between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere? > =20 > I do agree that a discussion of "instance vs. application" would be = helpful in clearing this up, I'll make a note to add text to that = effect. (We had to do something similar for BB+) > =20 > I think it is simple enough to at least add a self generated UUID for = the application ID. Though I would allow for cases where the = application ID is assigned when the client developer and the APIs owner = do a formal assignment of application IDs. > =20 > In a sense this is just a lower tech way of doing it than what you = described as the initial client credential in Blue Button+ where you = encoded extra claims into the initial app credential. > =20 > What the UUID does is link multiple instances of a client app together = as the same "thing" that should have similar heuristics/behaviours. = This is very useful if you want to be able to revoke access to a set of = clients identified by application id (or a version of that app). > =20 > While I=E2=80=99m sympathetic to the OAuth working group eventually = doing work on differentiating between instances of an OAuth client, = I=E2=80=99ll note that in RFC 6749 or RFC 6750 there is no such thing as = a client instance. There are only clients, which are identified by = client_id values. If we want to do work on client instances, we should = recharter to add this new work as a working group deliverable. We = should not try to shoehorn bits and pieces of it into the Dynamic = Registration spec, any more than we should have tried to shoehorn it = into RFC 6749 or RFC 6750. Oauth-dyn-reg is there to register clients = as defined in RFC 6749. It=E2=80=99s not the right place to extend what = an OAuth client is in new ways. > =20 > 2. How are client credentials managed. Are we assuming client = credentials have a limited lifetime or rotation policy? > =20 > The intent was that client_secret could be rotated, as indicated by = the expires_at member of the response. If a client's secret expires, it = calls the read operation on the Client Configuration Endpoint (=C2=A74.2) = to get its new client_secret. If this is unclear in the current text = (which I suspect it may be after multiple refactorings), then I welcome = suggestions and specific text as to how to make that clear.=20 > Something like this should be in the draft. > =20 > Should this be up in the introductory text, somewhere else, or have = its own section? > =20 > I'm starting to think credential management is a key part of the = draft. It may be worth introducing a specific section outling the = registration life-cycle, registration access token usage, and client = token usage and bootstrapping. > =20 > I think that adding a discussion on this would be fine, as it could = help developers understand the workflow of registering, using, and = updating registered clients. > =20 > How does a client authenticate the first time and subsequent times to = the registration service? > =20 > This is a separate question all together, as it does not involve the = client_secret or client_id at all. Rather, the first time the client = shows up to the registration service, it may either: > - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do this) > - Authenticate using an OAuth 2.0 token (which ATM means a bearer = token). How the client gets that bearer token and what the bearer token = means to the AS beyond "this client is authorized to register" is out of = scope for the spec, by design. > =20 > Subsequent times that the same registered client (by which we mean the = same instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance. > =20 > Something like this should be in the draft. > =20 > OK, the definition of the registration access token can be expanded, = but I think that the rest of it is already in there in =C2=A73. I'd = welcome suggestions on which bits of this could be made clearer. > =20 > See the discussion on what the registration_access_token is in the = thread =E2=80=9CClient Credential Expiry and new Registration Access = Token - draft-ietf-oauth-dyn-reg-10=E2=80=9D. I will work with Justin = to apply these clarifications to the specification. This may go into = the proposed credential management overview section discussed above. > =20 > 3. How is versioning of clients managed? Should each new version of a = client require a change in client registration including possibly = changing client_id and authentication credential? I don't have a strong = feeling, but it is something that implementors should consider. > =20 > This is up to the AS, really, and I don't think that any global policy = would ever fly here. Especially if you consider that the entire notion = of "version" is more fluid these days than it ever has been. I wouldn't = mind adding a discussion in the security considerations if it merits = mentioning though, so that we can help both client developers and server = developers institute reasonably good policy. > =20 > I guess the issue is that when a client upgrades it may have access to = the old credentials. What is the intent then of registration. Since you = have an update are clients expected to update /re-register or not? I'm = not sure this is a security consideration but more part of the whole = change management function dynamic registration supports. > =20 > If your upgraded version of the client still has access to its old = credentials, why wouldn't it just use those? I don't see a reason for = forcing a re-registration. Nor do I see any way that an AS would even be = able to tell that a client had been upgraded. An upgraded client always = has the *option* of re-registering itself and getting a new client_id.=20= > I think the concern here is that rotation of client credential is not = something discussed before. Before we put it in the spec we should = consider the reasons for doing it and what problems it solves. > =20 > I think this may be just a case of letting people exchange credentials = for whatever reason they feel is appropriate. The version upgrade thing = suggests that when a client is upgraded it should go to the registration = server to "re-register". Depending on the policy of the server, it may = (or may not) receive a new client_id and/or new credential. =20 > =20 > One of the best benefits I can think of is if you discover a version = of a client has a problem, being able to select a group of clients by = software and version is important. Thus if client_id doesn't trace to a = particular software and version, that makes it hard to do. I think you = talked about this as an issue for Blue Button+ > =20 > Again, RFC 6749 defines no client instances or groups of clients, = therefore I believe that it=E2=80=99s inappropriate to do so here. We = don=E2=80=99t need to boil the ocean. If a new charter item is approved = to do work on client instances and protocol elements to use and express = them, that=E2=80=99s the time for the working group to consider that = possibility =E2=80=93 not as part of Dynamic Client Registration. > =20 > 4. What is the registration access token? Why is is used? What is its = life-cycle? When is it issued, when is it changed? When is it deleted? > =20 > See the response above above and the definition in =C2=A71.2:=20 > =20 > Registration Access Token: An OAuth 2.0 Bearer Token issued by the = Authorization Server through the Client Registration Endpoint which is = used by the Client to authenticate itself during read, update, and = delete operations. This token is associated with a particular Client. > =20 > If this can be clarified, I welcome text suggestions. > =20 > The latter part of 1.2 didn't seem like terminology but rather = architecture or part of the introduction that describes what the spec = does. The third point doesn't seem to fit with the other two except to = say that the dynamic registration endpoints use their own access tokens = called registration access tokens. > =20 > Client Registration Endpoint: The OAuth 2.0 Endpoint through which > a Client can request new registration. The means of the Client > obtaining the URL for this endpoint are out of scope for this > specification. > =20 > o Client Configuration Endpoint: The OAuth 2.0 Endpoint through > which a specific Client can manage its registration information, > provided by the Authorization Server to the Client. This URL = for > this endpoint is communicated to the client by the Authorization > Server in the Client Information Response. > =20 > o Registration Access Token: An OAuth 2.0 Bearer Token issued by = the > Authorization Server through the Client Registration Endpoint > which is used by the Client to authenticate itself during read, > update, and delete operations. This token is associated with a > particular Client. > =20 > This section is meant to just introduce the new terms that are then = explained in greater detail throughout the rest of the document. Yes, = it's a bit architecture, but only in the sense that you need to define = the terms that make up your architecture. How would you suggest that it = change? > =20 > Probably this is more a matter of style. But, what happened for me is = I naturally skipped the terminology section, as I wasn't expecting = protocol components to be there. "terminology" is something I think = people tend to use as a dictionary rather than as protocol component = description. Maybe the chairs can advise? > =20 > If we distinguish between first time registration of a particular = client software package, it is possible that somethings like = authentication method can be negotiate in or out-of-band at that time. = Subsequent registrations should only have parameters for items that = could change per deployment (like tos_uri). I think = token_endpoint_auth_method is one thing that should not be negotiated = per instance. > =20 > When subsequent instances register, I have to ask the question, for = example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication method. > =20 > I'm confused by this -- as far as the dynamic registration spec is = concerned, all instances are separate from each other. All parameters = change per instance. And instance, you should keep in mind, is defined = as any one copy of the client code connecting to any new authorization = server. That pairing creates the client_id, and therefore the instance, = and therefore the registration access token, and therefore the = registration itself at a conceptual level. So there is no way other than = per-instance for a client to ask for a particular = token_endpoint_auth_method. Where else would the AS find out about it? > =20 > We still disagree on this. It is my assertion that clients should = NEVER ask for a particular token auth method. Since it is the AS that is = authenticating the client, then it is the AS's right to set the = authentication policy. The role of dynamic reg endpoint is to inform = the client what it must do. My assumption is that during the first time = a piece of software is registered (the first instance), there could be = some OOB discussion by an administrator to approve the particular = authentication type for the AS in question. > =20 > I haven't heard a reason justifying this parameter other then "it is = needed". Why? > =20 > The role of the dynamic registration protocol is twofold: half of that = is the server informing the client what it must do. But the other half = is the client informing the server what it *can* do, or what it *wants* = to do.=20 > =20 > And again, there's no way to distinguish a first instance from a = subsequent instance unless you're doing something in addition. Nothing = is stopping the same application from registering a new instance of = itself for every single user or every single token that it wants to get = access for. That's complicated and wasteful and not a great idea, sure, = but there's no useful way to prevent that kind of behavior if you also = want open registration of clients.=20 > =20 > I think we've discussed how recognizing subsequent instances is easily = done. > =20 > As I mentioned in the other thread, if a developer chooses to limit = the capabilities of the client it must do so by looking to the developer = or standard behind the API. Otherwise they are taking the chance. = There's no way a developer can query all the potential deployers to ask = what authn types will you use. As I said, the net effect in the absence = of an API standard dictating what should be supported, the developer = will have to implement all methods. > =20 > My point here is that none of this is helped by the client app saying = what it supports. A developer who takes the route of limiting = implementation takes the chance that the server will not accept. So why = negotiate within registration? > =20 > And there's no way other than per-instance for the server to tell the = client which token_endpoint_auth_method to use. All instances will = probably ask for the same token_endpoint_auth_method from all auth = servers they talk to, right? And each AS will tell each instance that = registers with it to use a particular auth method. There is no way to = tie together different instances across (or within) auth servers without = specifying a significant amount of other machinery. > =20 > Which is not to say that it's not useful in some circumstances to tie = together different instances of the same code across (or within) auth = servers. This is why, with Blue Button+, we specified a specific token = format for the initial access token that the clients use to call the = registration endpoint the first time, as well as a discovery protocol = against a centralized server that handles pre-registration. All of this = machinery is, in my opinion, a stupendous overkill for the general case, = though if some folks find use for it outside of BB+ then it'd be a good = thing to abstract out and make its own spec that extends the Dyn Reg = spec in a fully compatible way. Furthermore, even in Blue Button+ we = specify that all auth servers MUST also accept open registration, = without an initial access token, where the client simply shows up and = says "hey, here are my parameters." The auth server has no way to know = in this case any kind of out-of-band negotiation for different things. = In BB+ we are writing very specific policy guidelines about how to = present the UX and things to the end user for all of these different = cases. But again, all of this is specific to the BB+ use case, and I = don't see value in dragging it in to the registration spec on its own. I = believe it would be far too limiting. >=20 > =20 > See my previous comments on differentiating client instances being out = of scope without rechartering to do this new work and on what the = registration_access_token is. In short, the registration_access_token = is an RFC 6750 bearer token issued to the party registering the client, = enabling it to subsequently retrieve information about the client = registration and to potentially update the registration information for = that registered client. Again, I=E2=80=99ll work with Justin to make = sure that this is as clear as possible in the specification. > =20 > Finally, there seems to be an inconsistent style approach with = draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do = so as well? > =20 > That's an individual submission, not a working group draft. Nobody = has, until now, even mentioned the use of ETags here. UMA (where the = resource registration draft comes from) uses ETags, hence their = inclusion there. I personally don't see their utility here, though, and = I wouldn't want to include a wholly new mechanism this late. > =20 > Yes. Thomas' draft is not a WG document. But that doesn't mean he = doesn't have a point. It's worth discussing.=20 > =20 > One could argue that the point of an ETag is that it is useful for = change detection when there are multiple writers to a particular = resource. In the design of dynamic registration endpoint, there should = only be one writer -- the client. This is an important observation. > =20 > There are other mechanisms that handle this -- namely, the = registration access token and the client_id. Many instances include the = client_id in some form in the client configuration endpoint's URL for = sanity checking, as described in =C2=A74.1.=20 > =20 > If everyone agrees, I'm in agreement. But it will likely mean changes = for the resource reg draft if adopted. > =20 > ETags seem like an unnecessary addition (and potential complication) = to the specification. It=E2=80=99s already working fine as-is. > =20 > Specific items: > --------------------- > "token_endpoint_auth_method" > =20 > There is some confusion as to whether this applies to server or client = authentication. Suggest renaming parameter to = "token_endpoint_client_auth_method" > =20 > This is the first I've heard of this particular confusion. I'm fine = with either name but at this stage I don't want to make syntax changes = without very, very compelling reasons to do so. > =20 > The question was raised to me by some new developers. It seems obvious = to us as experienced OAuth persons, but to new developers it seems = unclear. Also, now that you are introducing registration = authentication, the whole thing gets very confusing. So it is useful = disambiguate all the parameters where possible. That said, I wouldn't = mind shorter names (maybe not quite as short as the JOSE stuff ;-) > =20 > Fair enough, but again, I only want to do syntax changes if the rest = of the WG *really* wants to. > =20 > I agree with Justin here. I=E2=80=99m fine clarifying the description = of this parameter to resolve the potential ambiguities that you cite, = Phil. I=E2=80=99m not OK revising the syntax without a compelling = reason to do so. > =20 > * Currently, the API only supports a single value instead of an array. = If the purpose is to allow the client to know what auth methods it = supports, this should be an array indicated what methods the client = supports - or it should not be used. > =20 > I would rather like this to be an array, personally, and brought it up = with the OpenID Connect working group about six months ago. But there it = was decided that a single value was simpler and sufficient for the = purpose. The IETF draft has inherited this decision. I *believe* (though = am not 100% positive) that I brought up this very issue in the WG here = but didn't receive any traction on it, so single it remains. > =20 > I can get behind multiple values. In this case, it changes the meaning = of the parameter. Instead of the client forcing the server to use a = particular method, the client is informing the server about what methods = it can perform. This allows the server to assign the appropriate method = based on its own policy. >=20 > Also note that this field, like all others in =C2=A72, represents two = things: the client telling the server "I want to use this value for this = field", and the server telling the client "this is the value you have = for this field". It's not exactly a negotiation, more like making a = polite request to an absolute dictator who has the last word anyway. But = at least this dictator is nice enough to tell you what their decision = was instead of just decapitating you. > =20 > This is the heart of my objection. This fuzziness is is going to lead = to interop issues. > =20 > There is no fuzziness that I can see here. It's parallelism between = what goes in to the endpoint and what comes out of it. The semantics for = the request and the response are different, and differentiable by the = fact that one is a request and the other is a response.=20 > =20 > The inter-op issue I would like to point out is that the spec does not = currently specify if particular input values are singular or multiple. = If an implementer assumes singular and clients assume multiple, we have = issues. > =20 > The multiple/single discussion above gets to the heart of what I *do* = believe is a deficiency in the specification, as it=E2=80=99s currently = written. The authors, myself included, have failed to make it 100% = clear that discovery of Authorization Server functionality is out of = scope for this specification. I strongly believe that we need to add a = clear statement to this effect in the introduction to the specification. > =20 > The purpose of the Dynamic Client Registration specification is for = the client to register with the Authorization Server and to inform it of = properties of the client that the AS may want/need to be aware of. It = *is not* the purpose of this specification for it to be used by clients = in any manner to discover features of the Authorization Server. That = should be explicitly out of scope. > =20 > Currently, clients are instructed by RFC 6749 to discover information = about Authorization Servers they interact with by consulting the = =E2=80=9Cservice documentation=E2=80=9D (RFC 6749, Sections 3.1 and = 3.2). They can also learn information about Authorization Servers in = specific contexts through discovery protocols such as OpenID Connect = Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) = and UMA Discovery (TBD). > =20 > I suspect that at some point, someone in the OAuth working group will = propose developing a generic OAuth discovery mechanism, which will lead = to a rechartering to include this work in the working group=E2=80=99s = set of deliverables. I would support doing this work and the necessary = rechartering to do so. > =20 > That being said, I strongly oppose trying to shoehorn piecemeal = aspects of discovery into the Dynamic Client Registration specification. = It is distinct functionality and deserves first-class and separable = treatment by the working group. Discovery is for potential clients to = learn properties of the AS before registration. Registration is for = potential clients to inform the AS of its properties, creating a = registered client. Discovery sends information about the AS to the = Client. Registration sends information about the Client to the AS. = That=E2=80=99s a clean separation. We should strongly resist muddying = the two functions. > =20 > OAuth 2.0 is a success because it didn=E2=80=99t try to boil the = ocean. It specified how to do one thing well in a simple, web-friendly = manner. We should do the same =E2=80=93 focusing on specifying = interoperable dynamic client registration, while making it clear that = this is distinct from discovery about Authorization Server properties, = and making it clear that discovery is out of scope for this work. > =20 > I apologize at this point on behalf of myself and the other spec = editors for not being 100% clear that discovery functionality is = explicitly out of scope for Dynamic Client Registration. If we had done = so, I=E2=80=99m sure that many of the current questions and confusions = would not have arisen. I think we=E2=80=99d assumed that this was = obvious, but from the current discussions, it=E2=80=99s apparent that = it=E2=80=99s not obvious. I will personally commit to clarifying the = specification at this point to eliminate this potential point of = confusion. > =20 > Getting back to the specifics, the only useful purpose of a = multi-valued =E2=80=9Ctoken_endpoint_client_auth_method=E2=80=9D member = would be to enable the client to discover information about the = authentication methods supported by the AS after the registration had = been performed. But that is a discovery function, and so should be part = of the discovery work =E2=80=93 not this specification. We should = resist shoehorning in bits of discovery into this specification. It = *is* a worthwhile topic, but deserves full consideration by the working = group in its own right. Therefore, this member must remain = single-valued, and be clearly specified as the method by which a client = informs the AS which token endpoint authentication method it will use. = Anything else would be scope creep, and result in an unnecessarily = complicated specification and unnecessarily complicated clients. > =20 > * There is no authn method for "client_secret_saml" or = "private_key_saml". > =20 > Nobody has really asked that these two be included or specified. The = extension mechanism (using an absolute URI) would allow someone else to = define these. Is the definition in the SAML Assertion draft sufficient = for their use? > =20 > I think this is coming from the fact that there is a JWT bearer draft = and a SAML bearer draft. The truth is you are defining an = authentication that isn't even defined. > =20 > There are no profiles referenced or defined for "client_secret_jwt" or = "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced = cover these types of flows. They only cover bearer flows. = "client_secret_jwt" and "private_key_jwt" seem to have some meaning = within OpenID Connect, but I note that OIDC does not fully define these = either. > =20 > The JWT assertion draft does say how to use a JWT for client = authentication, and the DynReg text differentiates between a client = signing said JWT with its own secret symmetrically vs. a client using = its own private key, asymmetrically. > =20 > Actually my interpretation is the JWT draft assumes the JWT Bearer is = a bearer token. The assumption is that if a client has the assertion it = has the right to present it. IOW. The JWT Bearer Draft is most = definitively not a JWT HoK Draft. :-) > =20 > Regardless, you are introducing a new profile which is undefined. > =20 > I think I see the point that you're making now, let me try to re-state = it: > =20 > While the basics of "how to present a JWT as a client credential" is = defined here: = http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2= .2 , it's not completely specified in that it doesn't fully restrict the = signature secret source, the audience claim, and other things that the = AS would need to check and validate. Right? The dynamic registration = draft can define those cases in greater detail if needed (though I think = it does so sufficiently as-is, I welcome more clarity). > =20 > I'd be OK with adding the SAML bit, going into greater detail on the = JWT bits, or dropping the JWT bits, if the WG wants to do any of those = actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it out. > =20 > I guess then the mistake the JWT Bearer and SAML Bearer drafts authors = made is they assumed everyone had the same definition of bearer token. = To me a bearer token opaque to the client. It therefore cannot do any = signature work with regards to the token itself. Now, that's not to say = a proof didn't occur between the client and the token issuer, but when = the client wields the token, it is handling an opaque string. > =20 > The concept of client_secret_jwt suggests an HoK profile. Therefore = of course the bearer drafts are a little underspecified when it comes to = HoK profiles. > =20 > So for example, you need a draft like the MAC draft for this.=20 > =20 > I'm having trouble overall here. It seems the authn types suggest ONLY = strong authentication for clients, yet during the registration process = the current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way). If you haven't authenticated = the software at all, why have strong client auth? > =20 > There is no authentication method defined for "client_bearer_saml" or = "client_bearer_jwt" or "client_bearer_ref". Since the bearer specs say = this is acceptable, the dynamic registration spec should accept these. > =20 > I don't understand this bit -- where are these defined in RFC6750? I = don't even know what client_bearer_ref would refer to. > =20 > 6750 says you can use a bearer assertion (e.g. obtained from an IDP) = and wield it as an authentication assertion. The client is NOT creating = or modifying the assertion. The client is simply passing one it = previously obtained. > =20 > What you are describing is not bearer. It is holder of key. Very very = different.=20 >=20 > A possible suggestion is to remove client_secret_jwt and = private_key_jwt and define those as register extensions since these = profiles are not defined. > =20 > That's possible, but they are in active use already.=20 > =20 > That may be true. But then you need to write another draft so the rest = of us can implement it in an interoperable way. Me I prefer not to = guess what you are doing. > =20 > This much I agree with. > =20 > Justin, John, and I discussed this issue and agree with your = suggestion, Phil. Since they are not completely specified, we will = remove the client_secret_jwt and private_key_jwt methods from the = specification and add a registry, enabling specification that do fully = specify these and other token endpoint authentication methods, including = potential methods using SAML assertions, to register them in the = registry, rather than trying to bake them into the Dynamic Client = Registration specification. > =20 > About "tos_uri" and "policy_uri" > =20 > The distinction between tos_uri and policy_uri is unclear. Can we = clarify or combine them? > =20 > Terms of service and policy are two different documents. One is = something that a user accepts (generally describing what the user will = do), one is a statement of what the service provider (in this case, the = client) will do. More importantly, we used to have only one, and several = people asked for them to be split. > =20 > Several developers were confused by this. In particular they couldn't = figure out which was used for what. Just passing along the feedback. > =20 > OK, the distinction that I see is that the TOS is contractual, the = Policy is a statement. Re-reading the definitions in there right now, = that can be made much clearer. (It even looks like some OIDC text leaked = into the definition of policy_uri and that hadn't been caught yet.) > =20 > I support clarifying the language on these definitions, and will work = with Justin to do so. > =20 > Also, aren't these really URIs or are they meant to be URLs? > =20 > There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a plus. > =20 > Arg. Nice. Then the text should say the value passed must resolve to = a valid web page, document, whatever. > =20 > That's fair, and it's something that the AS can even check if it wants = to. > =20 > Agreed on this clarification. > =20 > About "jwks_uri" > =20 > A normative reference for = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.=20 > =20 > Yes, you're correct, I'll add that. > =20 > Should be URL instead of URI? > =20 > See above. :) > =20 > Agreed on adding this reference. > =20 > Section 2.1 > =20 > In the table urn:ietf:params:oauth:grant-type:jwt-bearer > is missing. > =20 > It's there in the copy of -10 I'm reading off of ietf.org right now = =E2=80=A6 ? > ' > Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer > =20 > Ah, that makes more sense. If the WG wants to add in SAML support to = parallel the JWT support, I'd be OK with that. > =20 > =E2=80=9CAs such, a server supporting these fields SHOULD take steps = to ensure that a client cannot register itself into an inconsistent = state.=E2=80=9D >=20 > We may want to define more detailed HTTP error response. E.g. 400 = status code + defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D= )? > =20 > I'd be fine with defining a more explicit error state in this case. I = think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special. > =20 > I *think* that this goes away with the deletion of client_secret_jwt = and private_key_jwt in favor of the registry=E2=80=A6 I=E2=80=99ll do a = consistency check and verify that when the spec is updated accordingly. > =20 > Section 2.2 > =20 > May want to add: > =20 > When =E2=80=9C#=E2=80=9D language tag is missing, (e.g. =E2=80=9C#en=E2=80= =9D is missing in =E2=80=9Cclient_name=E2=80=9D, instead of = =E2=80=9Cclient_name#en=E2=80=9D) the OAuth server may use interpret the = language used based on server configuration or heuristics. > =20 > That seems inconsistent with what we already have: > =20 > If any human-readable field is sent without a language tag, parties = using it MUST NOT make any assumptions about the language, character = set, or script of the string value, and the string value MUST be used = as-is wherever it is presented in a user interface. > =20 > Which is to say, treat it as a raw byte-value-string and don't try to = get fancy. > =20 > I will discuss with our developers. I'm not sure the as-is works. =20 > =20 > Is it the intent that when the client has localized "client_name" for = example, it should pass all language variations in a JSON array? > =20 > Or, should part of the registration be to indicate which interface = language the client wishes to use? Then it only passes a single value = for that registration? > =20 > =20 > No, the client should pass parameters as multiple separate values. = Connect has this in its example: > =20 > "client_name": "My Example", > "client_name#ja-Jpan-JP": > "=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88=E5=90=8D", > Should we add that to at least one of the examples in DynReg? (The = language tags are a late addition, so the examples don't reflect it.) > =20 > An example would definitely help. > If the client passes only a single unadorned field, the AS can't make = any assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with it. > =20 > Passing in a "default" language field (like default_locale or the = like) is only going to lead to pain for implementors of both clients and = servers, and it's going to hurt the interoperability of the = human-readable fields.=20 > =20 > I think what I meant is since you are allowing each client to register = different things, AND the client likely already knows the user's = preferred language, why wouldn't the client just pass text values in one = language and another parameter indicating preferred language in the case = of any service generated text. > =20 > Is the reason you are passing multiple localizations is so that you = can use the preferred language of the resource owner rather then the = client user? I wonder if that is correct. If the language preferences = are in fact different, what would the user of the client app expect? > =20 > ----> any multi-lingual people have any opinions here? > =20 > Without specific proposed text changes to review, it=E2=80=99s hard to = know what to think about this comment. Unless a specific proposed text = change is sent to the list with clear rationale for why it=E2=80=99s = better than what=E2=80=99s there now and reviewed by the working group, = I don=E2=80=99t believe we should change the specification in response = to this comment. > =20 > Section 3 > =20 > Existing text: >=20 > =E2=80=9CIn order to support open registration and facilitate wider = interoperability, the Client Registration Endpoint SHOULD allow initial = registration requests with no authentication. These requests MAY be = rate-limited or otherwise limited to prevent a denial-of-service attack = on the Client Registration Endpoint.=E2=80=9D >=20 > I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D. In most cloud services, the first client is = registered by a human user. Then, other clients can be further used to = automate other client registration. So, the first request would = typically come with an authenticated user identity.=20 > =20 > I think the weight of "SHOULD" is appropriate here, because I believe = that turning off open registration at the AS (which is what this is = talking about) really ought to be the exception rather than the rule.=20 > =20 > I think you are reading it wrong -- a double-negative issue. The end = of the sentence is "no authentication". You are implying that NO = Authentication us what should normally be done. I think you intend = anonymous authentication to be the exception rather than the rule don't = you? > =20 > No, I think that anonymous authentication should be the rule. Open = registration should be default.=20 > =20 > I disagree. Again, the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. Yes = you gain uniqueness, but that's about it. >=20 > On the flip side, the earlier paragraph: >=20 > =E2=80=9CThe 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.=E2=80=9D >=20 > I tend to think it would be better to change this =E2=80=9CMAY=E2=80=9D = to =E2=80=9CSHOULD=E2=80=9D. >=20 > That access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user assertion = token. > =20 > Again, disagree, for the same reasoning as above. > =20 > Same reasoning.=20 >=20 > I agree with Justin here. The default should be that open = registrations are enabled. The exception case is that specific = permissions are required to perform dynamic client registration. >=20 > About section 4.3: > =20 > If the client does not exist on this server, the server MUST respond > with HTTP 401 Unauthorized, and the Registration Access Token used = to > make this request SHOULD be immediately revoked. > =20 > If the Client does not exist on this server, shouldn't it return a = "404 Not Found"? >=20 > If revoking the registration access token, is it bound to a single = client registration? This is not clear. What is the lifecycle around = registration access token? Only hint is in the Client Information = Response in section 5.1. > =20 > The language about the 401 here (and in other nearby sections) is = specifically so that you treat a missing client and a bad registration = access token the same way. You see, returning a 404 here actually = indicates things were in an inconsistent state. Namely, that the = registration access token was still valid but the client that the = registration access token was attached to doesn't exist anymore. The = registration access token in meant to be tied to a client's instance (or = registration), so it's actually more sensible to act as though the = registration access token isn't valid anymore. In at least some = implementations (specifically ours at MITRE that's built on SECOAUTH in = Java), you'd never be able to reach the 404 state due to consistency = checking with the inbound token. > =20 > Since the intent of the registration access token is that it's bound = to a single instance, its lifecycle is generally tied to the lifecycle = begins at the issuance of a new client_id with that instance. That token = might be revoked and a new one issued on Read and Update requests to the = Client Configuration Endpoint (and the client needs to be prepared for = that -- same as the client_secret), and it will be revoked when the = client is deleted either with a Delete call to the Client Configuration = Endpoint or something happening out-of-band to kill the client.=20 > =20 > Should we add more explanatory text to the definition in the = terminology section? Elsewhere? I'm very open to concrete suggestions = with this, since I don't think it's as clear as we'd like. > =20 > I think we should look at it. >=20 > For security reasons, it=E2=80=99s generally not good to distinguish = between =E2=80=9Cnot found=E2=80=9D and =E2=80=9Cunauthorized=E2=80=9D = errors in responses, as that can provide the attacker an oracle to probe = whether a particular entity exists I don=E2=80=99t think a change is = called for here. >=20 > About section 5.1: > Is registration_access_token unique? Or is it shared by multiple = instances? If shared, then registration_access_token can't be revoked = on delete of client. > =20 > The registration_access_token is unique to a registered client, in the = RFC 6749 sense of =E2=80=9Cclient=E2=80=9D. Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly. >=20 > Suggest rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D,=20 >=20 > Suggest to rename =E2=80=9Cissued_at=E2=80=9D to =E2=80=9Cid_issued_at=E2= =80=9D > =20 > While I do like the suggestion of changing these to = client_secret_expires_at and client_id_issued_at, and I think these are = more clear and readable, >=20 >=20 > I don't want to change the syntax during last call unless there is a = clear need and a clear consensus for doing so. > =20 > That's why we are having last call. To confirm consensus on the draft.=20= > =20 > Same reasoning as earlier. You now have multiple tokens (registration = access and client) in play. The spec needs to be clear which one it is = talking about. > =20 > I'm fine with the suggested change but I would like more feedback from = other people before moving forward with it. There's a lot of value in = "just pick a name and ship it" as well though, and I don't want to = devolve into bike shedding. (I'm not accusing you of bike shedding quite = yet, btw, just afraid of getting into a long debate on names.) > =20 > Again, this was a problem raised by people new to the specification. = They found it confusing. I tend to agree. We're not talking about what = colour to paint the shed. We're talking about whether the bike shed is a = house. :-)=20 > =20 > I'm not too fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at".=20 >=20 > If the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at= =E2=80=9D are unclear, we should clarify them. If you believe that this = is the case Phil, can you supply proposed alternative definition text = that is clearer? That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them. They are = already working fine as-is in production deployments. > =20 > Section 7 > =20 > When a client_secret expires is it the intent that clients do an = update or refresh to get a new client secret? > =20 > Yes, the client is supposed to either call the read or update methods = on the client configuration endpoint to get its new secret. As discussed = above, I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this. > =20 > Either is a reasonable behavior on the behalf of clients, depending = upon context. I support adding text to clarify this. > =20 > Again, thanks for the very thorough read through. Have you implemented = any of the spec yet, either as-is or with any of your suggested changes? > =20 > Yes. Much of the feedback is coming from our development community.=20 > =20 > Ah, very cool. Developer experience is the most valuable feedback, in = my opinion. If you can't actually build the blasted thing, what good is = it? :) > =20 > Glad to hear that you=E2=80=99re working with developers building the = spec. Please thank them for the feedback. > =20 > -- Justin > =20 > Best = wishes, > -- Mike >=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=_50DF9D20-A207-4738-835C-C950A07ECF19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree with Mike, I don't = think we are loosing anything, only gaining.

I think = it is a false statement to say that having multiple client instances = with the same client_id and secret is a = feature.

In reality with public clients or = public clients masquerading as private ones the only real way for the AS = to tell them apart in OAuth is by redirect_uri.  We are not = changing that, though we are perhaps making it cleaner that client_id = for public clients can't be relied upon in any way.   Previously we = had what was more or less assumed to be a one to one mapping of = client_id to redirect for native clients.

Once = we start assigning unique client_id to instances of clients that are all = going to be using the same redirect_uri there are a lot of question a AS = has to decide, such as can two client_id register the same redirect_uri? =  That could well cause all sorts of race conditions on the device = if you have two apps fighting over the same custom = scheme.

So I think in reality the piece of = information that a registration server that is going to need to look at = is the custom url scheme for apps,  probably disallowing multiple = anonymous registrations for the same custom scheme. =  

Getting into the details of how app = stores allocate schemes to developers etc is out of scope for this spec. =  Someone can build something more sophisticated on top of dynamic = registration, but there are a lot of issues outside of the simple how is = a client registering for a client_id and secret without forcing a manual = step through a web portal.

I honestly don't = think adding some new application identifier solves the problem. =  That information is in the redirect_uri for native apps, and the = problem doesn't exist for web server = clients.

John = B.

On 2013-05-21, at 2:28 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

 
 
Mike,

There is an = operational loss of information in the dynamic registration = spec.

www.independentid.com
phil.hunt@oracle.com
O= n 2013-05-21, at 10:52 AM, Mike Jones wrote:

No information is being thrown away.  = Developers can use dynamic registration to obtain a client_id and then = have all the client instances use that client_id if they choose - just = like they can do when doing out-of-band registration with a = site=E2=80=99s developer portal.  The only difference is that they = don=E2=80=99t have to do out-of-band registration = anymore!
 
-- = Mike
 
 
From: Phil = Hunt
Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E= =E2=80=8E21=E2=80=8E, =E2=80=8E2013 =E2=80=8E8=E2=80=8E:=E2=80=8E02=E2=80= =8E =E2=80=8EAM
To: Justin Richer
Cc: oauth@ietf.org WG
 
Regarding charter. 

The charter is = a one-liner. To say associating clients is not in the charter while = saying every other 'new' thing that is in the spec (eg client auth type) = is in is laughable. After all the entire draft is new = functionality. 

The item i have asked for = is not new. It preserves information that was available without reg. = Namely a way to recognize multiple clients as a common public client as = in 6749 they share a client_id.  The draft throws this information = away preventing security admins from making any judgements since all = clients are now anonymized.

Where in the = charter does it say you can anonymize the = clients? 

Phil

On = 2013-05-21, at 6:46, Justin Richer <jricher@mitre.org> = wrote:


On 05/21/2013 = 02:01 AM, Phil Hunt wrote:


Phil

On = 2013-05-20, at 8:35, Justin Richer <jricher@mitre.org> = wrote:


On 05/17/2013 = 05:27 PM, Phil Hunt wrote:
Mike,

Rather then = embed comments in an extended thread, I'd like to open up a specific = discussion on the objective of dyn reg.

I see = limited to no value in having clients completely anonymously registering = and receiving tokens without any ability to correlate applications = between applications. 

I think that herein lies a very big = disconnect in assumptions. I see a huge benefit in anonymously = registered clients getting tokens because there is an end-user in the = loop during the authorization phase (long after registration has = happened). The arity of registrations to authorizations approaches 1:1 = in these cases, and I'm just fine with that. 
<Ph>Then = what you describe is NOT anonymous but rather a profile not covered by = the spec as there is no discussion of user authenticated registration. = Implicitly or explicitly. 

[JR] I think you misunderstand = what I said, let me try to be more explicit: the user is not = authenticating the registration. The user is not involved in the = registration. The user might not even know that a registration happened. = The registration is (normally) completely anonymous and open, the client = just shows up and says "Hi, I'm a client!". 

The = "authorization" that I mentioned happens later and is a normal OAuth = authorization, which has a user involved like usual. The authorization = step in OAuth depends on *some* kind of registration happening = beforehand, dynamic or otherwise. This is all perfectly within the model = of OAuth. 


=46rom the RFC6749 perspective, a "client" is = not a particular piece of code, it is a particular copy of a piece of = code with a particular client_id from the vantage point of a particular = authorization server.
<ph> actually, i disagree. = This spec fundamentally breaks the old definition and behavior from = 6749. In the old way every instance of software shared a client_id. In = this draft, u throw that away without preserving the information. This = is BAD!
[JR] No, we're not throwing that away at all. = The concept is the same, but when you add new functionality, the = mechanics change a bit. A "client_id" was always pairwise between a = client and an AS. If a client had to talk to two AS's before, it would = have two client_ids. That's still the case. If there were multiple = copies of a confidential client, you need to get a client_id and = client_secret to each copy. That's still the case. What's different is = that we've made it *easier* for a particular piece of code to get = different client_ids when it's talking to the same or a different auth = server, at runtime. When you have to manually register every client, = you're going to just do it once. If you can do it dynamically, you have = more options. 

Note that you can *still* have a public = client with a known client_id if you want to. You don't even need to use = dynamic registration for that. Heck, you don't need to use dynamic = registration for any kind of client if you don't want to, since most = services will probably still offer manual registration through some = portal kind of page.



A "client" is, = conceptually, a pairwise association between two running codebases. When = you have a particular piece of code talking only to one auth server and = being manually configured at said auth server with its client_id, this = is fairly clear and straightforward and the arity is simple. Things get = a bit muddy when you introduce dynamic registration, which is why I = think that we need to have introductory text about this. = Specifically:

 - a particular piece of code can be run on = multiple devices and talk to the same auth server, each copy of that = code getting its own client_id. 
 - a particular copy of a = particular piece of code can now be expected to talk to multiple auth = servers, each auth server giving the piece of code its own = client_id. 

Both of these are cases of what defines an = "instance" in most people's heads, even though it's the same software, = even sometimes the same running copy of the same software. But as far as = RFC6749's definition of "client" is concerned, these are all completely = separate "client"s with no way to tie them together out of the box. And = that's fine.


Associating client_id's with known = client applications to allow admins to know who is running what version = of clients seems to be the most fundamental part of the reason for = dynamic reg. How can you revoke access to particular client app types? =  As Justin already talked about in his Blue Button+ scenario, there = are often life and death situations where particular sets of clients = need to be revoked.  
While it's very useful, I wouldn't = (and haven't) classified it quite like that. Nor would I say that the = BB+ profile is a complete solution -- our Registry component does not = actually push revocation notifications down to Providers (yet), so it's = more like invalidating a root certificate and waiting for caches to time = out for things to cascade. We've been talking about adding some form of = callback to providers, but we don't want to boil that particular ocean = right now. However, the BB+ profile makes use of a well-specified = discovery and Registry set up, as well as data conveyed in structured, = signed tokens (JWTs) at different points in the = process.


Or put another way. I believe this will be a = critical operational requirement going forwards. If the spec is = published as is, it will be quickly invalidated by one that does at = least partially address the problem.
That's not true = at all. BB+ addresses this scenario and still uses the Dynamic = Registration spec as-is. I would encourage folks to read what we're = doing, a work-in-progress found here:
<ph> but you are breaking = other things and overloading client cred etc to pass in signed data. I = don't want a hack for a solution. I want interop. 
[JR] I'm = curious, what exactly are we breaking? If anything in BB+ breaks = compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need = to fix there. It is our intent to be fully compatible with OAuth Dyn = Reg, and we are even explicitly calling for open registration as = mandatory to implement for authorization servers within BB+, even though = we have additional mechanisms as well for what we're calling "trusted = registrations". For those trusted registrations, we're not using the = client *credentials* to pass in signed data, we're using the initial = *registration authentication* mechanism (which is to say, an OAuth = token) for its intended purpose: authorizing the holder of this token = access to the registration endpoint. In BB+, we're profiling exactly = what that means. To wit, we define the content of the token (which is = fully compatible with DynReg which doesn't care what's in the token) and = how the AS can verify it (which DynReg doesn't care how it happens) and = we've added some additional rules and policies that allow us to tie = together instances of the client across the distributed = network. 

So why doesn't DynReg adopt this mechanism? Two = reasons: it adds a huge amount of very specific machinery (signed tokens = with known formats and fields, a Registry with manual pre-registration, = a three-tiered discovery service with information about clients and = service providers rooted at the Registry, trust frameworks and network = enforcement policies that all players have to agree to before playing, = etc.), and it's not really doing just registration anymore. In BB+, we = needed the Registry and Discovery services to do other functions as well = apart from just registration, and so it makes sense to re-use = them. 

If there were a simple solution that didn't leave = security holes the size of a small army, I'd be glad to bring it to the = table. But I am convinced that a good solution for managing client = instances across a network requires a lot more thought and = consideration, and I believe that having a fully specified discovery = service will help this case, like it has helped in BB+. But I think that = it's a complex enough problem that it needs its own set of = considerations. With DynReg, we need to leave things open for that work = in the future, and I believe we have, but we shouldn't kill the simple, = general case for want of a special case. 


  http://blue-button.github.io/blue-button-plus-pull/=

Just because you make something better doesn't mean you throw = necessarily away everything you've done to date.

And dynamic client = registration will make
it easier to broadly deploy OAuth clients = (performing services = to
users).

And: 

Sep 2013 Submit 'OAuth = Dynamic Client Registration Protocol' to the IESG for consideration as a = Proposed Standard
There's nothing in there at all about = tying together client instances. I have not seen anything to convince me = that management of client instances across a deployed network of auth = servers is a necessary part of basic client registration. It sounds very = likely to me that it *is* required for your use case, but that doesn't = make it required for everybody's use case. 

There are other = important pieces of functionality that the WG isn't picking up right now = (such as token chaining and token introspection) that are absolutely = necessary for my own use cases, but I think it makes sense for those to = be separate modules.



As I mentioned in my comments = to the other thread. Let's say we agree not do this now. Well, then the = new draft that does solve it would likely be 95% overlap.  Thus I = see this issue as within charter and should be solved now rather then = waiting for a V2 dyn reg in the next charter.
Why = wouldn't the new draft just be the extra 5%? I personally think that = it's a lot more than 5% once you have in all the assurance and safety = mechanisms in place to avoid self-asserted values causing race = conditions, and what not.

<ph> Two = drafts to do registration is not the way to go. It implies complexity = where there should be none. There is no technical reason for two = drafts. 
[JR] There is a need when there's a special case that = requires a large amount of overhead to be done correctly, to allow the = general case to move forward and be used on its own (as it is being used = today). 


 -- Justin

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





On 2013-05-17, at 1:08 = PM, Mike Jones wrote:

Thanks for the = detailed feedback, Phil.  Sorry for the delayed response =E2=80=93 = I was pretty fully engaged at the European Identity Conference = (where OAuth 2.0 won the = award for best new standard ).  My = feedback on the points raised is inline in = green=E2=80=A6
(Perhaps if any of = you reply to this thread, you could also choose a distinct color  
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, May 16, 2013 = 12:54 PM
To: Richer, Justin = P.
Cc:  WG
Subject: Re: [OAUTH-WG] Last call = review of = draft-ietf-oauth-dyn-reg-10
But without other mechanisms to tie things together, there's no = way for an authorization server to know if any client instance is tied = to any other client instance. Therefore, from the perspective of an AS, = the first instance of an application (i.e., particular configuration of = a set of code) to register is no different to subsequent instances of = that same application. How were you envisioning an AS knowing the = difference between the first and subsequent instances of an application, = specifically? If there's an "application_id" like you mention above, I = think it raises more questions than it resolves: Who issues the = application_id, some server or the application itself? Is it validated = at all? Should it be considered secret? What happens when someone simply = steals an application_id? Does an AS have to do anything to check with = any other AS to see if the application_id has already been used = elsewhere?
How does a = client authenticate the first time and subsequent times to the = registration service?
This is a = separate question all together, as it does not involve the client_secret = or client_id at all. Rather, the first time the client shows up to the = registration service, it may either:
  - Not authenticate at all (this is the true public, open = registration, and it is recommended that servers do = this)
 - = Authenticate using an OAuth 2.0 token (which ATM means a bearer token). = How the client gets that bearer token and what the bearer token means to = the AS beyond "this client is authorized to register" is out of scope = for the spec, by design.
Subsequent = times that the same registered client (by which we mean the same = instance of a client with a particular client_id) shows up at the = registration endpoint (actually, the Client Configuration Endpoint), it = uses its Registration Access Token that it was issued on initial = registration. This is an OAuth 2.0 Bearer token that is unique to the = client instance.
4.  What is the registration access = token? Why is is used? What is its life-cycle?  When is it issued, = when is it changed? When is it deleted?
 
See the response above above and the definition in = =C2=A71.2: 
Registration Access Token: An OAuth = 2.0 Bearer Token issued by the Authorization Server through the Client = Registration Endpoint which is used by the Client to authenticate itself = during read, update, and delete operations. This token is associated = with a particular Client.
 
If this can be clarified, I welcome text = suggestions.
 
The latter part of 1.2 didn't seem like = terminology but rather architecture or part of the introduction that = describes what the spec does. The third point doesn't seem to fit with = the other two except to say that the dynamic registration endpoints use = their own access tokens called registration access = tokens.
Client Registration Endpoint: The OAuth 2.0 = Endpoint through which
      obtaining the URL for this =
endpoint are out of scope for this
 
   o  Client =
Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can =
manage its registration information,
 
   o  Registration Access Token: An OAuth 2.0 =
Bearer Token issued by the
This section =
is meant to just introduce the new terms that are then explained in =
greater detail throughout the rest of the document. Yes, it's a bit =
architecture, but only in the sense that you need to define the terms =
that make up your architecture. How would you suggest that it =
change?
Probably this = is more a matter of style.  But, what happened for me is I = naturally skipped the terminology section, as I wasn't expecting = protocol components to be there.  "terminology" is something I = think people tend to use as a dictionary rather than as protocol = component description.  Maybe the chairs can = advise?
If we = distinguish between first time registration of a particular client = software package, it is possible that somethings like authentication = method can be negotiate in or out-of-band at that time. Subsequent = registrations should only have parameters for items that could change = per deployment (like tos_uri).  I think token_endpoint_auth_method = is one thing that should not be negotiated per = instance.
 
When subsequent instances register, I have to ask the question, = for example when would things like "token_endpoint_auth_method" be = negotiated or be different for the same client software? Should not all = instances use the same authentication = method.
The role of = the dynamic registration protocol is twofold: half of that is the server = informing the client what it must do. But the other half is the client = informing the server what it *can* do, or what it *wants* to = do. 
And again, = there's no way to distinguish a first instance from a subsequent = instance unless you're doing something in addition. Nothing is stopping = the same application from registering a new instance of itself for every = single user or every single token that it wants to get access for. = That's complicated and wasteful and not a great idea, sure, but =  there's no useful way to prevent that kind of behavior if you also = want open registration of clients. 
 
As I mentioned = in the other thread, if a developer chooses to limit the capabilities of = the client it must do so by looking to the developer or standard behind = the API.  Otherwise they are taking the chance.  There's no = way a developer can query all the potential deployers to ask what authn = types will you use. As I said, the net effect in the absence of an API = standard dictating what should be supported, the developer will have to = implement all methods.
My point here = is that none of this is helped by the client app saying what it = supports. A developer who takes the route of limiting implementation = takes the chance that the server will not accept.  So why negotiate = within registration?
And there's no way other than = per-instance for the server to tell the client which = token_endpoint_auth_method to use. All instances will probably ask for = the same token_endpoint_auth_method from all auth servers they talk to, = right? And each AS will tell each instance that registers with it to use = a particular auth method. There is no way to tie together different = instances across (or within) auth servers without specifying a = significant amount of other machinery.
 

Which is not to say that it's not useful in some = circumstances to tie together different instances of the same code = across (or within) auth servers. This is why, with Blue Button+, we = specified a specific token format for the initial access token that the = clients use to call the registration endpoint the first time,  as = well as a discovery protocol against a centralized server that handles = pre-registration. All of this machinery is, in my opinion, a stupendous = overkill for the general case, though if some folks find use for it = outside of BB+ then it'd be a good thing to abstract out and make its = own spec that extends the Dyn Reg spec in a fully compatible way. = Furthermore, even in Blue Button+ we specify that all auth servers MUST = also accept open registration, without an initial access token, where = the client simply shows up and says "hey, here are my parameters." The = auth server has no way to know in this case any kind of out-of-band = negotiation for different things. In BB+ we are writing very specific = policy guidelines about how to present the UX and things to the end user = for all of these different cases. But again, all of this is specific to = the BB+ use case, and I don't see value in dragging it in to the = registration spec on its own. I believe it would be far too = limiting.

 
See my = previous comments on differentiating client instances being out of scope = without rechartering to do this new work and on what the = registration_access_token is.  In short, the = registration_access_token is an RFC 6750 bearer token issued to the = party registering the client, enabling it to subsequently retrieve = information about the client registration and to potentially update the = registration information for that registered client.  Again, I=E2=80=99= ll work with Justin to make sure that this is as clear as possible in = the specification.
While the = basics of "how to present a JWT as a client credential" is defined = here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section= .2.2 , it's not = completely specified in that it doesn't fully restrict the signature = secret source, the audience claim, and other things that the AS would = need to check and validate. Right? The dynamic registration draft can = define those cases in greater detail if needed (though I think it does = so sufficiently as-is, I welcome more clarity).
 
I'd be OK with adding the SAML bit, going into greater detail on = the JWT bits, or dropping the JWT bits, if the WG wants to do any of = those actions. My objection is that the JWT stuff is already in use and = functioning and it'd be a shame to leave it = out.
I guess then = the mistake the JWT Bearer and SAML Bearer drafts authors made is they = assumed everyone had the same definition of bearer token.  To me a = bearer token opaque to the client. It therefore cannot do any signature = work with regards to the token itself.  Now, that's not to say a = proof didn't occur between the client and the token issuer, but when the = client wields the token, it is handling an opaque = string.
The concept of = client_secret_jwt suggests an HoK profile.  Therefore of course the = bearer drafts are a little underspecified when it comes to HoK = profiles.
So for = example, you need a draft like the MAC draft for = this. 
I'm having = trouble overall here. It seems the authn types suggest ONLY strong = authentication for clients, yet during the registration process the = current draft isn't able to correlate multiple instances of the same = software (even in a self-asserted way).  If you haven't = authenticated the software at all, why have strong client = auth?
 
There is no authentication method defined for = "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref". =  Since the bearer specs say this is acceptable,  the dynamic = registration spec should accept these.
 
I don't understand this bit -- where are these defined in = RFC6750? I don't even know what client_bearer_ref would refer = to.
 
6750 says you can use = a bearer assertion (e.g. obtained from an IDP) and wield it as an = authentication assertion.  The client is NOT creating or modifying = the assertion. The client is simply passing one it previously = obtained.
 
What you are describing = is not bearer. It is holder of key. Very very = different. 

A possible = suggestion is to remove client_secret_jwt and private_key_jwt and define = those as register extensions since these profiles are not = defined.
That's = possible, but they are in active use = already. 
 
That may be true. = But then you need to write another draft so the rest of us can implement = it in an interoperable way.  Me I prefer not to guess what you are = doing.
This much I = agree with.
 
About "tos_uri" and = "policy_uri"
The = distinction between tos_uri and policy_uri is unclear.  Can we = clarify or combine them?
Terms of = service and policy are two different documents. One is something that a = user accepts (generally describing what the user will do), one is a = statement of what the service provider (in this case, the client) will = do. More importantly, we used to have only one, and several people asked = for them to be = split.
 
Several developers = were confused by this. In particular they couldn't figure out which was = used for what.  Just passing along the = feedback.
OK, the = distinction that I see is that the TOS is contractual, the Policy is a = statement. Re-reading the definitions in there right now, that can be = made much clearer. (It even looks like some OIDC text leaked into the = definition of policy_uri and that hadn't been caught = yet.)
 
I support clarifying the language on these = definitions, and will work with Justin to do so.
Also, aren't = these really URIs or are they meant to be URLs?
 
There was already discussion about this on the list: The IETF is = apparently trying to deprecate URL in favor of URI in new specs. So in = practice they'll nearly always be URLs, but since all URLs are URIs = we're not technically incorrect in following the new policy. And it = makes the IESG less mad at us, which is a = plus.
 
Arg. Nice. =  Then the text should say the value passed must resolve to a valid = web page, document, whatever.
That's fair, = and it's something that the AS can even check if it wants = to.
 
Agreed on this clarification.
'
Sorry I = meant: urn:ietf:params:oauth:grant-type:saml-bearer
Ah, that makes = more sense. If the WG wants to add in SAML support to parallel the JWT = support, I'd be OK with that.
=E2=80=9CAs such, a server supporting = these fields SHOULD take steps to ensure that a client cannot = register itself into an inconsistent state.=E2=80=9D

We may want = to define more detailed HTTP error response. E.g. 400 status code + = defined error code (=E2=80=9Cinvalid_client_metadata=E2=80=9D)?
=
 
I'd be fine with defining a more explicit error state in this = case. I think it would help interop for the servers that want to enforce = grant-type and response-type restrictions, but servers that can't or = don't care about restricting grants types and whatnot don't have to do = anything special.
 
I *think* that this goes = away with the deletion of client_secret_jwt and private_key_jwt in favor = of the registry=E2=80=A6  I=E2=80=99ll do a consistency check and = verify that when the spec is updated accordingly.
May want to = add:
That seems = inconsistent with what we already have:
 
If any human-readable field is sent = without a language tag, parties using it MUST NOT make any assumptions = about the language, character set, or script of the string value, and = the string value MUST be used as-is wherever it is presented in a user = interface.
Which is to = say, treat it as a raw byte-value-string and don't try to get = fancy.
 
I will = discuss with our developers. I'm not sure the as-is works. =  
 
Is it the intent that when the = client has localized "client_name" for example, it should pass all = language variations in a JSON array?
 
Or, = should part of the registration be to indicate which interface language = the client wishes to use?  Then it only passes a single value for = that registration?
No, the client = should pass parameters as multiple separate values. Connect has this in = its example:
   = "client_name": "My Example",
   =
"client_name#ja-Jpan-JP":
     =
"
Should we add that to at least one =
of the examples in DynReg? (The language tags are a late addition, so =
the examples don't reflect it.)
 
An = example would definitely help.
If the = client passes only a single unadorned field, the AS can't make any = assumption about what language it is. Think of this as the = internationalized value of the field while the language tags are the = localized versions of the field. This is why we recommend that the = bare-value always be sent by the client, so that in the lack of anything = more specific, the AS can at least do *something* with = it.
Passing in a = "default" language field (like default_locale or the like) is only going = to lead to pain for implementors of both clients and servers, and it's = going to hurt the interoperability of the human-readable = fields. 
I think what I = meant is since you are allowing each client to register different = things, AND the client likely already knows the user's preferred = language, why wouldn't the client just pass text values in one language = and another parameter indicating preferred language in the case of any = service generated text.
Is the reason = you are passing multiple localizations is so that you can use the = preferred language of the resource owner rather then the client user? I = wonder if that is correct.  If the language preferences are in fact = different, what would the user of the client app = expect?
----> any = multi-lingual people have any opinions here?
Without specific proposed text changes to review, = it=E2=80=99s hard to know what to think about this comment.  Unless = a specific proposed text change is sent to the list with clear rationale = for why it=E2=80=99s better than what=E2=80=99s there now and reviewed = by the working group, I don=E2=80=99t believe we should change the = specification in response to this comment.
Section = 3
 
Existing text:

=E2=80=9CIn = order to support open registration and facilitate = wider interoperability, the Client Registration = Endpoint SHOULD allow initial registration requests with = no authentication.  These requests MAY = be rate-limited or otherwise limited to prevent a denial-of-service = attack on the Client Registration Endpoint.=E2=80=9D
<= br>I would suggest to change the first =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D.   In most cloud services, the first = client is registered by a human user. Then, other clients can = be further used to automate other client = registration.  So, the first request would typically come = with an authenticated user identity. 
 
I think the weight of "SHOULD" is appropriate here, because I = believe that turning off open registration at the AS (which is what this = is talking about) really ought to be the exception rather than the = rule. 
 
I think you = are reading it wrong -- a double-negative issue. The end of the sentence = is "no authentication".  You are implying that NO Authentication us = what should normally be done. I think you intend anonymous = authentication to be the exception rather than the rule don't = you?
No, I think = that anonymous authentication should be the rule. Open registration = should be default. 
 
I disagree. =  Again,  the spec seems contradictory. It suggests strong = client auth methods and at the same time anonymous registration. =  Yes you gain uniqueness, but that's about = it.

On the flip side, the earlier = paragraph:

=E2=80=9CThe 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.=E2=80=9D

I tend to think it would be better = to change this =E2=80=9CMAY=E2=80=9D to =E2=80=9CSHOULD=E2=80=9D.

T= hat access token would carry a human user authenticated identity = somehow. In some cases, it can be a pure authenticated user = assertion token.Same reasoning. 

I agree with Justin here.  The = default should be that open registrations are enabled.  The = exception case is that specific permissions are required to perform = dynamic client registration.
If the = client does not exist on this server, the server MUST = respond
   with HTTP 401 =
Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately =
revoked.
 
If the Client does not = exist on this server, shouldn't it return a "404 Not = Found"?

If revoking the registration access token, is it bound to = a single client registration?  This is not clear.  What is the = lifecycle around registration access token? Only hint is in the Client = Information Response in section = 5.1.
 
The language about the 401 here = (and in other nearby sections) is specifically so that you treat a = missing client and a bad registration access token the same way. You = see, returning a 404 here actually indicates things were in an = inconsistent state. Namely, that the registration access token was still = valid but the client that the registration access token was attached to = doesn't exist anymore. The registration access token in meant to be tied = to a client's instance (or registration), so it's actually more sensible = to act as though the registration access token isn't valid anymore. In = at least some implementations (specifically ours at MITRE that's built = on SECOAUTH in Java), you'd never be able to reach the 404 state due to = consistency checking with the inbound = token.
 
Since the intent of the registration = access token is that it's bound to a single instance, its lifecycle is = generally tied to the lifecycle begins at the issuance of a new = client_id with that instance. That token might be revoked and a new one = issued on Read and Update requests to the Client Configuration Endpoint = (and the client needs to be prepared for that -- same as the = client_secret), and it will be revoked when the client is deleted either = with a Delete call to the Client Configuration Endpoint or something = happening out-of-band to kill the = client. 
 
Should we add more explanatory = text to the definition in the terminology section? Elsewhere? I'm very = open to concrete suggestions with this, since I don't think it's as = clear as we'd like.
 
I think we should look at it.

For security reasons, it=E2=80=99s generally not good = to distinguish between =E2=80=9Cnot found=E2=80=9D and = =E2=80=9Cunauthorized=E2=80=9D errors in responses, as that can provide = the attacker an oracle to probe whether a particular entity exists  = I don=E2=80=99t think a change is called for here.

About section 5.1:
Is = registration_access_token unique?  Or is it shared by multiple = instances?   If shared, then registration_access_token can't be = revoked on delete of client.
 
The = registration_access_token is unique to a registered client, in the RFC = 6749 sense of =E2=80=9Cclient=E2=80=9D.  Again, if we want to do = work on =E2=80=9Cclient instances=E2=80=9D, we need to recharter and = take this distinct work item up explicitly.

Suggest = rename =E2=80=9Cexpires_at=E2=80=9D to = =E2=80=9Cclient_secret_expires_at=E2=80=9D, 

Suggest to = rename =E2=80=9Cissued_at=E2=80=9D to = =E2=80=9Cid_issued_at=E2=80=9D
 
Whil= e I do like the suggestion of changing these to client_secret_expires_at = and client_id_issued_at, and I think these are more clear and = readable,
That's why we = are having last call. To confirm consensus on the = draft. 
Same reasoning = as earlier. You now have multiple tokens (registration access and = client) in play. The spec needs to be clear which one it is talking = about.
I'm fine with = the suggested change but I would like more feedback from other people = before moving forward with it. There's a lot of value in "just pick a = name and ship it" as well though, and I don't want to devolve into bike = shedding. (I'm not accusing you of bike shedding quite yet, btw, just = afraid of getting into a long debate on = names.)
Again, this = was a problem raised by people new to the specification. They found it = confusing. I tend to agree. We're not talking about what colour to paint = the shed. We're talking about whether the bike shed is a = house.  :-) 
I'm not too = fussed about whether you call it "cl_sec_expiry" or = "client_secret_expires_at". 

If = the definitions of =E2=80=9Cexpires_at=E2=80=9D or =E2=80=9Cissued_at=E2=80= =9D are unclear, we should clarify them.  If you believe that this = is the case Phil, can you supply proposed alternative definition text = that is clearer?  That being said, I believe that at this point we = should stick with the existing protocol element names unless = overwhelming working group sentiment emerges to change them.  They = are already working fine as-is in production = deployments.
Section = 7
 
When a client_secret expires is it the = intent that clients do an update or refresh to get a new client = secret?
Yes, the = client is supposed to either call the read or update methods on the = client configuration endpoint to get its new secret. As discussed above, = I'm not sure that's as clear as it needs to be, and I welcome = suggestions on how to clarify this.
Ah, very cool. = Developer experience is the most valuable feedback, in my opinion. If = you can't actually build the blasted thing, what good is it? = :)
 
Glad to hear that you=E2=80=99re working with = developers building the spec.  Please thank them for the = feedback.
 -- = Justin
 

_______________________=
________________________
OAuth mailing 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=_50DF9D20-A207-4738-835C-C950A07ECF19-- --Apple-Mail=_1FFBF6C9-44B0-446A-B140-9D8094FAFC0C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIxMjAyODEyWjAjBgkqhkiG9w0BCQQxFgQUxRZx8M+i lyeCADg6n1//+m9QGzwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAX2AK+2YJPExtmxxb9R9psoZ+8DpvF6PeQUtiO8WR 0qj+tjH721dKJHAaDAVSNc1iXmrcBzBk5Lqg6qvWZFooxlWC7uCq3YzBRv6FD7BNSKy6laua3osZ sNMucJZQhWnh+qRe7fYAFvs1sro6x98+m6v1QIO4gwew6DeAuvSPmtxZqQxpym36Ehd+2S4FyVGy 4mT1oFuLVJ6Tfeb4lfzKR6i/6aDHGZIZR379CKfBHuJRLwfLGQzhdMGW4l2kqy09mE01BizbV9KM axNtZhoQ3+t84KCD659WNHTVtj9bJ+AHXEBRuAC0dofgRSHJwTfxpGm42cQq8ph0dadiz3DCkwAA AAAAAA== --Apple-Mail=_1FFBF6C9-44B0-446A-B140-9D8094FAFC0C-- From jricher@mitre.org Wed May 22 06:58:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8121F920E for ; Wed, 22 May 2013 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bWAaw+cCsz5 for ; Wed, 22 May 2013 06:58:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 15EF221F9227 for ; Wed, 22 May 2013 06:58:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F9CB1F0A35; Wed, 22 May 2013 09:58:05 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6F3881F0A17; Wed, 22 May 2013 09:58:05 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 09:58:05 -0400 Message-ID: <519CCECE.4080609@mitre.org> Date: Wed, 22 May 2013 09:57:34 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130519170413.8755.15810.idtracker@ietfa.amsl.com> <0d3cddff70416885cef176fbb5fe7aef@lodderstedt-online.de> In-Reply-To: <0d3cddff70416885cef176fbb5fe7aef@lodderstedt-online.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-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: Wed, 22 May 2013 13:58:15 -0000 Nit: section 2.1, under "token type hint", the word "parameter" is repeated. Otherwise a quick read through looks good to me. -- Justin On 05/19/2013 01:07 PM, Torsten Lodderstedt wrote: > Hi all, > > this revision covers all minor issues from IETF LC. > > regards, > Torsten. > > Am 19.05.2013 19:04, schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> >> Title : OAuth 2.0 Token Revocation >> Author(s) : Torsten Lodderstedt >> Stefanie Dronia >> Marius Scurtescu >> Filename : draft-ietf-oauth-revocation-09.txt >> Pages : 10 >> Date : 2013-05-19 >> >> Abstract: >> This document proposes an additional endpoint for OAuth authorization >> servers, which allows clients to notify the authorization server that >> a previously obtained refresh or access token is no longer needed. >> This allows the authorization server to cleanup security credentials. >> A revocation request will invalidate the actual token and, if >> applicable, other tokens based on the same authorization grant. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-revocation-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-09 >> >> >> 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 eve@xmlgrrl.com Wed May 22 09:04:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE3621F86D3 for ; Wed, 22 May 2013 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.988 X-Spam-Level: X-Spam-Status: No, score=0.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONSin5eMngSD for ; Wed, 22 May 2013 09:04:39 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id BAAD421F9643 for ; Wed, 22 May 2013 09:04:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 4CAD014B6C59; Wed, 22 May 2013 09:04:27 -0700 (PDT) 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 Th0W0d6jhYKp; Wed, 22 May 2013 09:04:22 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 2150914B6C23; Wed, 22 May 2013 09:04:22 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8D0F9B2-233A-4D73-8FE3-A80E21C1629B" From: Eve Maler In-Reply-To: Date: Wed, 22 May 2013 09:04:21 -0700 Message-Id: References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org>, <4E1F6AAD24975D4BA5B168042967394367748E19@TK5EX14MBXC283.redmond.corp.microsoft.com>, <4E1F6AAD24975D4BA5B168042967394367749249@TK5EX14MBXC283.redmond.corp.microsoft.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Charter- was Re: Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 16:04:43 -0000 --Apple-Mail=_C8D0F9B2-233A-4D73-8FE3-A80E21C1629B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Coming in late to this thread: I agree broadly with Justin, Mike, and = John. Having an in-band just-in-time registration capability is = valuable. By analogy with user identifiers, it's useful for client = identifiers to be issued for the asking as the first rung of an = assurance (real-world identification/strong ongoing correlation) ladder. = UMA definitely needs this because it requires further, finer-grained = authorization to assign any significant access rights to clients and = their wielders ("requesting parties") -- getting a token is, by itself, = not very meaningful. If you want, you can consider this approach a = mitigation of the risks in issuing client IDs for the asking... Eve On 21 May 2013, at 1:28 PM, John Bradley wrote: > I agree with Mike, I don't think we are loosing anything, only = gaining. >=20 > I think it is a false statement to say that having multiple client = instances with the same client_id and secret is a feature. >=20 > In reality with public clients or public clients masquerading as = private ones the only real way for the AS to tell them apart in OAuth is = by redirect_uri. We are not changing that, though we are perhaps making = it cleaner that client_id for public clients can't be relied upon in any = way. Previously we had what was more or less assumed to be a one to = one mapping of client_id to redirect for native clients. >=20 > Once we start assigning unique client_id to instances of clients that = are all going to be using the same redirect_uri there are a lot of = question a AS has to decide, such as can two client_id register the same = redirect_uri? That could well cause all sorts of race conditions on the = device if you have two apps fighting over the same custom scheme. >=20 > So I think in reality the piece of information that a registration = server that is going to need to look at is the custom url scheme for = apps, probably disallowing multiple anonymous registrations for the = same custom scheme. =20 >=20 > Getting into the details of how app stores allocate schemes to = developers etc is out of scope for this spec. Someone can build = something more sophisticated on top of dynamic registration, but there = are a lot of issues outside of the simple how is a client registering = for a client_id and secret without forcing a manual step through a web = portal. >=20 > I honestly don't think adding some new application identifier solves = the problem. That information is in the redirect_uri for native apps, = and the problem doesn't exist for web server clients. >=20 > John B. >=20 > On 2013-05-21, at 2:28 PM, Mike Jones = wrote: >=20 >> What is the loss of information that you=E2=80=99re concerned about? = It seems odd to me that you=E2=80=99re asserting that there's = information loss when the operations performed by Dynamic Client = Registration are equivalent to those that are performed by out-of-band = OAuth developer portals today. It=E2=80=99s just automating a formerly = manual process. >> =20 >> -- Mike >> =20 >> =20 >> From: Phil Hunt >> Sent: =E2=80=8ETuesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E21=E2=80= =8E, =E2=80=8E2013 =E2=80=8E11=E2=80=8E:=E2=80=8E20=E2=80=8E =E2=80=8EAM >> To: Mike Jones >> Cc: Justin P. Richer, oauth@ietf.org WG >> =20 >> Mike, >>=20 >> There is an operational loss of information in the dynamic = registration spec. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> On 2013-05-21, at 10:52 AM, Mike Jones wrote: >>=20 >> No information is being thrown away. Developers can use dynamic = registration to obtain a client_id and then have all the client = instances use that client_id if they choose - just like they can do when = doing out-of-band registration with a site=E2=80=99s developer portal. = The only difference is that they don=E2=80=99t have to do out-of-band = registration anymore! >> =20 >> -- Mike >>=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_C8D0F9B2-233A-4D73-8FE3-A80E21C1629B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Eve

On 21 May = 2013, at 1:28 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

I agree with Mike, I don't think we are loosing = anything, only gaining.

I think it is a false = statement to say that having multiple client instances with the same = client_id and secret is a feature.

In reality = with public clients or public clients masquerading as private ones the = only real way for the AS to tell them apart in OAuth is by redirect_uri. =  We are not changing that, though we are perhaps making it cleaner = that client_id for public clients can't be relied upon in any way. =   Previously we had what was more or less assumed to be a one to = one mapping of client_id to redirect for native = clients.

Once we start assigning unique = client_id to instances of clients that are all going to be using the = same redirect_uri there are a lot of question a AS has to decide, such = as can two client_id register the same redirect_uri?  That could = well cause all sorts of race conditions on the device if you have two = apps fighting over the same custom scheme.

So I = think in reality the piece of information that a registration server = that is going to need to look at is the custom url scheme for apps, =  probably disallowing multiple anonymous registrations for the same = custom scheme.  

Getting into the details = of how app stores allocate schemes to developers etc is out of scope for = this spec.  Someone can build something more sophisticated on top = of dynamic registration, but there are a lot of issues outside of the = simple how is a client registering for a client_id and secret without = forcing a manual step through a web portal.

I = honestly don't think adding some new application identifier solves the = problem.  That information is in the redirect_uri for native apps, = and the problem doesn't exist for web server = clients.

John = B.

On 2013-05-21, at 2:28 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

 
 
Mike,

There is an = operational loss of information in the dynamic registration = spec.

www.independentid.com
phil.hunt@oracle.com
On = 2013-05-21, at 10:52 AM, Mike Jones wrote:

No information is being thrown away.  = Developers can use dynamic registration to obtain a client_id and then = have all the client instances use that client_id if they choose - just = like they can do when doing out-of-band registration with a = site=E2=80=99s developer portal.  The only difference is that they = don=E2=80=99t have to do out-of-band registration = anymore!
 
-- = Mike



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

= --Apple-Mail=_C8D0F9B2-233A-4D73-8FE3-A80E21C1629B-- From jricher@mitre.org Wed May 22 11:20:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03D321F8F61 for ; Wed, 22 May 2013 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uds9FaMxL6bN for ; Wed, 22 May 2013 11:20:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA221F8F09 for ; Wed, 22 May 2013 11:20:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A2021F0558 for ; Wed, 22 May 2013 14:20:28 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E6D261F0511 for ; Wed, 22 May 2013 14:20:27 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 14:20:27 -0400 Message-ID: <519D0C4D.60002@mitre.org> Date: Wed, 22 May 2013 14:19:57 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "oauth@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040307060206030802000200" X-Originating-IP: [129.83.31.56] Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 18:20:41 -0000 --------------040307060206030802000200 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Speaking as an implementor, I'm actually in favor of changing "expires_at" and "issued_at" to the values proposed below. It would require some minor code changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I think it will save us a lot of questions and headaches going forward. I believe that changing it now will have minimal impact on any deployed and running code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "B" for #1 and #2. I believe "token_endpoint_auth_method" is sufficient as is, since the client is the only thing that authenticates to the token endpoint. *[[ Note: As an editor, I don't believe it's really in my power to make that change unless there's support in the working group for making it. I **/really/**want more feedback from people, with explanation if you can. ]]** * -- Justin On 05/20/2013 11:09 AM, Justin Richer wrote: > Phil Hunt's review of the Dynamic Registration specification has > raised a couple of issues that I felt were getting buried by the > larger discussion (which I still strongly encourage others to jump in > to). Namely, Phil has suggested a couple of syntax changes to the > names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from developers* who have > deployed this draft spec, what we ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the parameter > *definitions* so that it's more clear to people reading the spec what > each piece does. Speaking as the editor: "A" is the default as far as > I'm concerned, since we shouldn't change syntax without very good > reason to do so. That said, if it's going to be better for developers > with the new parameter names, I am open to fixing them now. > > Naming things is hard. > > -- Justin > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040307060206030802000200 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Speaking as an implementor, I'm actually in favor of changing "expires_at" and "issued_at" to the values proposed below. It would require some minor code changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I think it will save us a lot of questions and headaches going forward. I believe that changing it now will have minimal impact on any deployed and running code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make that change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. ]]

 -- Justin


On 05/20/2013 11:09 AM, Justin Richer wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin


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

--------------040307060206030802000200-- From Michael.Jones@microsoft.com Wed May 22 11:30:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8C11E8106 for ; Wed, 22 May 2013 11:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNQLJbSCvx+Z for ; Wed, 22 May 2013 11:30:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id A402621F8D69 for ; Wed, 22 May 2013 11:30:23 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB012.protection.gbl (10.173.161.118) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 18:30:22 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 18:30:21 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 22 May 2013 18:30:06 +0000 From: Mike Jones To: Justin Richer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVxj2kVRUbqGmb0Chrsy2ymzpkpkRhUOw Date: Wed, 22 May 2013 18:30:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436774FFFA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <519D0C4D.60002@mitre.org> In-Reply-To: <519D0C4D.60002@mitre.org> 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_4E1F6AAD24975D4BA5B16804296739436774FFFATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(78114002)(189002)(51444003)(24454002)(479174002)(377454002)(54316002)(49866001)(74662001)(6806003)(16406001)(512954002)(16236675002)(31966008)(33656001)(53806001)(81342001)(4396001)(46102001)(44976003)(15202345002)(79102001)(47976001)(81542001)(55846006)(47736001)(47446002)(74502001)(54356001)(76482001)(51856001)(71186001)(56776001)(69226001)(74366001)(50986001)(74876001)(74706001)(20776003)(77982001)(80022001)(56816002)(63696002)(59766001)(65816001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB012; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 18:30:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436774FFFATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm neutral with changing (1) and (2) because they're not highly breaking c= hanges. These are optional parameters and code already has to be prepared = to not receive them and to ignore not understood parameters. If the change= is made, the result would be that existing implementations wouldn't receiv= e issuance and expiration times that they understand until they change thei= r code. That being said, the documentation for these parameters is already= clear, so I don't think that much confusion is likely to arise if we chang= e nothing. I am very strongly against changing (3) because this is truly a gratuitous = and fully breaking change. There's only thing that authenticates to token = endpoints - clients - and so adding "client_" to the name adds no semantic = or disambiguating value. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Wednesday, May 22, 2013 11:20 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Speaking as an implementor, I'm actually in favor of changing "expires_at" = and "issued_at" to the values proposed below. It would require some minor c= ode changes on my end, but the impact would be minimal, and I think that th= e new names are *much* more clear to new developers. I think it will save u= s a lot of questions and headaches going forward. I believe that changing i= t now will have minimal impact on any deployed and running code (there are = no large-scale services that I am aware of), and it will make things cleare= r. So I vote for "B" for #1 and #2. I believe "token_endpoint_auth_method" is sufficient as is, since the clien= t is the only thing that authenticates to the token endpoint. [[ Note: As an editor, I don't believe it's really in my power to make that= change unless there's support in the working group for making it. I really= want more feedback from people, with explanation if you can. ]] -- Justin On 05/20/2013 11:09 AM, Justin Richer wrote: Phil Hunt's review of the Dynamic Registration specification has raised a c= ouple of issues that I felt were getting buried by the larger discussion (w= hich I still strongly encourage others to jump in to). Namely, Phil has sug= gested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, especially from developers who have deployed thi= s draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* = so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned, since we = shouldn't change syntax without very good reason to do so. That said, if it= 's going to be better for developers with the new parameter names, I am ope= n to fixing them now. Naming things is hard. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436774FFFATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m neutral with ch= anging (1) and (2) because they’re not highly breaking changes. = These are optional parameters and code already has to be prepared to not receive them and to ignore not understood parameters.  If the change = is made, the result would be that existing implementations wouldn’t r= eceive issuance and expiration times that they understand until they change= their code.  That being said, the documentation for these parameters is already clear, so I don’t think that much co= nfusion is likely to arise if we change nothing.

 <= /p>

I am very strongly agains= t changing (3) because this is truly a gratuitous and fully breaking change= .  There’s only thing that authenticates to token endpoints – clients – and so adding “client_” to the name ad= ds no semantic or disambiguating value.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 11:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrat= ion

 

Speaking as an implem= entor, I'm actually in favor of changing "expires_at" and "i= ssued_at" to the values proposed below. It would require some minor co= de changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I thin= k it will save us a lot of questions and headaches going forward. I believe= that changing it now will have minimal impact on any deployed and running = code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "= B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since= the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make t= hat change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. = ]]

 -- Justin

On 05/20/2013 11:09 AM, Justin Richer wrote:

Phil Hunt's review of the Dynamic Registration speci= fication has raised a couple of issues that I felt were getting buried by t= he larger discussion (which I still strongly encourage others to jump in to= ). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deplo= yed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* = so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned,= since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for devel= opers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin



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

 

--_000_4E1F6AAD24975D4BA5B16804296739436774FFFATK5EX14MBXC283r_-- From phil.hunt@oracle.com Wed May 22 11:34:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25ED211E8132 for ; Wed, 22 May 2013 11:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg9WXaIjYRyJ for ; Wed, 22 May 2013 11:34:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D44A611E812E for ; Wed, 22 May 2013 11:34:29 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MIYSf7005669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 18:34:29 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MIYROB009481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 18:34:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MIYR56009475; Wed, 22 May 2013 18:34:27 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 May 2013 11:34:27 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3A387B37-A212-46F9-BA22-63356881F444" From: Phil Hunt In-Reply-To: <519D0C4D.60002@mitre.org> Date: Wed, 22 May 2013 11:34:32 -0700 Message-Id: References: <519D0C4D.60002@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 18:34:35 -0000 --Apple-Mail=_3A387B37-A212-46F9-BA22-63356881F444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 I also agree with Justin's comment on token_endpoint_auth_method. = Never-the-less, I did want to pass along the feedback that some were = confused. The expires_at, issued_at thing though is particularly confusing (though = the text may be clear) and is a higher priority issue in my opinion. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-22, at 11:19 AM, Justin Richer wrote: > Speaking as an implementor, I'm actually in favor of changing = "expires_at" and "issued_at" to the values proposed below. It would = require some minor code changes on my end, but the impact would be = minimal, and I think that the new names are *much* more clear to new = developers. I think it will save us a lot of questions and headaches = going forward. I believe that changing it now will have minimal impact = on any deployed and running code (there are no large-scale services that = I am aware of), and it will make things clearer. So I vote for "B" for = #1 and #2. >=20 > I believe "token_endpoint_auth_method" is sufficient as is, since the = client is the only thing that authenticates to the token endpoint.=20 >=20 >=20 > [[ Note: As an editor, I don't believe it's really in my power to make = that change unless there's support in the working group for making it. I = really want more feedback from people, with explanation if you can. ]] >=20 > -- Justin >=20 >=20 > On 05/20/2013 11:09 AM, Justin Richer wrote: >> Phil Hunt's review of the Dynamic Registration specification has = raised a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 >>=20 >>=20 >> 1) expires_at -> client_secret_expires_at >> 2) issued_at -> client_id_issued_at >> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >>=20 >>=20 >> I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these: >>=20 >> A) Keep the parameter names as-is >> B) Adopt the new names as above >> C) Adopt a new name that I will specify >>=20 >> In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. >>=20 >> Naming things is hard. >>=20 >> -- Justin >>=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=_3A387B37-A212-46F9-BA22-63356881F444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Phil

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





On 2013-05-22, at 11:19 AM, Justin Richer wrote:

=20 =20
Speaking as an implementor, I'm actually in favor of changing "expires_at" and "issued_at" to the values proposed below. It would require some minor code changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I think it will save us a lot of questions and headaches going forward. I believe that changing it now will have minimal impact on any deployed and running code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make that change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. ]]

 -- Justin


On 05/20/2013 11:09 AM, Justin Richer wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin


_______________________________________________
OAuth mailing 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=_3A387B37-A212-46F9-BA22-63356881F444-- From tonynad@microsoft.com Wed May 22 11:41:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC2E21F9346 for ; Wed, 22 May 2013 11:41:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLAYwbMDZEdm for ; Wed, 22 May 2013 11:40:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8421F9349 for ; Wed, 22 May 2013 11:40:54 -0700 (PDT) Received: from BN1AFFO11FD001.protection.gbl (10.58.52.201) by BN1BFFO11HUB024.protection.gbl (10.58.53.134) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 18:40:51 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD001.mail.protection.outlook.com (10.58.52.61) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 18:40:51 +0000 Received: from CO9EHSOBE006.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 22 May 2013 18:40:42 +0000 Received: from mail151-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 18:39:12 +0000 Received: from mail151-co9 (localhost [127.0.0.1]) by mail151-co9-R.bigfish.com (Postfix) with ESMTP id 9031D2A026C for ; Wed, 22 May 2013 18:39:12 +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: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh936eI1e83Mc857hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail151-co9: 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; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail151-co9 (localhost.localdomain [127.0.0.1]) by mail151-co9 (MessageSwitch) id 1369247949570102_21151; Wed, 22 May 2013 18:39:09 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.249]) by mail151-co9.bigfish.com (Postfix) with ESMTP id 8854360791; Wed, 22 May 2013 18:39:09 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 18:39: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.311.1; Wed, 22 May 2013 18:39:05 +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.698.13; Wed, 22 May 2013 18:39:02 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) with mapi id 15.00.0698.010; Wed, 22 May 2013 18:39:02 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWw2HOVR1MGBX02Be07cmNz/cpkOMHcAgAAH54CAAA6lAIAAGIDAgAAAQ4CAAytGAA== Date: Wed, 22 May 2013 18:39:02 +0000 Message-ID: <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> In-Reply-To: <519A6715.9040904@mitre.org> 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_148ab6ca581c49358e1ba8ecdbd791b3BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.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%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$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:(24454002)(189002)(479174002)(377454002)(377424003)(78114002)(199002)(512874002)(71186001)(81342001)(54316002)(46102001)(56816002)(56776001)(74366001)(16236675002)(81542001)(77982001)(59766001)(54356001)(74662001)(76482001)(47976001)(47446002)(74502001)(79102001)(31966008)(50986001)(4396001)(49866001)(47736001)(53806001)(69226001)(74316001)(74706001)(16676001)(15202345002)(74876001)(66066001)(63696002)(20776003)(80022001)(6806003)(33646001)(65816001)(51856001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB024; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 18:41:04 -0000 --_000_148ab6ca581c49358e1ba8ecdbd791b3BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28sIEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgZHluYW1pYyByZWdpc3RyYXRpb24g aXMgaW4gc2NvcGUsIEkgdW5kZXJzdGFuZCB0aGlzIHJlbGF0aXZlIHRvIE9wZW5JRCBDb25uZWN0 IGJ1dCBub3QgT0F1dGgsIGlmIHRoaXMgaXMgaW5kZWVkIGluIHNjb3BlIHRoZW4gSSB3b3VsZCBo YXZlIGV4cGVjdGVkIHRoYXQgdGhlIGVuZHBvaW50IGJlIGJhc2VkIHVwb24gU0NJTSBhbmQgbm90 IHNvbWV0aGluZyBlbHNlIGxpa2Ugd2hhdCBoYXMgYmVlbiBkb25lIGhlcmUuDQoNCkZyb206IEp1 c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10NClNlbnQ6IE1vbmRheSwgTWF5 IDIwLCAyMDEzIDExOjEwIEFNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogUGhpbCBIdW50OyBv YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUHJvcG9zZWQgU3ludGF4IENo YW5nZXMgaW4gRHluYW1pYyBSZWdpc3RyYXRpb24NCg0KVG9ueSwgY2FuIHlvdSBiZSBtb3JlIHNw ZWNpZmljPyBXaGF0IG5lZWRzIHRvIGJlIGNoYW5nZWQgaW4geW91ciBvcGluaW9uPyBXaGF0IHRl eHQgY2hhbmdlcyB3b3VsZCB5b3Ugc3VnZ2VzdD8NCg0KIC0tIEp1c3Rpbg0KT24gMDUvMjAvMjAx MyAwMjowOSBQTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KQWdyZWUNCg0KRnJvbTogb2F1dGgt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50DQpTZW50OiBNb25k YXksIE1heSAyMCwgMjAxMyA5OjQyIEFNDQpUbzogSnVzdGluIFJpY2hlcg0KQ2M6IG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFBy b3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFtaWMgUmVnaXN0cmF0aW9uDQoNClRoaXMgZHJh ZnQgaXNuJ3QgcmVhZHkgZm9yIExDLg0KDQpQaGlsDQoNCk9uIDIwMTMtMDUtMjAsIGF0IDg6NDks IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9y Zz4+IHdyb3RlOg0KQnV0IGFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhpcyBpcyBsYXN0LWNhbGws IGFuZCB0aGF0IHdlIGRvbid0IHJlYWxseSB3YW50IHRvIGVuY291cmFnZSBhdm9pZGFibGUgZHJh c3RpYyBjaGFuZ2VzIGF0IHRoaXMgc3RhZ2UuDQoNCiAtLSBKdXN0aW4NCg0KDQpPbiAwNS8yMC8y MDEzIDExOjIxIEFNLCBQaGlsIEh1bnQgd3JvdGU6DQpLZWVwIGluIG1pbmQgdGhlcmUgbWF5IGJl IG90aGVyIGNoYW5nZXMgY29taW5nLg0KDQpUaGUgaXNzdWUgaXMgdGhhdCBuZXcgZGV2ZWxvcGVy cyBjYW4ndCBmaWd1cmUgb3V0IHdoYXQgdG9rZW4gaXMgYmVpbmcgcmVmZXJyZWQgdG8uDQoNClBo aWwNCg0KT24gMjAxMy0wNS0yMCwgYXQgODowOSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRy ZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpQaGlsIEh1bnQncyByZXZp ZXcgb2YgdGhlIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gaGFzIHJhaXNlZCBh IGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBJIGZlbHQgd2VyZSBnZXR0aW5nIGJ1cmllZCBieSB0aGUg bGFyZ2VyIGRpc2N1c3Npb24gKHdoaWNoIEkgc3RpbGwgc3Ryb25nbHkgZW5jb3VyYWdlIG90aGVy cyB0byBqdW1wIGluIHRvKS4gTmFtZWx5LCBQaGlsIGhhcyBzdWdnZXN0ZWQgYSBjb3VwbGUgb2Yg c3ludGF4IGNoYW5nZXMgdG8gdGhlIG5hbWVzIG9mIHNldmVyYWwgcGFyYW1ldGVycy4NCg0KDQox KSBleHBpcmVzX2F0IC0+IGNsaWVudF9zZWNyZXRfZXhwaXJlc19hdA0KMikgaXNzdWVkX2F0IC0+ IGNsaWVudF9pZF9pc3N1ZWRfYXQNCjMpIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIC0+IHRv a2VuX2VuZHBvaW50X2NsaWVudF9hdXRoX21ldGhvZA0KDQoNCkknZCBsaWtlIHRvIGdldCBhIGZl ZWxpbmcsIGVzcGVjaWFsbHkgZnJvbSBkZXZlbG9wZXJzIHdobyBoYXZlIGRlcGxveWVkIHRoaXMg ZHJhZnQgc3BlYywgd2hhdCB3ZSBvdWdodCB0byBkbyBmb3IgZWFjaCBvZiB0aGVzZToNCg0KIEEp IEtlZXAgdGhlIHBhcmFtZXRlciBuYW1lcyBhcy1pcw0KIEIpIEFkb3B0IHRoZSBuZXcgbmFtZXMg YXMgYWJvdmUNCiBDKSBBZG9wdCBhIG5ldyBuYW1lIHRoYXQgSSB3aWxsIHNwZWNpZnkNCg0KSW4g YWxsIGNhc2VzLCBjbGFyaWZ5aW5nIHRleHQgd2lsbCBiZSBhZGRlZCB0byB0aGUgcGFyYW1ldGVy ICpkZWZpbml0aW9ucyogc28gdGhhdCBpdCdzIG1vcmUgY2xlYXIgdG8gcGVvcGxlIHJlYWRpbmcg dGhlIHNwZWMgd2hhdCBlYWNoIHBpZWNlIGRvZXMuIFNwZWFraW5nIGFzIHRoZSBlZGl0b3I6ICJB IiBpcyB0aGUgZGVmYXVsdCBhcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwgc2luY2Ugd2Ugc2hvdWxk bid0IGNoYW5nZSBzeW50YXggd2l0aG91dCB2ZXJ5IGdvb2QgcmVhc29uIHRvIGRvIHNvLiBUaGF0 IHNhaWQsIGlmIGl0J3MgZ29pbmcgdG8gYmUgYmV0dGVyIGZvciBkZXZlbG9wZXJzIHdpdGggdGhl IG5ldyBwYXJhbWV0ZXIgbmFtZXMsIEkgYW0gb3BlbiB0byBmaXhpbmcgdGhlbSBub3cuDQoNCk5h bWluZyB0aGluZ3MgaXMgaGFyZC4NCg0KIC0tIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KDQoNCg== --_000_148ab6ca581c49358e1ba8ecdbd791b3BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIEkg cmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgZHluYW1pYyByZWdpc3RyYXRpb24gaXMgaW4g c2NvcGUsIEkgdW5kZXJzdGFuZCB0aGlzIHJlbGF0aXZlIHRvIE9wZW5JRCBDb25uZWN0IGJ1dCBu b3QgT0F1dGgsIGlmIHRoaXMgaXMgaW5kZWVkIGluIHNjb3BlIHRoZW4NCiBJIHdvdWxkIGhhdmUg ZXhwZWN0ZWQgdGhhdCB0aGUgZW5kcG9pbnQgYmUgYmFzZWQgdXBvbiBTQ0lNIGFuZCBub3Qgc29t ZXRoaW5nIGVsc2UgbGlrZSB3aGF0IGhhcyBiZWVuIGRvbmUgaGVyZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyAxMToxMCBBTTxicj4NCjxi PlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBQaGlsIEh1bnQ7IG9hdXRo QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5 bnRheCBDaGFuZ2VzIGluIER5bmFtaWMgUmVnaXN0cmF0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5U b255LCBjYW4geW91IGJlIG1vcmUgc3BlY2lmaWM/IFdoYXQgbmVlZHMgdG8gYmUgY2hhbmdlZCBp biB5b3VyIG9waW5pb24/IFdoYXQgdGV4dCBjaGFuZ2VzIHdvdWxkIHlvdSBzdWdnZXN0Pzxicj4N Cjxicj4NCiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDA1LzIwLzIwMTMgMDI6MDkgUE0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBo aWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyA5OjQyIEFNPGJy Pg0KPGI+VG86PC9iPiBKdXN0aW4gUmljaGVyPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lz dHJhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGRyYWZ0IGlzbid0IHJlYWR5IGZvciBMQy4mbmJzcDs8YnI+DQo8YnI+DQpQaGls PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIwMTMtMDUtMjAsIGF0IDg6NDksIEp1 c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+anJpY2hl ckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CdXQg YWxzbyBrZWVwIGluIG1pbmQgdGhhdCB0aGlzIGlzIGxhc3QtY2FsbCwgYW5kIHRoYXQgd2UgZG9u J3QgcmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIGF2b2lkYWJsZSBkcmFzdGljIGNoYW5nZXMgYXQg dGhpcyBzdGFnZS4NCjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzIwLzIw MTMgMTE6MjEgQU0sIFBoaWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VlcCBpbiBtaW5kIHRoZXJlIG1heSBiZSBvdGhl ciBjaGFuZ2VzIGNvbWluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlzIHRoYXQgbmV3IGRldmVsb3BlcnMgY2Fu J3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5nIHJlZmVycmVkIHRvLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhp bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMDEzLTA1LTIwLCBhdCA4OjA5LCBK dXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNo ZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWwgSHVudCdzIHJldmlldyBvZiB0aGUgRHluYW1p YyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiBoYXMgcmFpc2VkIGEgY291cGxlIG9mIGlzc3Vl cyB0aGF0IEkgZmVsdCB3ZXJlIGdldHRpbmcgYnVyaWVkIGJ5IHRoZSBsYXJnZXIgZGlzY3Vzc2lv biAod2hpY2ggSSBzdGlsbCBzdHJvbmdseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIGp1bXAgaW4gdG8p LiBOYW1lbHksIFBoaWwgaGFzIHN1Z2dlc3RlZCBhIGNvdXBsZQ0KIG9mIHN5bnRheCBjaGFuZ2Vz IHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFsIHBhcmFtZXRlcnMuIDxicj4NCjxicj4NCjxicj4NCjEp IGV4cGlyZXNfYXQgLSZndDsgY2xpZW50X3NlY3JldF9leHBpcmVzX2F0PGJyPg0KMikgaXNzdWVk X2F0IC0mZ3Q7IGNsaWVudF9pZF9pc3N1ZWRfYXQ8YnI+DQozKSB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZCAtJmd0OyB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2Q8YnI+DQo8YnI+ DQo8YnI+DQpJJ2QgbGlrZSB0byBnZXQgYSBmZWVsaW5nLCA8Yj5lc3BlY2lhbGx5IGZyb20gZGV2 ZWxvcGVyczwvYj4gd2hvIGhhdmUgZGVwbG95ZWQgdGhpcyBkcmFmdCBzcGVjLCB3aGF0IHdlIG91 Z2h0IHRvIGRvIGZvciBlYWNoIG9mIHRoZXNlOjxicj4NCjxicj4NCiZuYnNwO0EpIEtlZXAgdGhl IHBhcmFtZXRlciBuYW1lcyBhcy1pczxicj4NCiZuYnNwO0IpIEFkb3B0IHRoZSBuZXcgbmFtZXMg YXMgYWJvdmU8YnI+DQombmJzcDtDKSBBZG9wdCBhIG5ldyBuYW1lIHRoYXQgSSB3aWxsIHNwZWNp Znk8YnI+DQo8YnI+DQpJbiBhbGwgY2FzZXMsIGNsYXJpZnlpbmcgdGV4dCB3aWxsIGJlIGFkZGVk IHRvIHRoZSBwYXJhbWV0ZXIgKmRlZmluaXRpb25zKiBzbyB0aGF0IGl0J3MgbW9yZSBjbGVhciB0 byBwZW9wbGUgcmVhZGluZyB0aGUgc3BlYyB3aGF0IGVhY2ggcGllY2UgZG9lcy4gU3BlYWtpbmcg YXMgdGhlIGVkaXRvcjogJnF1b3Q7QSZxdW90OyBpcyB0aGUgZGVmYXVsdCBhcyBmYXIgYXMgSSdt IGNvbmNlcm5lZCwgc2luY2Ugd2Ugc2hvdWxkbid0IGNoYW5nZSBzeW50YXggd2l0aG91dA0KIHZl cnkgZ29vZCByZWFzb24gdG8gZG8gc28uIFRoYXQgc2FpZCwgaWYgaXQncyBnb2luZyB0byBiZSBi ZXR0ZXIgZm9yIGRldmVsb3BlcnMgd2l0aCB0aGUgbmV3IHBhcmFtZXRlciBuYW1lcywgSSBhbSBv cGVuIHRvIGZpeGluZyB0aGVtIG5vdy48YnI+DQo8YnI+DQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQu PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_148ab6ca581c49358e1ba8ecdbd791b3BY2PR03MB041namprd03pro_-- From phil.hunt@oracle.com Wed May 22 11:46:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97A21F9662 for ; Wed, 22 May 2013 11:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.093 X-Spam-Level: X-Spam-Status: No, score=-6.093 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWmZt8GbgBIa for ; Wed, 22 May 2013 11:46:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1159521F964C for ; Wed, 22 May 2013 11:46:54 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MIkqqI018828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 18:46:53 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MIkqd5013126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 18:46:52 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MIkq64010080; Wed, 22 May 2013 18:46:52 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 May 2013 11:46:51 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FB773235-1198-437C-AA5B-28741E3B6973" From: Phil Hunt In-Reply-To: <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> Date: Wed, 22 May 2013 11:46:58 -0700 Message-Id: <50082DCE-5901-4CEC-B813-F471F1706D6B@oracle.com> References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Dyn Reg API Style: Was Re: Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 18:46:59 -0000 --Apple-Mail=_FB773235-1198-437C-AA5B-28741E3B6973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Let's make a new thread for this. It is worth some discussion. We have some strong cases for this, and I do think dyn reg involves some = credential management issues that SCIM doesn't yet handle. I think Justin is planning to make these aspects more clear in the = draft. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-22, at 11:39 AM, Anthony Nadalin wrote: > So, I really don=92t understand why dynamic registration is in scope, = I understand this relative to OpenID Connect but not OAuth, if this is = indeed in scope then I would have expected that the endpoint be based = upon SCIM and not something else like what has been done here. > =20 > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Monday, May 20, 2013 11:10 AM > To: Anthony Nadalin > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration > =20 > Tony, can you be more specific? What needs to be changed in your = opinion? What text changes would you suggest? >=20 > -- Justin >=20 > On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > Agree > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Monday, May 20, 2013 9:42 AM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration > =20 > This draft isn't ready for LC.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:49, Justin Richer wrote: >=20 > But also keep in mind that this is last-call, and that we don't really = want to encourage avoidable drastic changes at this stage.=20 >=20 > -- Justin >=20 >=20 >=20 > On 05/20/2013 11:21 AM, Phil Hunt wrote: > Keep in mind there may be other changes coming.=20 > =20 > The issue is that new developers can't figure out what token is being = referred to.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:09, Justin Richer wrote: >=20 > Phil Hunt's review of the Dynamic Registration specification has = raised a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 >=20 >=20 > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >=20 >=20 > I'd like to get a feeling, especially from developers who have = deployed this draft spec, what we ought to do for each of these: >=20 > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify >=20 > In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. >=20 > Naming things is hard. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail=_FB773235-1198-437C-AA5B-28741E3B6973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Let's = make a new thread for this.  It is worth some = discussion.

We have some strong cases for this, = and I do think dyn reg involves some credential management issues that = SCIM doesn't yet handle.

I think Justin is = planning to make these aspects more clear in the = draft.

Phil

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





On 2013-05-22, at 11:39 AM, Anthony Nadalin = wrote:

So, I = really don=92t understand why dynamic registration is in scope, I = understand this relative to OpenID Connect but not OAuth, if this is = indeed in scope then I would have expected that the endpoint be based = upon SCIM and not something else like what has been done = here.
On 05/20/2013 = 02:09 PM, Anthony Nadalin wrote:
Agree
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Monday, May 20, 2013 9:42 = AM
To: Justin = Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed = Syntax Changes in Dynamic = Registration
This draft = isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, = Justin Richer <jricher@mitre.org> = wrote:

 

 -- = Justin


On = 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes = coming. 
The issue = is that new developers can't figure out what token is being referred = to. 

On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> = wrote:

Phil Hunt's = review of the Dynamic Registration specification has raised a couple of = issues that I felt were getting buried by the larger discussion (which I = still strongly encourage others to jump in to). Namely, Phil has = suggested a couple of syntax changes to the names of several = parameters. 


1) expires_at = -> client_secret_expires_at
2) issued_at -> = client_id_issued_at
3) token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a = feeling, especially = from developers who = have deployed this draft spec, what we ought to do for each of = these:

 A) Keep the parameter names as-is
 B) Adopt = the new names as above
 C) Adopt a new name that I will = specify

In all cases, clarifying text will be added to the = parameter *definitions* so that it's more clear to people reading the = spec what each piece does. Speaking as the editor: "A" is the default as = far as I'm concerned, since we shouldn't change syntax without very good = reason to do so. That said, if it's going to be better for developers = with the new parameter names, I am open to fixing them = now.

Naming things is hard.

 -- = Justin
OAuth@ietf.org
To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 19:59:16 -0000 --Apple-Mail=_48714CB9-4636-4755-9071-BD7A45252B79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I had a conversation with Justin yesterday to try to come to a = resolution regarding my concerns about client instances and being able = to associate client instances that are issued for the same client = software. I think we made some progress. Background: =20 In RFC6749, public clients, had a common client_id. Many interpreted = client_id as refering to the client application software (e.g. the = iPhone Facebook app). This is probably due to the types of OAuth2 = implementations that existed at the time, where there was a single SP = instance. Others have interpreted that client_id does not refer to = client applications but rather ideally should point to instances of = software. To me this seems like equating a client_id to being a user-id = -- IOW the key part of a credential rather than a client identifier.=20 The new draft proposes that each instance be identified separately. = However it does so without keeping track of client software that is the = same. Never-the-less, I think both interpretations can be accommodated. Finally, in single instance services (like Facebook, Twitter, etc), = there was a natural registration and approval cycle bound into the = client_id issuance process. The developer was able to talk to the single = service provider and obtain a client_id for all deployments. It wasn't = stated, but the client_id registration sites served a useful way to do = application approvals. This is a difficult problem to solve when there = are multiple instance of Resource API deployed in multiple locations. = The developer can't contact them all. Further, because the current = draft loses knowledge of how to recognize that two instances of clients = share the same software, there's no ability to have an approval process. = Each instance is essentially anonymous, and thus approval processes = would not be possible. Though it does not require it, this proposal = makes it possible for service providers to recognize new software and to = have approval process. Proposal: What I have worked out with Justin (and he may not yet fully agree with = everything) is a proposal that solves the problem in an optional way = that will not break existing clients.=20 I also propose that optional version numbers also be supported. This is = useful to service providers who need to know which client_ids are = affected when certain software clients and/or versions are deprecated. = The re-introduction of the renamed software_id further enables "local" = registration to occur. The first time a client tries to register, a = service provider could for example, choose to hold the registration to = obtain administrative approval. The solution here is not intended to provide software "authentication" = or software verification. The solution simply allows service providers = to make pragmatic decisions about sets of clients that typically work = the same way in a change managed environment.=20 Question: What happens if the server does not support these new = parameters and the client provides them? The current draft already = covers this in Section 3. Specifically: > The Client Registration Endpoint MUST ignore all parameters it does = not understand. Below are 3 options for the group to consider. My recommendation is for = option 1. My concern is option 2 will lead to complexity because clients = and service providers will attempt to encode versions and software = identifiers into one field. I would rather keep this to simple UUIDs for = most cases. Option 1 (2 parameters): software_id This value MAY be required by registration endpoints. The value MAY be a = unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD NOT change between software updates. While a = client application MAY be issued multiple client_id's and client = credentials over its deployment lifecycle, the software_id SHOULD NOT = change. Signed assertions MAY be used as software identifiers to allow different = dynamic registration end-points to recognize approval from a common = issuer (for example in cases where the resource API released by a single = publisher but deployed in many different domains). The decision to use = assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. [editorial note: some current deployments are using temporary client = credential assertions for this purpose. I propose to standardize this in = this field since an assertion would server the same purpose as a UUID = only providing third party signing and other claims. I am concerned that = passing a client assertion for this purpose creates complexity in client = authentication processing - though obviously Justin has it working] software_version RECOMMENDED. A version indicates a client developer chosen version = number. The identifier SHOULD BE the same across all copies of client = software. The version number SHOULD change between different client = updates. The intention is that Service Providers MAY perform equality = matching with software_id to sub-select groups of clients of a = particular software version. Option 2 (single parameter): software_id This value MAY be required by registration endpoints. The value MAY be a = unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD change when the client software has changed = such as with a version update or a platform change. Signed assertions MAY be used as software identifiers to allow different = dynamic registration end-points to recognize approval from a common = issuer (for example in cases where the resource API released by a single = publisher but deployed in many different domains). The decision to use = assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. [note: same editorial note as option 1] Option 3 (no change): In this option, no changes to the draft are made.=20 Personal comment: It has been proposed by several on the list that = another extension draft be written for these features as an extension to = the dynamic registration draft. In my opinion, such a draft would be = very small in size without clear reason for separation. My feeling is = that some technical justification for keeping these features separated = will likely be needed. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_48714CB9-4636-4755-9071-BD7A45252B79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I had = a conversation with Justin yesterday to try to come to a resolution = regarding my concerns about client instances and being able to associate = client instances that are issued for the same client software. I think = we made some progress.

Background: =  
In RFC6749, public clients, had a common = client_id. Many interpreted client_id as refering to the client = application software (e.g. the iPhone Facebook app). This is probably = due to the types of OAuth2 implementations that existed at the time, = where there was a single SP instance.  Others have interpreted that = client_id does not refer to client applications but rather ideally = should point to instances of software. To me this seems like equating a = client_id to being a user-id -- IOW the key part of a credential rather = than a client identifier. 

The new draft = proposes that each instance be identified separately. However it does so = without keeping track of client software that is the = same.

Never-the-less, I think both = interpretations can be = accommodated.

Finally, in single instance = services (like Facebook, Twitter, etc), there was a natural registration = and approval cycle bound into the client_id issuance process. The = developer was able to talk to the single service provider and obtain a = client_id for all deployments. It wasn't stated, but the client_id = registration sites served a useful way to do application approvals. =  This is a difficult problem to solve when there are multiple = instance of Resource API deployed in multiple locations. The developer = can't contact them all.  Further, because the current draft loses = knowledge of how to recognize that two instances of clients share the = same software, there's no ability to have an approval process. Each = instance is essentially anonymous, and thus approval processes would not = be possible.  Though it does not require it, this proposal makes it = possible for service providers to recognize new software and to have = approval = process.

Proposal:
= What I have worked out with Justin (and he may not yet fully agree with = everything) is a proposal that solves the problem in an optional way = that will not break existing clients. 

I = also propose that optional version numbers also be supported. This is = useful to service providers who need to know which client_ids are = affected when certain software clients and/or versions are deprecated. = The re-introduction of the renamed software_id further enables "local" = registration to occur. The first time a client tries to register, a = service provider could for example, choose to hold the registration to = obtain administrative approval.

The solution = here is not intended to provide software "authentication" or software = verification. The solution simply allows service providers to make = pragmatic decisions about sets of clients that typically work the same = way in a change managed = environment. 

Question:  What happens = if the server does not support these new parameters and the client = provides them?  The current draft already covers this in Section 3. =  Specifically:
 The Client =
Registration Endpoint MUST ignore all parameters it does not =
understand.

Below are 3 = options for the group to consider.  My recommendation is for option = 1. My concern is option 2 will lead to complexity because clients and = service providers will attempt to encode versions and software = identifiers into one field. I would rather keep this to simple UUIDs for = most cases.

Option 1 (2 = parameters):

software_id
This value MAY be required by registration = endpoints. The value MAY be a unique identifier (UUID) self-assigned by = a the client application developer, or it MAY be an assertion. The value = SHOULD be the same across all instances of a client on an application = platform. For example, software used in a = mobile phone should be considered as different from a web server = implementation though it may share the same code. The = identifier SHOULD NOT change between software = updates. While a client application MAY be issued multiple = client_id's and client credentials over its deployment lifecycle, the = software_id SHOULD NOT change.

Signed assertions MAY be used as software = identifiers to allow different dynamic registration end-points to = recognize approval from a common issuer (for example in cases where the = resource API released by a single publisher but deployed in many = different domains). The decision to use assertions and the method by = which developers know how to obtain assertions is out of scope for this = specification.

[editorial note: some current deployments are using = temporary client credential assertions for this purpose. I propose to = standardize this in this field since an assertion would server the same = purpose as a UUID only providing third party signing and other claims. I = am concerned that passing a client assertion for this purpose creates = complexity in client authentication processing - though obviously Justin = has it working]

software_version
RECOMMENDED. A version indicates a client = developer chosen version number. The identifier SHOULD BE the same = across all copies of client software. The version number SHOULD change = between different client updates. The intention is that Service = Providers MAY perform equality matching with software_id to sub-select = groups of clients of a particular software = version.

Option = 2 (single parameter):

software_id
This value MAY = be required by registration endpoints. The value MAY be a unique = identifier (UUID) self-assigned by a the client application developer, = or it MAY be an assertion. The value SHOULD be the same across all = instances of a client on an application platform. For example, software = used in a mobile phone should be considered as different from a web = server implementation though it may share the same code. The = identifier SHOULD change when the client software has = changed such as with a version update or a platform = change.
Signed = assertions MAY be used as software identifiers to allow different = dynamic registration end-points to recognize approval from a common = issuer (for example in cases where the resource API released by a single = publisher but deployed in many different domains). The decision to use = assertions and the method by which developers know how to obtain = assertions is out of scope for this = specification.

[note: same editorial note as option = 1]

Option 3 (no = change):

In this option, no changes to the = draft are made. 

Personal comment: =  It has been proposed by several on the list that another extension = draft be written for these features as an extension to the dynamic = registration draft. In my opinion, such a draft would be very small in = size without clear reason for separation. My feeling is that some = technical justification for keeping these features separated will likely = be needed.


= --Apple-Mail=_48714CB9-4636-4755-9071-BD7A45252B79-- From jricher@mitre.org Wed May 22 13:35:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD6411E80FB for ; Wed, 22 May 2013 13:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD2C+EKrpB5w for ; Wed, 22 May 2013 13:35:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 69A8611E80A2 for ; Wed, 22 May 2013 13:35:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B5FC91F030F; Wed, 22 May 2013 16:35:15 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 995321F027D; Wed, 22 May 2013 16:35:15 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 16:35:15 -0400 Message-ID: <519D2BE4.6080303@mitre.org> Date: Wed, 22 May 2013 16:34:44 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Anthony Nadalin References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------050706030307080307060005" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 20:35:23 -0000 --------------050706030307080307060005 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I'm not sure why you don't think it's in scope, it's in the working group's charter: http://www.ietf.org/dyn/wg/charter/oauth-charter.html So ... it's definitely in scope, and has been for over a year and a half. This is the tenth version of this document-- an IETF Working Group document at that-- that's been posted to the group with every revision and there has been significant conversation around it, especially over the last six months since I took over the editor role. There are also a handful of implementations of this, and while most of them are built to do OpenID Connect or UMA (which are directly built on OAuth), I know there are some that also do plain OAuth. (Not the least of which is one that I have personally implemented and deployed.) SCIM doesn't solve client management particularly well, since it's made for users more than anything. The usage model of SCIM is also quite different -- it's really intended to be used between two servers to transfer information, as opposed to handling self-asserted claims. I understand that some implementations like UAA have done their static registration using a SCIM profile, but it's not dynamic registration, really. I think it's too much of a square-peg-round-hole problem, at least with SCIM as it is today; so let SCIM do what it's good at, and don't try to force it into something it's not. Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic Registration was meant to be a fairly simple REST/JSON API that would be easy to implement, especially for clients. Just because SCIM is RESTful doesn't mean it's a good structure for other RESTful APIs. Namely, I don't think the extra structure and hooks with SCIM really buy you anything here, especially with the additions and changes you'd have to make to SCIM. And finally, nobody to date has actually written a proposal that is even remotely SCIM based. -- Justin On 05/22/2013 02:39 PM, Anthony Nadalin wrote: > > So, I really don’t understand why dynamic registration is in scope, I > understand this relative to OpenID Connect but not OAuth, if this is > indeed in scope then I would have expected that the endpoint be based > upon SCIM and not something else like what has been done here. > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, May 20, 2013 11:10 AM > *To:* Anthony Nadalin > *Cc:* Phil Hunt; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > Tony, can you be more specific? What needs to be changed in your > opinion? What text changes would you suggest? > > -- Justin > > On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > > Agree > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Monday, May 20, 2013 9:42 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic > Registration > > This draft isn't ready for LC. > > Phil > > > On 2013-05-20, at 8:49, Justin Richer > wrote: > > But also keep in mind that this is last-call, and that we > don't really want to encourage avoidable drastic changes at > this stage. > > -- Justin > > > On 05/20/2013 11:21 AM, Phil Hunt wrote: > > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out what > token is being referred to. > > > Phil > > > On 2013-05-20, at 8:09, Justin Richer > wrote: > > Phil Hunt's review of the Dynamic Registration > specification has raised a couple of issues that I > felt were getting buried by the larger discussion > (which I still strongly encourage others to jump in > to). Namely, Phil has suggested a couple of syntax > changes to the names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> > token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from > developers* who have deployed this draft spec, what we > ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the > parameter *definitions* so that it's more clear to > people reading the spec what each piece does. Speaking > as the editor: "A" is the default as far as I'm > concerned, since we shouldn't change syntax without > very good reason to do so. That said, if it's going to > be better for developers with the new parameter names, > I am open to fixing them now. > > Naming things is hard. > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------050706030307080307060005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I'm not sure why you don't think it's in scope, it's in the working group's charter:

  http://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a half. This is the tenth version of this document-- an IETF Working Group document at that-- that's been posted to the group with every revision and there has been significant conversation around it, especially over the last six months since I took over the editor role. There are also a handful of implementations of this, and while most of them are built to do OpenID Connect or UMA (which are directly built on OAuth), I know there are some that also do plain OAuth. (Not the least of which is one that I have personally implemented and deployed.)

SCIM doesn't solve client management particularly well, since it's made for users more than anything. The usage model of SCIM is also quite different -- it's really intended to be used between two servers to transfer information, as opposed to handling self-asserted claims. I understand that some implementations like UAA have done their static registration using a SCIM profile, but it's not dynamic registration, really. I think it's too much of a square-peg-round-hole problem, at least with SCIM as it is today; so let SCIM do what it's good at, and don't try to force it into something it's not.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic Registration was meant to be a fairly simple REST/JSON API that would be easy to implement, especially for clients. Just because SCIM is RESTful doesn't mean it's a good structure for other RESTful APIs. Namely, I don't think the extra structure and hooks with SCIM really buy you anything here, especially with the additions and changes you'd have to make to SCIM.

And finally, nobody to date has actually written a proposal that is even remotely SCIM based.

 -- Justin

On 05/22/2013 02:39 PM, Anthony Nadalin wrote:

So, I really don’t understand why dynamic registration is in scope, I understand this relative to OpenID Connect but not OAuth, if this is indeed in scope then I would have expected that the endpoint be based upon SCIM and not something else like what has been done here.

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

Tony, can you be more specific? What needs to be changed in your opinion? What text changes would you suggest?

 -- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin wrote:

Agree

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 

 


--------------050706030307080307060005-- From jricher@mitre.org Wed May 22 13:38:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B911E80FB for ; Wed, 22 May 2013 13:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM795fL9V76k for ; Wed, 22 May 2013 13:38:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0811E80A2 for ; Wed, 22 May 2013 13:38:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CD931F04E4; Wed, 22 May 2013 16:38:33 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 592E41F047A; Wed, 22 May 2013 16:38:33 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 16:38:33 -0400 Message-ID: <519D2CAA.70306@mitre.org> Date: Wed, 22 May 2013 16:38:02 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <50082DCE-5901-4CEC-B813-F471F1706D6B@oracle.com> In-Reply-To: <50082DCE-5901-4CEC-B813-F471F1706D6B@oracle.com> Content-Type: multipart/alternative; boundary="------------030307000901040609070507" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dyn Reg API Style: Was Re: Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 20:38:39 -0000 --------------030307000901040609070507 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit I answered some of this in my reply to Tony already, but from my perspective it boils down to SCIM not really being that great of a fit for this kind of use. It makes very different assumptions about who's undertaking all of the actions, and those assumptions (which are completely valid assumptions, mind you) are baked into what the spec does and how it works. From what I understand of how SCIM works, you'd have to jump through some interesting hoops to get to the self-managed registration using SCIM as it's defined today, or even as it could be defined. There are profiles of using SCIM to transfer information about registered clients between AS's in different security domains (or different instances), but that's not dynamic registration. Someone can feel free to correct me if I'm completely off the rails here. (Won't be the first time. :) ) I say let's just keep letting SCIM be good at what it's good at and not try to squish it into something it's not. -- Justin On 05/22/2013 02:46 PM, Phil Hunt wrote: > Let's make a new thread for this. It is worth some discussion. > > We have some strong cases for this, and I do think dyn reg involves > some credential management issues that SCIM doesn't yet handle. > > I think Justin is planning to make these aspects more clear in the draft. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-22, at 11:39 AM, Anthony Nadalin wrote: > >> So, I really dont understand why dynamic registration is in scope, I >> understand this relative to OpenID Connect but not OAuth, if this is >> indeed in scope then I would have expected that the endpoint be based >> upon SCIM and not something else like what has been done here. >> *From:*Justin Richer [mailto:jricher@mitre.org] >> *Sent:*Monday, May 20, 2013 11:10 AM >> *To:*Anthony Nadalin >> *Cc:*Phil Hunt; oauth@ietf.org >> *Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration >> >> Tony, can you be more specific? What needs to be changed in your >> opinion? What text changes would you suggest? >> >> -- Justin >> >> On 05/20/2013 02:09 PM, Anthony Nadalin wrote: >> >> Agree >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org]*On >> Behalf Of*Phil Hunt >> *Sent:*Monday, May 20, 2013 9:42 AM >> *To:*Justin Richer >> *Cc:*oauth@ietf.org >> *Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic >> Registration >> This draft isn't ready for LC. >> >> Phil >> >> >> On 2013-05-20, at 8:49, Justin Richer > > wrote: >> >> But also keep in mind that this is last-call, and that we >> don't really want to encourage avoidable drastic changes at >> this stage. >> >> -- Justin >> >> >> On 05/20/2013 11:21 AM, Phil Hunt wrote: >> >> Keep in mind there may be other changes coming. >> The issue is that new developers can't figure out what >> token is being referred to. >> >> Phil >> >> >> On 2013-05-20, at 8:09, Justin Richer > > wrote: >> >> Phil Hunt's review of the Dynamic Registration >> specification has raised a couple of issues that I >> felt were getting buried by the larger discussion >> (which I still strongly encourage others to jump in >> to). Namely, Phil has suggested a couple of syntax >> changes to the names of several parameters. >> >> >> 1) expires_at -> client_secret_expires_at >> 2) issued_at -> client_id_issued_at >> 3) token_endpoint_auth_method -> >> token_endpoint_client_auth_method >> >> >> I'd like to get a feeling,*especially from >> developers*who have deployed this draft spec, what we >> ought to do for each of these: >> >> A) Keep the parameter names as-is >> B) Adopt the new names as above >> C) Adopt a new name that I will specify >> >> In all cases, clarifying text will be added to the >> parameter *definitions* so that it's more clear to >> people reading the spec what each piece does. >> Speaking as the editor: "A" is the default as far as >> I'm concerned, since we shouldn't change syntax >> without very good reason to do so. That said, if it's >> going to be better for developers with the new >> parameter names, I am open to fixing them now. >> >> Naming things is hard. >> >> -- Justin >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --------------030307000901040609070507 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit I answered some of this in my reply to Tony already, but from my perspective it boils down to SCIM not really being that great of a fit for this kind of use. It makes very different assumptions about who's undertaking all of the actions, and those assumptions (which are completely valid assumptions, mind you) are baked into what the spec does and how it works. From what I understand of how SCIM works, you'd have to jump through some interesting hoops to get to the self-managed registration using SCIM as it's defined today, or even as it could be defined. There are profiles of using SCIM to transfer information about registered clients between AS's in different security domains (or different instances), but that's not dynamic registration. Someone can feel free to correct me if I'm completely off the rails here. (Won't be the first time. :) )

I say let's just keep letting SCIM be good at what it's good at and not try to squish it into something it's not.

-- Justin

On 05/22/2013 02:46 PM, Phil Hunt wrote:
Let's make a new thread for this. It is worth some discussion.

We have some strong cases for this, and I do think dyn reg involves some credential management issues that SCIM doesn't yet handle.

I think Justin is planning to make these aspects more clear in the draft.


On 2013-05-22, at 11:39 AM, Anthony Nadalin wrote:

So, I really dont understand why dynamic registration is in scope, I understand this relative to OpenID Connect but not OAuth, if this is indeed in scope then I would have expected that the endpoint be based upon SCIM and not something else like what has been done here.
From:Justin Richer [mailto:jricher@mitre.org]
Sent:Monday, May 20, 2013 11:10 AM
To:Anthony Nadalin
Cc:Phil Hunt; oauth@ietf.org
Subject:Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Tony, can you be more specific? What needs to be changed in your opinion? What text changes would you suggest?

-- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
Agree
From:oauth-bounces@ietf.org[mailto:oauth-bounces@ietf.org]On Behalf OfPhil Hunt
Sent:Monday, May 20, 2013 9:42 AM
To:Justin Richer
Cc:oauth@ietf.org
Subject:Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
This draft isn't ready for LC.

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

-- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.
The issue is that new developers can't figure out what token is being referred to.

Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling,especially from developerswho have deployed this draft spec, what we ought to do for each of these:

A) Keep the parameter names as-is
B) Adopt the new names as above
C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

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


--------------030307000901040609070507-- From ve7jtb@ve7jtb.com Wed May 22 14:20:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC3411E810C for ; Wed, 22 May 2013 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEmHDJUaYqA2 for ; Wed, 22 May 2013 14:20:48 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9532E11E80A2 for ; Wed, 22 May 2013 14:20:48 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x13so1620470vbb.20 for ; Wed, 22 May 2013 14:20:48 -0700 (PDT) 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=CLX5BZJWkG04Laz0fa78ONnZcu6PDB/SQxUuuOP7NGA=; b=f3uxfFg/Tw+RkncpkRZuq1LzGd74PSjRyfwOvqxYNoBmwu/xfKLLLPFd34RvBs+1bx 8vy7tv1urEAaXnKKGZedcspDQj1O89gK+LYfbQN/GBMevQ9PeTkkEQrWAlb++naBwX7h L0kDChIVmWn+dJpq5F2E4uODnsj/SbEMEPTMCWMz1CGzhzRX6fnE+NVhTVqxhMN9HOC8 cqm2RluQgDYkdSs17BQPFEdfpJr0dXScZpuHvG4YeeWcN/BSGDyZPBSxtJjRk4XrR/57 KOfHE8GE35e7TaJXt6wm2FyJZOWX0RlLhRUuut0oD49NNofn83CSX0phl6bWPzjxTDG+ 0VNw== X-Received: by 10.58.172.67 with SMTP id ba3mr3400688vec.58.1369257647793; Wed, 22 May 2013 14:20:47 -0700 (PDT) Received: from [192.168.1.36] (190-20-39-239.baf.movistar.cl. [190.20.39.239]) by mx.google.com with ESMTPSA id mw6sm2455064vec.7.2013.05.22.14.20.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 May 2013 14:20:46 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5462A002-07CB-4270-BD34-1E5F5E544F2C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> Date: Wed, 22 May 2013 17:20:44 -0400 Message-Id: <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlqFC4QTbiCBYyqoatcNRWy00TYUDc/p0IGJCN9xbc9JaUlPTWbAFtwOGSb4PLVHo2OnX+N Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 21:20:50 -0000 --Apple-Mail=_5462A002-07CB-4270-BD34-1E5F5E544F2C Content-Type: multipart/alternative; boundary="Apple-Mail=_E795D8E9-22DC-45B4-8A29-BF24482618F9" --Apple-Mail=_E795D8E9-22DC-45B4-8A29-BF24482618F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phil, As I pointed out in the other thread, redirect_uri is the thing that = ties together the clients as that is the place the responses need to go = to so is hard to fake. All instances of a particular client application will share the same = redirect_uri across all instances. =20 Adding a bunch of self asserted informational fields to the base spec is = not really helping. In a enterprise situation where all the apps play = nice it might be helpfull but the reality is that you probably allready = have a MDM that lets you manage app versions. John=20 On 2013-05-22, at 3:59 PM, Phil Hunt wrote: > I had a conversation with Justin yesterday to try to come to a = resolution regarding my concerns about client instances and being able = to associate client instances that are issued for the same client = software. I think we made some progress. >=20 > Background: =20 > In RFC6749, public clients, had a common client_id. Many interpreted = client_id as refering to the client application software (e.g. the = iPhone Facebook app). This is probably due to the types of OAuth2 = implementations that existed at the time, where there was a single SP = instance. Others have interpreted that client_id does not refer to = client applications but rather ideally should point to instances of = software. To me this seems like equating a client_id to being a user-id = -- IOW the key part of a credential rather than a client identifier.=20 >=20 > The new draft proposes that each instance be identified separately. = However it does so without keeping track of client software that is the = same. >=20 > Never-the-less, I think both interpretations can be accommodated. >=20 > Finally, in single instance services (like Facebook, Twitter, etc), = there was a natural registration and approval cycle bound into the = client_id issuance process. The developer was able to talk to the single = service provider and obtain a client_id for all deployments. It wasn't = stated, but the client_id registration sites served a useful way to do = application approvals. This is a difficult problem to solve when there = are multiple instance of Resource API deployed in multiple locations. = The developer can't contact them all. Further, because the current = draft loses knowledge of how to recognize that two instances of clients = share the same software, there's no ability to have an approval process. = Each instance is essentially anonymous, and thus approval processes = would not be possible. Though it does not require it, this proposal = makes it possible for service providers to recognize new software and to = have approval process. >=20 > Proposal: > What I have worked out with Justin (and he may not yet fully agree = with everything) is a proposal that solves the problem in an optional = way that will not break existing clients.=20 >=20 > I also propose that optional version numbers also be supported. This = is useful to service providers who need to know which client_ids are = affected when certain software clients and/or versions are deprecated. = The re-introduction of the renamed software_id further enables "local" = registration to occur. The first time a client tries to register, a = service provider could for example, choose to hold the registration to = obtain administrative approval. >=20 > The solution here is not intended to provide software "authentication" = or software verification. The solution simply allows service providers = to make pragmatic decisions about sets of clients that typically work = the same way in a change managed environment.=20 >=20 > Question: What happens if the server does not support these new = parameters and the client provides them? The current draft already = covers this in Section 3. Specifically: >> The Client Registration Endpoint MUST ignore all parameters it does = not understand. >=20 >=20 > Below are 3 options for the group to consider. My recommendation is = for option 1. My concern is option 2 will lead to complexity because = clients and service providers will attempt to encode versions and = software identifiers into one field. I would rather keep this to simple = UUIDs for most cases. >=20 > Option 1 (2 parameters): >=20 > software_id > This value MAY be required by registration endpoints. The value MAY be = a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD NOT change between software updates. While a = client application MAY be issued multiple client_id's and client = credentials over its deployment lifecycle, the software_id SHOULD NOT = change. >=20 > Signed assertions MAY be used as software identifiers to allow = different dynamic registration end-points to recognize approval from a = common issuer (for example in cases where the resource API released by a = single publisher but deployed in many different domains). The decision = to use assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. >=20 > [editorial note: some current deployments are using temporary client = credential assertions for this purpose. I propose to standardize this in = this field since an assertion would server the same purpose as a UUID = only providing third party signing and other claims. I am concerned that = passing a client assertion for this purpose creates complexity in client = authentication processing - though obviously Justin has it working] >=20 > software_version > RECOMMENDED. A version indicates a client developer chosen version = number. The identifier SHOULD BE the same across all copies of client = software. The version number SHOULD change between different client = updates. The intention is that Service Providers MAY perform equality = matching with software_id to sub-select groups of clients of a = particular software version. >=20 > Option 2 (single parameter): >=20 > software_id > This value MAY be required by registration endpoints. The value MAY be = a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD change when the client software has changed = such as with a version update or a platform change. >=20 > Signed assertions MAY be used as software identifiers to allow = different dynamic registration end-points to recognize approval from a = common issuer (for example in cases where the resource API released by a = single publisher but deployed in many different domains). The decision = to use assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. >=20 > [note: same editorial note as option 1] >=20 > Option 3 (no change): >=20 > In this option, no changes to the draft are made.=20 >=20 > Personal comment: It has been proposed by several on the list that = another extension draft be written for these features as an extension to = the dynamic registration draft. In my opinion, such a draft would be = very small in size without clear reason for separation. My feeling is = that some technical justification for keeping these features separated = will likely be needed. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E795D8E9-22DC-45B4-8A29-BF24482618F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii phil.hunt@oracle.com> = wrote:

I had a conversation = with Justin yesterday to try to come to a resolution regarding my = concerns about client instances and being able to associate client = instances that are issued for the same client software. I think we made = some progress.

Background: =  
In RFC6749, public clients, had a common = client_id. Many interpreted client_id as refering to the client = application software (e.g. the iPhone Facebook app). This is probably = due to the types of OAuth2 implementations that existed at the time, = where there was a single SP instance.  Others have interpreted that = client_id does not refer to client applications but rather ideally = should point to instances of software. To me this seems like equating a = client_id to being a user-id -- IOW the key part of a credential rather = than a client identifier. 

The new draft = proposes that each instance be identified separately. However it does so = without keeping track of client software that is the = same.

Never-the-less, I think both = interpretations can be = accommodated.

Finally, in single instance = services (like Facebook, Twitter, etc), there was a natural registration = and approval cycle bound into the client_id issuance process. The = developer was able to talk to the single service provider and obtain a = client_id for all deployments. It wasn't stated, but the client_id = registration sites served a useful way to do application approvals. =  This is a difficult problem to solve when there are multiple = instance of Resource API deployed in multiple locations. The developer = can't contact them all.  Further, because the current draft loses = knowledge of how to recognize that two instances of clients share the = same software, there's no ability to have an approval process. Each = instance is essentially anonymous, and thus approval processes would not = be possible.  Though it does not require it, this proposal makes it = possible for service providers to recognize new software and to have = approval = process.

Proposal:
= What I have worked out with Justin (and he may not yet fully agree with = everything) is a proposal that solves the problem in an optional way = that will not break existing clients. 

I = also propose that optional version numbers also be supported. This is = useful to service providers who need to know which client_ids are = affected when certain software clients and/or versions are deprecated. = The re-introduction of the renamed software_id further enables "local" = registration to occur. The first time a client tries to register, a = service provider could for example, choose to hold the registration to = obtain administrative approval.

The solution = here is not intended to provide software "authentication" or software = verification. The solution simply allows service providers to make = pragmatic decisions about sets of clients that typically work the same = way in a change managed = environment. 

Question:  What happens = if the server does not support these new parameters and the client = provides them?  The current draft already covers this in Section 3. =  Specifically:
 The Client =
Registration Endpoint MUST ignore all parameters it does not =
understand.

Below are 3 = options for the group to consider.  My recommendation is for option = 1. My concern is option 2 will lead to complexity because clients and = service providers will attempt to encode versions and software = identifiers into one field. I would rather keep this to simple UUIDs for = most cases.

Option 1 (2 = parameters):

software_id
This value MAY be required by registration = endpoints. The value MAY be a unique identifier (UUID) self-assigned by = a the client application developer, or it MAY be an assertion. The value = SHOULD be the same across all instances of a client on an application = platform. For example, software used in a = mobile phone should be considered as different from a web server = implementation though it may share the same code. The = identifier SHOULD NOT change between software = updates. While a client application MAY be issued multiple = client_id's and client credentials over its deployment lifecycle, the = software_id SHOULD NOT change.

Signed assertions MAY be used as software = identifiers to allow different dynamic registration end-points to = recognize approval from a common issuer (for example in cases where the = resource API released by a single publisher but deployed in many = different domains). The decision to use assertions and the method by = which developers know how to obtain assertions is out of scope for this = specification.

[editorial note: some current deployments are using = temporary client credential assertions for this purpose. I propose to = standardize this in this field since an assertion would server the same = purpose as a UUID only providing third party signing and other claims. I = am concerned that passing a client assertion for this purpose creates = complexity in client authentication processing - though obviously Justin = has it working]

software_version
RECOMMENDED. A version indicates a client = developer chosen version number. The identifier SHOULD BE the same = across all copies of client software. The version number SHOULD change = between different client updates. The intention is that Service = Providers MAY perform equality matching with software_id to sub-select = groups of clients of a particular software = version.

Option = 2 (single parameter):

software_id
This value MAY = be required by registration endpoints. The value MAY be a unique = identifier (UUID) self-assigned by a the client application developer, = or it MAY be an assertion. The value SHOULD be the same across all = instances of a client on an application platform. For example, software = used in a mobile phone should be considered as different from a web = server implementation though it may share the same code. The = identifier SHOULD change when the client software has = changed such as with a version update or a platform = change.
Signed = assertions MAY be used as software identifiers to allow different = dynamic registration end-points to recognize approval from a common = issuer (for example in cases where the resource API released by a single = publisher but deployed in many different domains). The decision to use = assertions and the method by which developers know how to obtain = assertions is out of scope for this = specification.

[note: same editorial note as option = 1]

Option 3 (no = change):

In this option, no changes to the = draft are made. 

Personal comment: =  It has been proposed by several on the list that another extension = draft be written for these features as an extension to the dynamic = registration draft. In my opinion, such a draft would be very small in = size without clear reason for separation. My feeling is that some = technical justification for keeping these features separated will likely = be needed.

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





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

= --Apple-Mail=_E795D8E9-22DC-45B4-8A29-BF24482618F9-- --Apple-Mail=_5462A002-07CB-4270-BD34-1E5F5E544F2C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIyMjEyMDQ0WjAjBgkqhkiG9w0BCQQxFgQUmvrDKFlq vDFA/MaV0cQoFXaGHvEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAP9WUIz/8/v5EPadbKKKUarvRx9Lz90CZ56ZGlr8q lL/DElYpcDYiFCSYKYVzCqsswFanP7PwP4FZW6EZm7R7PasdDNxl1JBABuKm9sH/IgXCSVmfK9JS f7sQ98gkiEqcY4Ouahz824B+M+4JPMqhMbEZiB4tQf/URXt8QlIu0Qv90MXAbX4K8XuqoOk7dTBj DT54utvZAou/WpriJAt7/SgplA45E5rvxwR18Ud4h34V+3bHzbQbq5py2aaO1tnvCfb4kKw7NNkj E7HTEbxkiYKbOfF7YhIW3biAG4RKcKAb8e3ACkJHD4yEHvfgWsxK3pPY1K6MUGAiwR1n9Wp36AAA AAAAAA== --Apple-Mail=_5462A002-07CB-4270-BD34-1E5F5E544F2C-- From tonynad@microsoft.com Wed May 22 14:29:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96711E811B for ; Wed, 22 May 2013 14:29:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEyQ+uVFR+BM for ; Wed, 22 May 2013 14:28:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6123011E8123 for ; Wed, 22 May 2013 14:28:54 -0700 (PDT) Received: from BY2FFO11FD006.protection.gbl (10.1.15.204) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 21:24:33 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 21:24:33 +0000 Received: from DB8EHSOBE014.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 22 May 2013 21:24:02 +0000 Received: from mail206-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE014.bigfish.com (10.174.4.77) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 21:22:28 +0000 Received: from mail206-db8 (localhost [127.0.0.1]) by mail206-db8-R.bigfish.com (Postfix) with ESMTP id 5588C4C01BC for ; Wed, 22 May 2013 21:22:28 +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: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh936eI1e83Mc857hdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail206-db8: 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; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail206-db8 (localhost.localdomain [127.0.0.1]) by mail206-db8 (MessageSwitch) id 1369257746385415_21709; Wed, 22 May 2013 21:22:26 +0000 (UTC) Received: from DB8EHSMHS023.bigfish.com (unknown [10.174.8.240]) by mail206-db8.bigfish.com (Postfix) with ESMTP id 579053C00B7; Wed, 22 May 2013 21:22:26 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS023.bigfish.com (10.174.4.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 21:22:26 +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.311.1; Wed, 22 May 2013 21:22:25 +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.698.13; Wed, 22 May 2013 21:22:23 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) with mapi id 15.00.0698.010; Wed, 22 May 2013 21:22:23 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWw2HOVR1MGBX02Be07cmNz/cpkOMHcAgAAH54CAAA6lAIAAGIDAgAAAQ4CAAytGAIAAIbEAgAALjfA= Date: Wed, 22 May 2013 21:22:23 +0000 Message-ID: <8ae4313deafe4397b0b312ef38dcf182@BY2PR03MB041.namprd03.prod.outlook.com> References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <519D2BE4.6080303@mitre.org> In-Reply-To: <519D2BE4.6080303@mitre.org> 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_8ae4313deafe4397b0b312ef38dcf182BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB041.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%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(479174002)(199002)(78114002)(377424003)(24454002)(77982001)(76482001)(74316001)(56816002)(81342001)(66066001)(74706001)(54356001)(16236675002)(81542001)(6806003)(15202345002)(63696002)(71186001)(512874002)(44976003)(49866001)(561944002)(20776003)(79102001)(33646001)(16676001)(74876001)(47446002)(80022001)(47976001)(56776001)(74502001)(51856001)(65816001)(74366001)(69226001)(31966008)(54316002)(59766001)(47736001)(46102001)(4396001)(50986001)(74662001)(53806001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB006; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 21:29:00 -0000 --_000_8ae4313deafe4397b0b312ef38dcf182BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0b3RhbGx5IGRpc2FncmVlIHdpdGggeW91ciBjaGFyYWN0ZXJpemF0aW9uIG9mIFNDSU0sIHdo aWxlIGl0IGNhbiBiZSB1c2VkIGZyb20gc2VydmVyIHRvIHNlcnZlciAocHJvdmlzaW9uIG9uZSBz eXN0ZW0gdG8gYW5vdGhlcikgaXQgY2FuIGFsc28gYmUgY2xpZW50IHRvIGVuZHBvaW50IChpbml0 aWFsIHByb3Zpc2lvbmluZyBhbmQgSklUIHByb3Zpc2lvbmluZykuIFNDSU0gaXMgZmFpcmx5IHNp bXBsZSAoYnV0IGNhbiBiZSBjb21wbGV4KSwgSSBhbHNvIGhhdmUgY29uY2VybnMgYWJvdXQgU0NJ TSBub3QgYmVpbmcgMTAwJSByZXN0ZnVsIGJ1dCB0aGF0IGRvZXMgbm90IHN0b3AgdXMgZnJvbSB1 c2luZyBpdC4gSSBhbHNvIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGxldCBPQXV0aCBkbyB3aGF0IGl0 4oCZcyBnb29kIGF0IGFuZCBkb27igJl0IHRyeSB0byBmb3JjZSBpdCBpbnRvIHNvbWV0aGluZyB0 aGF0IGl04oCZcyBub3QuIFdlIGFscmVhZHkgaGF2ZSBPQXV0aCBkb2luZyBkeW5hbWljIHJlZ2lz dHJhdGlvbiwgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEgbmVlZCB0byBmb3JjZSBpdCBpbnRv IE9BdXRoLg0KDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9y Z10NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDIyLCAyMDEzIDE6MzUgUE0NClRvOiBBbnRob255IE5h ZGFsaW4NCkNjOiBQaGlsIEh1bnQ7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbg0KDQpJ J20gbm90IHN1cmUgd2h5IHlvdSBkb24ndCB0aGluayBpdCdzIGluIHNjb3BlLCBpdCdzIGluIHRo ZSB3b3JraW5nIGdyb3VwJ3MgY2hhcnRlcjoNCg0KICBodHRwOi8vd3d3LmlldGYub3JnL2R5bi93 Zy9jaGFydGVyL29hdXRoLWNoYXJ0ZXIuaHRtbA0KDQpTbyAuLi4gaXQncyBkZWZpbml0ZWx5IGlu IHNjb3BlLCBhbmQgaGFzIGJlZW4gZm9yIG92ZXIgYSB5ZWFyIGFuZCBhIGhhbGYuIFRoaXMgaXMg dGhlIHRlbnRoIHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudC0tIGFuIElFVEYgV29ya2luZyBHcm91 cCBkb2N1bWVudCBhdCB0aGF0LS0gdGhhdCdzIGJlZW4gcG9zdGVkIHRvIHRoZSBncm91cCB3aXRo IGV2ZXJ5IHJldmlzaW9uIGFuZCB0aGVyZSBoYXMgYmVlbiBzaWduaWZpY2FudCBjb252ZXJzYXRp b24gYXJvdW5kIGl0LCBlc3BlY2lhbGx5IG92ZXIgdGhlIGxhc3Qgc2l4IG1vbnRocyBzaW5jZSBJ IHRvb2sgb3ZlciB0aGUgZWRpdG9yIHJvbGUuIFRoZXJlIGFyZSBhbHNvIGEgaGFuZGZ1bCBvZiBp bXBsZW1lbnRhdGlvbnMgb2YgdGhpcywgYW5kIHdoaWxlIG1vc3Qgb2YgdGhlbSBhcmUgYnVpbHQg dG8gZG8gT3BlbklEIENvbm5lY3Qgb3IgVU1BICh3aGljaCBhcmUgZGlyZWN0bHkgYnVpbHQgb24g T0F1dGgpLCBJIGtub3cgdGhlcmUgYXJlIHNvbWUgdGhhdCBhbHNvIGRvIHBsYWluIE9BdXRoLiAo Tm90IHRoZSBsZWFzdCBvZiB3aGljaCBpcyBvbmUgdGhhdCBJIGhhdmUgcGVyc29uYWxseSBpbXBs ZW1lbnRlZCBhbmQgZGVwbG95ZWQuKQ0KDQpTQ0lNIGRvZXNuJ3Qgc29sdmUgY2xpZW50IG1hbmFn ZW1lbnQgcGFydGljdWxhcmx5IHdlbGwsIHNpbmNlIGl0J3MgbWFkZSBmb3IgdXNlcnMgbW9yZSB0 aGFuIGFueXRoaW5nLiBUaGUgdXNhZ2UgbW9kZWwgb2YgU0NJTSBpcyBhbHNvIHF1aXRlIGRpZmZl cmVudCAtLSBpdCdzIHJlYWxseSBpbnRlbmRlZCB0byBiZSB1c2VkIGJldHdlZW4gdHdvIHNlcnZl cnMgdG8gdHJhbnNmZXIgaW5mb3JtYXRpb24sIGFzIG9wcG9zZWQgdG8gaGFuZGxpbmcgc2VsZi1h c3NlcnRlZCBjbGFpbXMuIEkgdW5kZXJzdGFuZCB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25zIGxp a2UgVUFBIGhhdmUgZG9uZSB0aGVpciBzdGF0aWMgcmVnaXN0cmF0aW9uIHVzaW5nIGEgU0NJTSBw cm9maWxlLCBidXQgaXQncyBub3QgZHluYW1pYyByZWdpc3RyYXRpb24sIHJlYWxseS4gSSB0aGlu ayBpdCdzIHRvbyBtdWNoIG9mIGEgc3F1YXJlLXBlZy1yb3VuZC1ob2xlIHByb2JsZW0sIGF0IGxl YXN0IHdpdGggU0NJTSBhcyBpdCBpcyB0b2RheTsgc28gbGV0IFNDSU0gZG8gd2hhdCBpdCdzIGdv b2QgYXQsIGFuZCBkb24ndCB0cnkgdG8gZm9yY2UgaXQgaW50byBzb21ldGhpbmcgaXQncyBub3Qu DQoNCkZ1cnRoZXJtb3JlLCBiZSBjYXJlZnVsIG5vdCB0byBjb25mbGF0ZSBTQ0lNIHdpdGggUkVT VC4gVWx0aW1hdGVseSwgRHluYW1pYyBSZWdpc3RyYXRpb24gd2FzIG1lYW50IHRvIGJlIGEgZmFp cmx5IHNpbXBsZSBSRVNUL0pTT04gQVBJIHRoYXQgd291bGQgYmUgZWFzeSB0byBpbXBsZW1lbnQs IGVzcGVjaWFsbHkgZm9yIGNsaWVudHMuIEp1c3QgYmVjYXVzZSBTQ0lNIGlzIFJFU1RmdWwgZG9l c24ndCBtZWFuIGl0J3MgYSBnb29kIHN0cnVjdHVyZSBmb3Igb3RoZXIgUkVTVGZ1bCBBUElzLiBO YW1lbHksIEkgZG9uJ3QgdGhpbmsgdGhlIGV4dHJhIHN0cnVjdHVyZSBhbmQgaG9va3Mgd2l0aCBT Q0lNIHJlYWxseSBidXkgeW91IGFueXRoaW5nIGhlcmUsIGVzcGVjaWFsbHkgd2l0aCB0aGUgYWRk aXRpb25zIGFuZCBjaGFuZ2VzIHlvdSdkIGhhdmUgdG8gbWFrZSB0byBTQ0lNLg0KDQpBbmQgZmlu YWxseSwgbm9ib2R5IHRvIGRhdGUgaGFzIGFjdHVhbGx5IHdyaXR0ZW4gYSBwcm9wb3NhbCB0aGF0 IGlzIGV2ZW4gcmVtb3RlbHkgU0NJTSBiYXNlZC4NCg0KIC0tIEp1c3Rpbg0KT24gMDUvMjIvMjAx MyAwMjozOSBQTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KU28sIEkgcmVhbGx5IGRvbuKAmXQg dW5kZXJzdGFuZCB3aHkgZHluYW1pYyByZWdpc3RyYXRpb24gaXMgaW4gc2NvcGUsIEkgdW5kZXJz dGFuZCB0aGlzIHJlbGF0aXZlIHRvIE9wZW5JRCBDb25uZWN0IGJ1dCBub3QgT0F1dGgsIGlmIHRo aXMgaXMgaW5kZWVkIGluIHNjb3BlIHRoZW4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoYXQgdGhl IGVuZHBvaW50IGJlIGJhc2VkIHVwb24gU0NJTSBhbmQgbm90IHNvbWV0aGluZyBlbHNlIGxpa2Ug d2hhdCBoYXMgYmVlbiBkb25lIGhlcmUuDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpq cmljaGVyQG1pdHJlLm9yZ10NClNlbnQ6IE1vbmRheSwgTWF5IDIwLCAyMDEzIDExOjEwIEFNDQpU bzogQW50aG9ueSBOYWRhbGluDQpDYzogUGhpbCBIdW50OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXgg Q2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbg0KDQpUb255LCBjYW4geW91IGJlIG1vcmUg c3BlY2lmaWM/IFdoYXQgbmVlZHMgdG8gYmUgY2hhbmdlZCBpbiB5b3VyIG9waW5pb24/IFdoYXQg dGV4dCBjaGFuZ2VzIHdvdWxkIHlvdSBzdWdnZXN0Pw0KDQogLS0gSnVzdGluDQpPbiAwNS8yMC8y MDEzIDAyOjA5IFBNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6DQpBZ3JlZQ0KDQpGcm9tOiBvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IE1v bmRheSwgTWF5IDIwLCAyMDEzIDk6NDIgQU0NClRvOiBKdXN0aW4gUmljaGVyDQpDYzogb2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g UHJvcG9zZWQgU3ludGF4IENoYW5nZXMgaW4gRHluYW1pYyBSZWdpc3RyYXRpb24NCg0KVGhpcyBk cmFmdCBpc24ndCByZWFkeSBmb3IgTEMuDQoNClBoaWwNCg0KT24gMjAxMy0wNS0yMCwgYXQgODo0 OSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUu b3JnPj4gd3JvdGU6DQpCdXQgYWxzbyBrZWVwIGluIG1pbmQgdGhhdCB0aGlzIGlzIGxhc3QtY2Fs bCwgYW5kIHRoYXQgd2UgZG9uJ3QgcmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIGF2b2lkYWJsZSBk cmFzdGljIGNoYW5nZXMgYXQgdGhpcyBzdGFnZS4NCg0KIC0tIEp1c3Rpbg0KDQoNCg0KT24gMDUv MjAvMjAxMyAxMToyMSBBTSwgUGhpbCBIdW50IHdyb3RlOg0KS2VlcCBpbiBtaW5kIHRoZXJlIG1h eSBiZSBvdGhlciBjaGFuZ2VzIGNvbWluZy4NCg0KVGhlIGlzc3VlIGlzIHRoYXQgbmV3IGRldmVs b3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3aGF0IHRva2VuIGlzIGJlaW5nIHJlZmVycmVkIHRvLg0K DQpQaGlsDQoNCk9uIDIwMTMtMDUtMjAsIGF0IDg6MDksIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJA bWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KUGhpbCBIdW50J3Mg cmV2aWV3IG9mIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uIGhhcyByYWlz ZWQgYSBjb3VwbGUgb2YgaXNzdWVzIHRoYXQgSSBmZWx0IHdlcmUgZ2V0dGluZyBidXJpZWQgYnkg dGhlIGxhcmdlciBkaXNjdXNzaW9uICh3aGljaCBJIHN0aWxsIHN0cm9uZ2x5IGVuY291cmFnZSBv dGhlcnMgdG8ganVtcCBpbiB0bykuIE5hbWVseSwgUGhpbCBoYXMgc3VnZ2VzdGVkIGEgY291cGxl IG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBvZiBzZXZlcmFsIHBhcmFtZXRlcnMuDQoN Cg0KMSkgZXhwaXJlc19hdCAtPiBjbGllbnRfc2VjcmV0X2V4cGlyZXNfYXQNCjIpIGlzc3VlZF9h dCAtPiBjbGllbnRfaWRfaXNzdWVkX2F0DQozKSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCAt PiB0b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2QNCg0KDQpJJ2QgbGlrZSB0byBnZXQg YSBmZWVsaW5nLCBlc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVycyB3aG8gaGF2ZSBkZXBsb3llZCB0 aGlzIGRyYWZ0IHNwZWMsIHdoYXQgd2Ugb3VnaHQgdG8gZG8gZm9yIGVhY2ggb2YgdGhlc2U6DQoN CiBBKSBLZWVwIHRoZSBwYXJhbWV0ZXIgbmFtZXMgYXMtaXMNCiBCKSBBZG9wdCB0aGUgbmV3IG5h bWVzIGFzIGFib3ZlDQogQykgQWRvcHQgYSBuZXcgbmFtZSB0aGF0IEkgd2lsbCBzcGVjaWZ5DQoN CkluIGFsbCBjYXNlcywgY2xhcmlmeWluZyB0ZXh0IHdpbGwgYmUgYWRkZWQgdG8gdGhlIHBhcmFt ZXRlciAqZGVmaW5pdGlvbnMqIHNvIHRoYXQgaXQncyBtb3JlIGNsZWFyIHRvIHBlb3BsZSByZWFk aW5nIHRoZSBzcGVjIHdoYXQgZWFjaCBwaWVjZSBkb2VzLiBTcGVha2luZyBhcyB0aGUgZWRpdG9y OiAiQSIgaXMgdGhlIGRlZmF1bHQgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQsIHNpbmNlIHdlIHNo b3VsZG4ndCBjaGFuZ2Ugc3ludGF4IHdpdGhvdXQgdmVyeSBnb29kIHJlYXNvbiB0byBkbyBzby4g VGhhdCBzYWlkLCBpZiBpdCdzIGdvaW5nIHRvIGJlIGJldHRlciBmb3IgZGV2ZWxvcGVycyB3aXRo IHRoZSBuZXcgcGFyYW1ldGVyIG5hbWVzLCBJIGFtIG9wZW4gdG8gZml4aW5nIHRoZW0gbm93Lg0K DQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQuDQoNCiAtLSBKdXN0aW4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg== --_000_8ae4313deafe4397b0b312ef38dcf182BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdG90YWxseSBkaXNhZ3Jl ZSB3aXRoIHlvdXIgY2hhcmFjdGVyaXphdGlvbiBvZiBTQ0lNLCB3aGlsZSBpdCBjYW4gYmUgdXNl ZCBmcm9tIHNlcnZlciB0byBzZXJ2ZXIgKHByb3Zpc2lvbiBvbmUgc3lzdGVtIHRvIGFub3RoZXIp IGl0IGNhbiBhbHNvIGJlIGNsaWVudCB0bw0KIGVuZHBvaW50IChpbml0aWFsIHByb3Zpc2lvbmlu ZyBhbmQgSklUIHByb3Zpc2lvbmluZykuIFNDSU0gaXMgZmFpcmx5IHNpbXBsZSAoYnV0IGNhbiBi ZSBjb21wbGV4KSwgSSBhbHNvIGhhdmUgY29uY2VybnMgYWJvdXQgU0NJTSBub3QgYmVpbmcgMTAw JSByZXN0ZnVsIGJ1dCB0aGF0IGRvZXMgbm90IHN0b3AgdXMgZnJvbSB1c2luZyBpdC4gSSBhbHNv IGFncmVlIHRoYXQgd2Ugc2hvdWxkIGxldCBPQXV0aCBkbyB3aGF0IGl04oCZcyBnb29kIGF0IGFu ZA0KIGRvbuKAmXQgdHJ5IHRvIGZvcmNlIGl0IGludG8gc29tZXRoaW5nIHRoYXQgaXTigJlzIG5v dC4gV2UgYWxyZWFkeSBoYXZlIE9BdXRoIGRvaW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uLCBJIGRv buKAmXQgdGhpbmsgdGhlcmUgaXMgYSBuZWVkIHRvIGZvcmNlIGl0IGludG8gT0F1dGguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBKdXN0aW4gUmljaGVyIFttYWlsdG86 anJpY2hlckBtaXRyZS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMjIs IDIwMTMgMTozNSBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6 PC9iPiBQaGlsIEh1bnQ7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFtaWMgUmVnaXN0cmF0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5JJ20gbm90IHN1cmUgd2h5IHlvdSBkb24ndCB0aGluayBpdCdz IGluIHNjb3BlLCBpdCdzIGluIHRoZSB3b3JraW5nIGdyb3VwJ3MgY2hhcnRlcjo8YnI+DQo8YnI+ DQombmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9keW4vd2cvY2hhcnRlci9vYXV0 aC1jaGFydGVyLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvZHluL3dnL2NoYXJ0ZXIvb2F1dGgt Y2hhcnRlci5odG1sPC9hPjxicj4NCjxicj4NClNvIC4uLiBpdCdzIGRlZmluaXRlbHkgaW4gc2Nv cGUsIGFuZCBoYXMgYmVlbiBmb3Igb3ZlciBhIHllYXIgYW5kIGEgaGFsZi4gVGhpcyBpcyB0aGUg dGVudGggdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50LS0gYW4gSUVURiBXb3JraW5nIEdyb3VwIGRv Y3VtZW50IGF0IHRoYXQtLSB0aGF0J3MgYmVlbiBwb3N0ZWQgdG8gdGhlIGdyb3VwIHdpdGggZXZl cnkgcmV2aXNpb24gYW5kIHRoZXJlIGhhcyBiZWVuIHNpZ25pZmljYW50IGNvbnZlcnNhdGlvbiBh cm91bmQNCiBpdCwgZXNwZWNpYWxseSBvdmVyIHRoZSBsYXN0IHNpeCBtb250aHMgc2luY2UgSSB0 b29rIG92ZXIgdGhlIGVkaXRvciByb2xlLiBUaGVyZSBhcmUgYWxzbyBhIGhhbmRmdWwgb2YgaW1w bGVtZW50YXRpb25zIG9mIHRoaXMsIGFuZCB3aGlsZSBtb3N0IG9mIHRoZW0gYXJlIGJ1aWx0IHRv IGRvIE9wZW5JRCBDb25uZWN0IG9yIFVNQSAod2hpY2ggYXJlIGRpcmVjdGx5IGJ1aWx0IG9uIE9B dXRoKSwgSSBrbm93IHRoZXJlIGFyZSBzb21lIHRoYXQgYWxzbw0KIGRvIHBsYWluIE9BdXRoLiAo Tm90IHRoZSBsZWFzdCBvZiB3aGljaCBpcyBvbmUgdGhhdCBJIGhhdmUgcGVyc29uYWxseSBpbXBs ZW1lbnRlZCBhbmQgZGVwbG95ZWQuKTxicj4NCjxicj4NClNDSU0gZG9lc24ndCBzb2x2ZSBjbGll bnQgbWFuYWdlbWVudCBwYXJ0aWN1bGFybHkgd2VsbCwgc2luY2UgaXQncyBtYWRlIGZvciB1c2Vy cyBtb3JlIHRoYW4gYW55dGhpbmcuIFRoZSB1c2FnZSBtb2RlbCBvZiBTQ0lNIGlzIGFsc28gcXVp dGUgZGlmZmVyZW50IC0tIGl0J3MgcmVhbGx5IGludGVuZGVkIHRvIGJlIHVzZWQgYmV0d2VlbiB0 d28gc2VydmVycyB0byB0cmFuc2ZlciBpbmZvcm1hdGlvbiwgYXMgb3Bwb3NlZCB0byBoYW5kbGlu ZyBzZWxmLWFzc2VydGVkDQogY2xhaW1zLiBJIHVuZGVyc3RhbmQgdGhhdCBzb21lIGltcGxlbWVu dGF0aW9ucyBsaWtlIFVBQSBoYXZlIGRvbmUgdGhlaXIgc3RhdGljIHJlZ2lzdHJhdGlvbiB1c2lu ZyBhIFNDSU0gcHJvZmlsZSwgYnV0IGl0J3Mgbm90IGR5bmFtaWMgcmVnaXN0cmF0aW9uLCByZWFs bHkuIEkgdGhpbmsgaXQncyB0b28gbXVjaCBvZiBhIHNxdWFyZS1wZWctcm91bmQtaG9sZSBwcm9i bGVtLCBhdCBsZWFzdCB3aXRoIFNDSU0gYXMgaXQgaXMgdG9kYXk7IHNvIGxldA0KIFNDSU0gZG8g d2hhdCBpdCdzIGdvb2QgYXQsIGFuZCBkb24ndCB0cnkgdG8gZm9yY2UgaXQgaW50byBzb21ldGhp bmcgaXQncyBub3QuPGJyPg0KPGJyPg0KRnVydGhlcm1vcmUsIGJlIGNhcmVmdWwgbm90IHRvIGNv bmZsYXRlIFNDSU0gd2l0aCBSRVNULiBVbHRpbWF0ZWx5LCBEeW5hbWljIFJlZ2lzdHJhdGlvbiB3 YXMgbWVhbnQgdG8gYmUgYSBmYWlybHkgc2ltcGxlIFJFU1QvSlNPTiBBUEkgdGhhdCB3b3VsZCBi ZSBlYXN5IHRvIGltcGxlbWVudCwgZXNwZWNpYWxseSBmb3IgY2xpZW50cy4gSnVzdCBiZWNhdXNl IFNDSU0gaXMgUkVTVGZ1bCBkb2Vzbid0IG1lYW4gaXQncyBhIGdvb2Qgc3RydWN0dXJlIGZvcg0K IG90aGVyIFJFU1RmdWwgQVBJcy4gTmFtZWx5LCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzdHJ1 Y3R1cmUgYW5kIGhvb2tzIHdpdGggU0NJTSByZWFsbHkgYnV5IHlvdSBhbnl0aGluZyBoZXJlLCBl c3BlY2lhbGx5IHdpdGggdGhlIGFkZGl0aW9ucyBhbmQgY2hhbmdlcyB5b3UnZCBoYXZlIHRvIG1h a2UgdG8gU0NJTS48YnI+DQo8YnI+DQpBbmQgZmluYWxseSwgbm9ib2R5IHRvIGRhdGUgaGFzIGFj dHVhbGx5IHdyaXR0ZW4gYSBwcm9wb3NhbCB0aGF0IGlzIGV2ZW4gcmVtb3RlbHkgU0NJTSBiYXNl ZC4NCjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzIyLzIwMTMgMDI6MzkgUE0sIEFudGhvbnkgTmFkYWxp biB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIEkgcmVhbGx5IGRv buKAmXQgdW5kZXJzdGFuZCB3aHkgZHluYW1pYyByZWdpc3RyYXRpb24gaXMgaW4gc2NvcGUsIEkg dW5kZXJzdGFuZCB0aGlzIHJlbGF0aXZlIHRvIE9wZW5JRCBDb25uZWN0IGJ1dCBub3QgT0F1dGgs IGlmIHRoaXMgaXMgaW5kZWVkIGluIHNjb3BlIHRoZW4NCiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQg dGhhdCB0aGUgZW5kcG9pbnQgYmUgYmFzZWQgdXBvbiBTQ0lNIGFuZCBub3Qgc29tZXRoaW5nIGVs c2UgbGlrZSB3aGF0IGhhcyBiZWVuIGRvbmUgaGVyZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEp1c3RpbiBSaWNoZXIgWzxhIGhyZWY9 Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyAxMToxMCBBTTxicj4NCjxi PlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBQaGlsIEh1bnQ7IDxhIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFt aWMgUmVnaXN0cmF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Ub255LCBjYW4geW91IGJlIG1vcmUg c3BlY2lmaWM/IFdoYXQgbmVlZHMgdG8gYmUgY2hhbmdlZCBpbiB5b3VyIG9waW5pb24/IFdoYXQg dGV4dCBjaGFuZ2VzIHdvdWxkIHlvdSBzdWdnZXN0Pzxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rp bjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzIwLzIw MTMgMDI6MDkgUE0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QWdyZWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhy ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIE1heSAyMCwgMjAxMyA5OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4g UmljaGVyPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBQcm9w b3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGlzbid0 IHJlYWR5IGZvciBMQy4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCk9uIDIwMTMtMDUtMjAsIGF0IDg6NDksIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CdXQgYWxzbyBrZWVwIGluIG1pbmQgdGhh dCB0aGlzIGlzIGxhc3QtY2FsbCwgYW5kIHRoYXQgd2UgZG9uJ3QgcmVhbGx5IHdhbnQgdG8gZW5j b3VyYWdlIGF2b2lkYWJsZSBkcmFzdGljIGNoYW5nZXMgYXQgdGhpcyBzdGFnZS4NCjxicj4NCjxi cj4NCiZuYnNwOy0tIEp1c3Rpbjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzIwLzIwMTMgMTE6MjEgQU0sIFBo aWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+S2VlcCBpbiBtaW5kIHRoZXJlIG1heSBiZSBvdGhlciBjaGFuZ2VzIGNvbWlu Zy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGlzc3VlIGlzIHRoYXQgbmV3IGRldmVsb3BlcnMgY2FuJ3QgZmlndXJlIG91dCB3 aGF0IHRva2VuIGlzIGJlaW5nIHJlZmVycmVkIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpPbiAyMDEzLTA1LTIwLCBhdCA4OjA5LCBKdXN0aW4gUmljaGVyICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBoaWwgSHVudCdzIHJldmlldyBvZiB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24g c3BlY2lmaWNhdGlvbiBoYXMgcmFpc2VkIGEgY291cGxlIG9mIGlzc3VlcyB0aGF0IEkgZmVsdCB3 ZXJlIGdldHRpbmcgYnVyaWVkIGJ5IHRoZSBsYXJnZXIgZGlzY3Vzc2lvbiAod2hpY2ggSSBzdGls bCBzdHJvbmdseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIGp1bXAgaW4gdG8pLiBOYW1lbHksIFBoaWwg aGFzIHN1Z2dlc3RlZCBhIGNvdXBsZQ0KIG9mIHN5bnRheCBjaGFuZ2VzIHRvIHRoZSBuYW1lcyBv ZiBzZXZlcmFsIHBhcmFtZXRlcnMuIDxicj4NCjxicj4NCjxicj4NCjEpIGV4cGlyZXNfYXQgLSZn dDsgY2xpZW50X3NlY3JldF9leHBpcmVzX2F0PGJyPg0KMikgaXNzdWVkX2F0IC0mZ3Q7IGNsaWVu dF9pZF9pc3N1ZWRfYXQ8YnI+DQozKSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCAtJmd0OyB0 b2tlbl9lbmRwb2ludF9jbGllbnRfYXV0aF9tZXRob2Q8YnI+DQo8YnI+DQo8YnI+DQpJJ2QgbGlr ZSB0byBnZXQgYSBmZWVsaW5nLCA8Yj5lc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVyczwvYj4gd2hv IGhhdmUgZGVwbG95ZWQgdGhpcyBkcmFmdCBzcGVjLCB3aGF0IHdlIG91Z2h0IHRvIGRvIGZvciBl YWNoIG9mIHRoZXNlOjxicj4NCjxicj4NCiZuYnNwO0EpIEtlZXAgdGhlIHBhcmFtZXRlciBuYW1l cyBhcy1pczxicj4NCiZuYnNwO0IpIEFkb3B0IHRoZSBuZXcgbmFtZXMgYXMgYWJvdmU8YnI+DQom bmJzcDtDKSBBZG9wdCBhIG5ldyBuYW1lIHRoYXQgSSB3aWxsIHNwZWNpZnk8YnI+DQo8YnI+DQpJ biBhbGwgY2FzZXMsIGNsYXJpZnlpbmcgdGV4dCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBwYXJhbWV0 ZXIgKmRlZmluaXRpb25zKiBzbyB0aGF0IGl0J3MgbW9yZSBjbGVhciB0byBwZW9wbGUgcmVhZGlu ZyB0aGUgc3BlYyB3aGF0IGVhY2ggcGllY2UgZG9lcy4gU3BlYWtpbmcgYXMgdGhlIGVkaXRvcjog JnF1b3Q7QSZxdW90OyBpcyB0aGUgZGVmYXVsdCBhcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwgc2lu Y2Ugd2Ugc2hvdWxkbid0IGNoYW5nZSBzeW50YXggd2l0aG91dA0KIHZlcnkgZ29vZCByZWFzb24g dG8gZG8gc28uIFRoYXQgc2FpZCwgaWYgaXQncyBnb2luZyB0byBiZSBiZXR0ZXIgZm9yIGRldmVs b3BlcnMgd2l0aCB0aGUgbmV3IHBhcmFtZXRlciBuYW1lcywgSSBhbSBvcGVuIHRvIGZpeGluZyB0 aGVtIG5vdy48YnI+DQo8YnI+DQpOYW1pbmcgdGhpbmdzIGlzIGhhcmQuPGJyPg0KPGJyPg0KJm5i c3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_8ae4313deafe4397b0b312ef38dcf182BY2PR03MB041namprd03pro_-- From Michael.Jones@microsoft.com Wed May 22 14:29:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78711E811B for ; Wed, 22 May 2013 14:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHO-PfJM44y3 for ; Wed, 22 May 2013 14:29:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53511E8123 for ; Wed, 22 May 2013 14:29:38 -0700 (PDT) Received: from BN1AFFO11FD010.protection.gbl (10.58.52.200) by BN1BFFO11HUB007.protection.gbl (10.58.53.117) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 21:27:18 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD010.mail.protection.outlook.com (10.58.52.70) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 21:27:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Wed, 22 May 2013 21:27:02 +0000 From: Mike Jones To: John Bradley , Phil Hunt Thread-Topic: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) Thread-Index: AQHOVybeptHVmQVKW0KjuX3bBguEJZkRtiIAgAAAWAA= Date: Wed, 22 May 2013 21:27:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> In-Reply-To: <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.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_4E1F6AAD24975D4BA5B1680429673943677531A1TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(199002)(377424003)(24454002)(77982001)(76482001)(56816002)(512954002)(81342001)(66066001)(74706001)(33656001)(54356001)(16236675002)(81542001)(6806003)(15202345002)(63696002)(71186001)(16406001)(49866001)(561944002)(20776003)(79102001)(74876001)(47446002)(80022001)(47976001)(56776001)(74502001)(51856001)(65816001)(74366001)(69226001)(31966008)(54316002)(59766001)(47736001)(55846006)(46102001)(4396001)(50986001)(74662001)(53806001)(15974865001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB007; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 21:29:45 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943677531A1TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 We already have a "software_id" field and it's named "redirect_uris". This doesn't seem well thought-out. We shouldn't try to jam it into the sp= ec at the last minute. The good news is that since the registration spec allows for extensions, an= d the proposed fields are optional, these could be added later as a non-bre= aking change by another spec if the working group eventually decides to pur= sue a route like the one proposed below. We don't have to do it now for th= is to eventually come into being after deliberate consideration of a comple= te specification including these features by the working group. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ohn Bradley Sent: Wednesday, May 22, 2013 2:21 PM To: Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_i= d definition issue (was: Client Instances) Phil, As I pointed out in the other thread, redirect_uri is the thing that ties = together the clients as that is the place the responses need to go to so is= hard to fake. All instances of a particular client application will share the same redire= ct_uri across all instances. Adding a bunch of self asserted informational fields to the base spec is no= t really helping. In a enterprise situation where all the apps play nice i= t might be helpfull but the reality is that you probably allready have a MD= M that lets you manage app versions. John On 2013-05-22, at 3:59 PM, Phil Hunt > wrote: I had a conversation with Justin yesterday to try to come to a resolution r= egarding my concerns about client instances and being able to associate cli= ent instances that are issued for the same client software. I think we made= some progress. Background: In RFC6749, public clients, had a common client_id. Many interpreted client= _id as refering to the client application software (e.g. the iPhone Faceboo= k app). This is probably due to the types of OAuth2 implementations that ex= isted at the time, where there was a single SP instance. Others have inter= preted that client_id does not refer to client applications but rather idea= lly should point to instances of software. To me this seems like equating a= client_id to being a user-id -- IOW the key part of a credential rather th= an a client identifier. The new draft proposes that each instance be identified separately. However= it does so without keeping track of client software that is the same. Never-the-less, I think both interpretations can be accommodated. Finally, in single instance services (like Facebook, Twitter, etc), there w= as a natural registration and approval cycle bound into the client_id issua= nce process. The developer was able to talk to the single service provider = and obtain a client_id for all deployments. It wasn't stated, but the clien= t_id registration sites served a useful way to do application approvals. T= his is a difficult problem to solve when there are multiple instance of Res= ource API deployed in multiple locations. The developer can't contact them = all. Further, because the current draft loses knowledge of how to recogniz= e that two instances of clients share the same software, there's no ability= to have an approval process. Each instance is essentially anonymous, and t= hus approval processes would not be possible. Though it does not require i= t, this proposal makes it possible for service providers to recognize new s= oftware and to have approval process. Proposal: What I have worked out with Justin (and he may not yet fully agree with eve= rything) is a proposal that solves the problem in an optional way that will= not break existing clients. I also propose that optional version numbers also be supported. This is use= ful to service providers who need to know which client_ids are affected whe= n certain software clients and/or versions are deprecated. The re-introduct= ion of the renamed software_id further enables "local" registration to occu= r. The first time a client tries to register, a service provider could for = example, choose to hold the registration to obtain administrative approval. The solution here is not intended to provide software "authentication" or s= oftware verification. The solution simply allows service providers to make = pragmatic decisions about sets of clients that typically work the same way = in a change managed environment. Question: What happens if the server does not support these new parameters= and the client provides them? The current draft already covers this in Se= ction 3. Specifically: The Client Registration Endpoint MUST ignore all parameters it does not un= derstand. Below are 3 options for the group to consider. My recommendation is for op= tion 1. My concern is option 2 will lead to complexity because clients and = service providers will attempt to encode versions and software identifiers = into one field. I would rather keep this to simple UUIDs for most cases. Option 1 (2 parameters): software_id This value MAY be required by registration endpoints. The value MAY be a un= ique identifier (UUID) self-assigned by a the client application developer,= or it MAY be an assertion. The value SHOULD be the same across all instanc= es of a client on an application platform. For example, software used in a = mobile phone should be considered as different from a web server implementa= tion though it may share the same code. The identifier SHOULD NOT change be= tween software updates. While a client application MAY be issued multiple c= lient_id's and client credentials over its deployment lifecycle, the softwa= re_id SHOULD NOT change. Signed assertions MAY be used as software identifiers to allow different dy= namic registration end-points to recognize approval from a common issuer (f= or example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and = the method by which developers know how to obtain assertions is out of scop= e for this specification. [editorial note: some current deployments are using temporary client creden= tial assertions for this purpose. I propose to standardize this in this fie= ld since an assertion would server the same purpose as a UUID only providin= g third party signing and other claims. I am concerned that passing a clien= t assertion for this purpose creates complexity in client authentication pr= ocessing - though obviously Justin has it working] software_version RECOMMENDED. A version indicates a client developer chosen version number. = The identifier SHOULD BE the same across all copies of client software. The= version number SHOULD change between different client updates. The intenti= on is that Service Providers MAY perform equality matching with software_id= to sub-select groups of clients of a particular software version. Option 2 (single parameter): software_id This value MAY be required by registration endpoints. The value MAY be a un= ique identifier (UUID) self-assigned by a the client application developer,= or it MAY be an assertion. The value SHOULD be the same across all instanc= es of a client on an application platform. For example, software used in a = mobile phone should be considered as different from a web server implementa= tion though it may share the same code. The identifier SHOULD change when t= he client software has changed such as with a version update or a platform = change. Signed assertions MAY be used as software identifiers to allow different dy= namic registration end-points to recognize approval from a common issuer (f= or example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and = the method by which developers know how to obtain assertions is out of scop= e for this specification. [note: same editorial note as option 1] Option 3 (no change): In this option, no changes to the draft are made. Personal comment: It has been proposed by several on the list that another= extension draft be written for these features as an extension to the dynam= ic registration draft. In my opinion, such a draft would be very small in s= ize without clear reason for separation. My feeling is that some technical = justification for keeping these features separated will likely be needed. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B1680429673943677531A1TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

We already have a “= software_id” field and it’s named “redirect_uris”.<= o:p>

 <= /p>

This doesn’t seem w= ell thought-out.  We shouldn’t try to jam it into the spec at th= e last minute.

 <= /p>

The good news is that sin= ce the registration spec allows for extensions, and the proposed fields are= optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a= route like the one proposed below.  We don’t have to do it now = for this to eventually come into being after deliberate consideration of a = complete specification including these features by the working group.

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to c= lient_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other thread,  redirect= _uri is the thing that ties together the clients as that is the place the r= esponses need to go to so is hard to fake.

 

All instances of a particular client application wil= l share the same redirect_uri across all instances.   =

 

Adding a bunch of self asserted informational fields= to the base spec is not really helping.  In a enterprise situation wh= ere all the apps play nice it might be helpfull but the reality is that you= probably allready have a MDM that lets you manage app versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=



I had a conversation with Justin yesterday to try to= come to a resolution regarding my concerns about client instances and bein= g able to associate client instances that are issued for the same client so= ftware. I think we made some progress.

 

Background:  

In RFC6749, public clients, had a common client_id. = Many interpreted client_id as refering to the client application software (= e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 = implementations that existed at the time, where there was a single SP instance.  Others have interpreted = that client_id does not refer to client applications but rather ideally sho= uld point to instances of software. To me this seems like equating a client= _id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

 

The new draft proposes that each instance be identif= ied separately. However it does so without keeping track of client software= that is the same.

 

Never-the-less, I think both interpretations can be = accommodated.

 

Finally, in single instance services (like Facebook,= Twitter, etc), there was a natural registration and approval cycle bound i= nto the client_id issuance process. The developer was able to talk to the s= ingle service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id regis= tration sites served a useful way to do application approvals.  This i= s a difficult problem to solve when there are multiple instance of Resource= API deployed in multiple locations. The developer can't contact them all.  Further, because the current d= raft loses knowledge of how to recognize that two instances of clients shar= e the same software, there's no ability to have an approval process. Each i= nstance is essentially anonymous, and thus approval processes would not be possible.  Though it does not re= quire it, this proposal makes it possible for service providers to recogniz= e new software and to have approval process.

 

Proposal:

What I have worked out with Justin (and he may not y= et fully agree with everything) is a proposal that solves the problem in an= optional way that will not break existing clients. 

 

I also propose that optional version numbers also be= supported. This is useful to service providers who need to know which clie= nt_ids are affected when certain software clients and/or versions are depre= cated. The re-introduction of the renamed software_id further enables "local" registration to occu= r. The first time a client tries to register, a service provider could for = example, choose to hold the registration to obtain administrative approval.=

 

The solution here is not intended to provide softwar= e "authentication" or software verification. The solution simply = allows service providers to make pragmatic decisions about sets of clients = that typically work the same way in a change managed environment. 

 

Question:  What happens if the server does not = support these new parameters and the client provides them?  The curren= t draft already covers this in Section 3.  Specifically: 

 The Client Registration End=
point MUST ignore all parameters it does not understand.<=
/pre>

 

Below are 3 options for the group to consider.  = ;My recommendation is for option 1. My concern is option 2 will lead to com= plexity because clients and service providers will attempt to encode versio= ns and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

 

Option 1 (2 parameters):

 

software_id

This value MAY be required by registration endpoints. The value M= AY be a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application plat= form. For example, software used in a mobile phone sh= ould be considered as different from a web server implementation though it may share the same code. The identifier&n= bsp;SHOULD NOT change between software updates. While a cl= ient application MAY be issued multiple client_id's and client credentials over= its deployment lifecycle, the software_id SHOULD NOT change.=

 

Signed assertions MAY be used as software identifiers to allow di= fferent dynamic registration end-points to recognize approval from a common= issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains)= . The decision to use assertions and the method by which developers know ho= w to obtain assertions is out of scope for this specification.<= /o:p>

 

[editorial note: some current deployments are using tempor= ary client credential assertions for this purpose. I propose to standardize= this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims= . I am concerned that passing a client assertion for this purpose creates c= omplexity in client authentication processing - though obviously Justin has= it working]

 

software_version

RECOMMENDED. A version indicates a client developer chosen versio= n number. The identifier SHOULD BE the same across all copies of client sof= tware. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perf= orm equality matching with software_id to sub-select groups of clients of a= particular software version.

 

Option 2 (single p= arameter):

 

software_id

This value MAY be required by registration endpoints. The value M= AY be a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application plat= form. For example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same cod= e. The identifier SHOULD change when the client software has changed such as with a version update or a pl= atform change.

 

Signed assertions MAY be used as software identifiers to allow di= fferent dynamic registration end-points to recognize approval from a common= issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains)= . The decision to use assertions and the method by which developers know ho= w to obtain assertions is out of scope for this specification.

 

[note: same editorial note as option 1]<= /p>

 

Option 3 (no change):

 

In this option, no changes to the draft are made.&nb= sp;

 

Personal comment:  It has been proposed by seve= ral on the list that another extension draft be written for these features = as an extension to the dynamic registration draft. In my opinion, such a dr= aft would be very small in size without clear reason for separation. My feeling is that some technical justificati= on for keeping these features separated will likely be needed.

 

 



 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943677531A1TK5EX14MBXC283r_-- From prateek.mishra@oracle.com Wed May 22 15:00:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D8521F8EEC for ; Wed, 22 May 2013 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONzN3udfaBaj for ; Wed, 22 May 2013 15:00:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C721F8F0C for ; Wed, 22 May 2013 15:00:42 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MM0e1b019482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 22:00:41 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MM0dOE022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 22:00:40 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MM0dEr018908; Wed, 22 May 2013 22:00:39 GMT Received: from [192.168.2.2] (/24.60.168.105) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 May 2013 15:00:38 -0700 Message-ID: <519D3FFB.1060208@oracle.com> Date: Wed, 22 May 2013 18:00:27 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------040207070809010606040808" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:00:54 -0000 This is a multi-part message in MIME format. --------------040207070809010606040808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics. [quote] We already have a "software_id" field and it's named "redirect_uris" [\quote] This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!! Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example. This is a practical deployment issue that also impacts the security characteristics of OAuth. It should be taken into account in the client registration process. I hope we will take the time to discuss this issue carefully and not rush to finalize a specification which has NOT received much review from the OAuth community. - prateek > +1 > > We already have a "software_id" field and it's named "redirect_uris". > > This doesn't seem well thought-out. We shouldn't try to jam it into > the spec at the last minute. > > The good news is that since the registration spec allows for > extensions, and the proposed fields are optional, these could be added > later as a non-breaking change by another spec if the working group > eventually decides to pursue a route like the one proposed below. We > don't have to do it now for this to eventually come into being after > deliberate consideration of a complete specification including these > features by the working group. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *John Bradley > *Sent:* Wednesday, May 22, 2013 2:21 PM > *To:* Phil Hunt > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to > client_id definition issue (was: Client Instances) > > Phil, > > As I pointed out in the other thread, redirect_uri is the thing that > ties together the clients as that is the place the responses need to > go to so is hard to fake. > > All instances of a particular client application will share the same > redirect_uri across all instances. > > Adding a bunch of self asserted informational fields to the base spec > is not really helping. In a enterprise situation where all the apps > play nice it might be helpfull but the reality is that you probably > allready have a MDM that lets you manage app versions. > > John > > On 2013-05-22, at 3:59 PM, Phil Hunt > wrote: > > > > I had a conversation with Justin yesterday to try to come to a > resolution regarding my concerns about client instances and being able > to associate client instances that are issued for the same client > software. I think we made some progress. > > */Background: /* > > In RFC6749, public clients, had a common client_id. Many interpreted > client_id as refering to the client application software (e.g. the > iPhone Facebook app). This is probably due to the types of OAuth2 > implementations that existed at the time, where there was a single SP > instance. Others have interpreted that client_id does not refer to > client applications but rather ideally should point to instances of > software. To me this seems like equating a client_id to being a > user-id -- IOW the key part of a credential rather than a client > identifier. > > The new draft proposes that each instance be identified separately. > However it does so without keeping track of client software that is > the same. > > Never-the-less, I think both interpretations can be accommodated. > > Finally, in single instance services (like Facebook, Twitter, etc), > there was a natural registration and approval cycle bound into the > client_id issuance process. The developer was able to talk to the > single service provider and obtain a client_id for all deployments. It > wasn't stated, but the client_id registration sites served a useful > way to do application approvals. This is a difficult problem to solve > when there are multiple instance of Resource API deployed in multiple > locations. The developer can't contact them all. Further, because the > current draft loses knowledge of how to recognize that two instances > of clients share the same software, there's no ability to have an > approval process. Each instance is essentially anonymous, and thus > approval processes would not be possible. Though it does not require > it, this proposal makes it possible for service providers to recognize > new software and to have approval process. > > */Proposal:/* > > What I have worked out with Justin (and he may not yet fully agree > with everything) is a proposal that solves the problem in an optional > way that will not break existing clients. > > I also propose that optional version numbers also be supported. This > is useful to service providers who need to know which client_ids are > affected when certain software clients and/or versions are deprecated. > The re-introduction of the renamed software_id further enables "local" > registration to occur. The first time a client tries to register, a > service provider could for example, choose to hold the registration to > obtain administrative approval. > > The solution here is not intended to provide software "authentication" > or software verification. The solution simply allows service providers > to make pragmatic decisions about sets of clients that typically work > the same way in a change managed environment. > > Question: What happens if the server does not support these new > parameters and the client provides them? The current draft already > covers this in Section 3. Specifically: > > The Client Registration Endpoint MUST ignore all parameters it does not understand. > > Below are 3 options for the group to consider. My recommendation is > for option 1. My concern is option 2 will lead to complexity because > clients and service providers will attempt to encode versions and > software identifiers into one field. I would rather keep this to > simple UUIDs for most cases. > > *Option 1 (2 parameters):* > > software_id > > This value MAY be required by registration endpoints. The value MAY be > a unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same > across all instances of a client on an application platform. For > example, software used in a mobile phone should be considered as > different from a web server implementation though it may share the > same code.The identifier *SHOULD NOT *change between software > updates. While a client application MAY be issued multiple client_id's > and client credentials over its deployment lifecycle, the software_id > SHOULD NOT change. > > Signed assertions MAY be used as software identifiers to allow > different dynamic registration end-points to recognize approval from a > common issuer (for example in cases where the resource API released by > a single publisher but deployed in many different domains). The > decision to use assertions and the method by which developers know how > to obtain assertions is out of scope for this specification. > > [editorial note: some current deployments are using temporary client > credential assertions for this purpose. I propose to standardize this > in this field since an assertion would server the same purpose as a > UUID only providing third party signing and other claims. I am > concerned that passing a client assertion for this purpose creates > complexity in client authentication processing - though obviously > Justin has it working] > > software_version > > RECOMMENDED. A version indicates a client developer chosen version > number. The identifier SHOULD BE the same across all copies of client > software. The version number SHOULD change between different client > updates. The intention is that Service Providers MAY perform equality > matching with software_id to sub-select groups of clients of a > particular software version. > > *Option 2 (single parameter):* > > software_id > > This value MAY be required by registration endpoints. The value MAY be > a unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same > across all instances of a client on an application platform. For > example, software used in a mobile phone should be considered as > different from a web server implementation though it may share the > same code. The identifier *SHOULD* change when the client software has > changed such as with a version update or a platform change. > > Signed assertions MAY be used as software identifiers to allow > different dynamic registration end-points to recognize approval from a > common issuer (for example in cases where the resource API released by > a single publisher but deployed in many different domains). The > decision to use assertions and the method by which developers know how > to obtain assertions is out of scope for this specification. > > [note: same editorial note as option 1] > > *Option 3 (no change):* > > In this option, no changes to the draft are made. > > Personal comment: It has been proposed by several on the list that > another extension draft be written for these features as an extension > to the dynamic registration draft. In my opinion, such a draft would > be very small in size without clear reason for separation. My feeling > is that some technical justification for keeping these features > separated will likely be needed. > > Phil > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040207070809010606040808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a “software_id” field and it’s named “redirect_uris”
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth.  It should be taken into account in the client registration process.

I hope we will take the time to discuss this issue carefully and not rush  to finalize a specification which has NOT received much review
from the OAuth community.

- prateek



+1

 

We already have a “software_id” field and it’s named “redirect_uris”.

 

This doesn’t seem well thought-out.  We shouldn’t try to jam it into the spec at the last minute.

 

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don’t have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other thread,  redirect_uri is the thing that ties together the clients as that is the place the responses need to go to so is hard to fake.

 

All instances of a particular client application will share the same redirect_uri across all instances.   

 

Adding a bunch of self asserted informational fields to the base spec is not really helping.  In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

 

Background:  

In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance.  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

 

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

 

Never-the-less, I think both interpretations can be accommodated.

 

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

 

Proposal:

What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients. 

 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

 

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

 

Question:  What happens if the server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3.  Specifically:

 The Client Registration Endpoint MUST ignore all parameters it does not understand.

 

Below are 3 options for the group to consider.  My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

 

Option 1 (2 parameters):

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change between software updates. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

 

software_version

RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

 

Option 2 (single parameter):

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when the client software has changed such as with a version update or a platform change.

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[note: same editorial note as option 1]

 

Option 3 (no change):

 

In this option, no changes to the draft are made. 

 

Personal comment:  It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

 

 



 

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

 



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

--------------040207070809010606040808-- From ve7jtb@ve7jtb.com Wed May 22 15:16:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11D821F8E49 for ; Wed, 22 May 2013 15:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6mL1uBiWXRm for ; Wed, 22 May 2013 15:15:59 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C518D21F8E2C for ; Wed, 22 May 2013 15:15:58 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ii15so1296867qab.3 for ; Wed, 22 May 2013 15:15:58 -0700 (PDT) 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=pyRPpPvqmnD/2yue4i1jncN374lZKVEElvcw1fDk6Zo=; b=ZQ9NvP5SdnhQt0adcS1jgdBf0kORjwgagcSTKGa7ktBccLhiEKL2x9rKyW7JPQC2oI 8x07VP8XDLWOjFpUnSp67m5qtZ9X0wb8/nyZg7vHfgjp7iA+QvGj3kQ83YSCwFNllTYs mFkVmY0T4SpdVNyTMYSAcZHbdn/kbI+M0sxMbSUk41z3O5h4tLIaEVEB01eJASms6gJq J58iFZ90Ro/CNNj274fp7CTTXgEitMlsishTO47woJmz3mlaF7vcRMe+X3Qq7AUvZ0ra +jw7k9s/5knGtSeMEqX0YsNj/mzZ8kdex7pnpQ5nLU+ABYCpkYBeA3FS7U/H6blNXuMc qkqw== X-Received: by 10.49.4.194 with SMTP id m2mr2912149qem.3.1369260958026; Wed, 22 May 2013 15:15:58 -0700 (PDT) Received: from [192.168.1.36] (190-20-39-239.baf.movistar.cl. [190.20.39.239]) by mx.google.com with ESMTPSA id y14sm8759642qac.0.2013.05.22.15.15.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 May 2013 15:15:56 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4E4F355E-A1EC-4A00-A5ED-C79B775FD301"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <519D3FFB.1060208@oracle.com> Date: Wed, 22 May 2013 18:15:53 -0400 Message-Id: <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> To: prateek mishra X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmis1JZNLwlNYuPvqQ9L6zXh6JwzJfQhwF/89ZmGuZ5KAko4CEy/Y8RZZy666P97tl26R0v Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:16:01 -0000 --Apple-Mail=_4E4F355E-A1EC-4A00-A5ED-C79B775FD301 Content-Type: multipart/alternative; boundary="Apple-Mail=_E79B91F2-CD62-4F73-9DD6-B7F464BEAB20" --Apple-Mail=_E79B91F2-CD62-4F73-9DD6-B7F464BEAB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 At the moment for Mobile devices and other native apps all we have to = reliably identify the app is the redirect_uri. =20 The client_id is trivially faked in native apps.=20 Yes in a well groomed enterprise trusting a self asserted software = identifier is nice but probably doesn't scale to the real world. I have had discussions with MDM venders about how you might be able to = tie access tokens to a instance of software on a device and determine if = that software is allowed to be run by that user on that device. These are all much more complicated discussions than just sticking = another registration parameter on. I don't think this should block the basic dynamic registration spec. = App lifecycle needs a full spec, and additional registration parameters = can be added later if required. I am not insensitive to the problem. John B. On 2013-05-22, at 6:00 PM, prateek mishra = wrote: > Well, I have to say that if anything seems poorly thought out, it = would be a design with the following characteristics. >=20 > [quote] > We already have a =93software_id=94 field and it=92s named = =93redirect_uris=94 > [\quote] >=20 > This seems to violate the most basic principles of software design - = overloading a field with meaning distinct from its primary purpose!! >=20 > Phil has raised some substantive questions regarding client meta-data = and the registration process. This information (software_id) is > essential for identifying and disabling a class of clients that may = have been found to have some security flaws, for example.=20 > This is a practical deployment issue that also impacts the security = characteristics of OAuth. It should be taken into account in the client = registration process.=20 >=20 > I hope we will take the time to discuss this issue carefully and not = rush to finalize a specification which has NOT received much review > from the OAuth community. >=20 > - prateek >=20 >=20 >=20 >> +1 >> =20 >> We already have a =93software_id=94 field and it=92s named = =93redirect_uris=94. >> =20 >> This doesn=92t seem well thought-out. We shouldn=92t try to jam it = into the spec at the last minute. >> =20 >> The good news is that since the registration spec allows for = extensions, and the proposed fields are optional, these could be added = later as a non-breaking change by another spec if the working group = eventually decides to pursue a route like the one proposed below. We = don=92t have to do it now for this to eventually come into being after = deliberate consideration of a complete specification including these = features by the working group. >> =20 >> -- = Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of John Bradley >> Sent: Wednesday, May 22, 2013 2:21 PM >> To: Phil Hunt >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to = client_id definition issue (was: Client Instances) >> =20 >> Phil, >> =20 >> As I pointed out in the other thread, redirect_uri is the thing that = ties together the clients as that is the place the responses need to go = to so is hard to fake. >> =20 >> All instances of a particular client application will share the same = redirect_uri across all instances. =20 >> =20 >> Adding a bunch of self asserted informational fields to the base spec = is not really helping. In a enterprise situation where all the apps = play nice it might be helpfull but the reality is that you probably = allready have a MDM that lets you manage app versions. >> =20 >> John=20 >> =20 >> On 2013-05-22, at 3:59 PM, Phil Hunt wrote: >>=20 >>=20 >> I had a conversation with Justin yesterday to try to come to a = resolution regarding my concerns about client instances and being able = to associate client instances that are issued for the same client = software. I think we made some progress. >> =20 >> Background: =20 >> In RFC6749, public clients, had a common client_id. Many interpreted = client_id as refering to the client application software (e.g. the = iPhone Facebook app). This is probably due to the types of OAuth2 = implementations that existed at the time, where there was a single SP = instance. Others have interpreted that client_id does not refer to = client applications but rather ideally should point to instances of = software. To me this seems like equating a client_id to being a user-id = -- IOW the key part of a credential rather than a client identifier.=20 >> =20 >> The new draft proposes that each instance be identified separately. = However it does so without keeping track of client software that is the = same. >> =20 >> Never-the-less, I think both interpretations can be accommodated. >> =20 >> Finally, in single instance services (like Facebook, Twitter, etc), = there was a natural registration and approval cycle bound into the = client_id issuance process. The developer was able to talk to the single = service provider and obtain a client_id for all deployments. It wasn't = stated, but the client_id registration sites served a useful way to do = application approvals. This is a difficult problem to solve when there = are multiple instance of Resource API deployed in multiple locations. = The developer can't contact them all. Further, because the current = draft loses knowledge of how to recognize that two instances of clients = share the same software, there's no ability to have an approval process. = Each instance is essentially anonymous, and thus approval processes = would not be possible. Though it does not require it, this proposal = makes it possible for service providers to recognize new software and to = have approval process. >> =20 >> Proposal: >> What I have worked out with Justin (and he may not yet fully agree = with everything) is a proposal that solves the problem in an optional = way that will not break existing clients.=20 >> =20 >> I also propose that optional version numbers also be supported. This = is useful to service providers who need to know which client_ids are = affected when certain software clients and/or versions are deprecated. = The re-introduction of the renamed software_id further enables "local" = registration to occur. The first time a client tries to register, a = service provider could for example, choose to hold the registration to = obtain administrative approval. >> =20 >> The solution here is not intended to provide software = "authentication" or software verification. The solution simply allows = service providers to make pragmatic decisions about sets of clients that = typically work the same way in a change managed environment.=20 >> =20 >> Question: What happens if the server does not support these new = parameters and the client provides them? The current draft already = covers this in Section 3. Specifically: >> The Client Registration Endpoint MUST ignore all parameters it does = not understand. >> =20 >> Below are 3 options for the group to consider. My recommendation is = for option 1. My concern is option 2 will lead to complexity because = clients and service providers will attempt to encode versions and = software identifiers into one field. I would rather keep this to simple = UUIDs for most cases. >> =20 >> Option 1 (2 parameters): >> =20 >> software_id >> This value MAY be required by registration endpoints. The value MAY = be a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD NOT change between software updates. While a = client application MAY be issued multiple client_id's and client = credentials over its deployment lifecycle, the software_id SHOULD NOT = change. >> =20 >> Signed assertions MAY be used as software identifiers to allow = different dynamic registration end-points to recognize approval from a = common issuer (for example in cases where the resource API released by a = single publisher but deployed in many different domains). The decision = to use assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. >> =20 >> [editorial note: some current deployments are using temporary client = credential assertions for this purpose. I propose to standardize this in = this field since an assertion would server the same purpose as a UUID = only providing third party signing and other claims. I am concerned that = passing a client assertion for this purpose creates complexity in client = authentication processing - though obviously Justin has it working] >> =20 >> software_version >> RECOMMENDED. A version indicates a client developer chosen version = number. The identifier SHOULD BE the same across all copies of client = software. The version number SHOULD change between different client = updates. The intention is that Service Providers MAY perform equality = matching with software_id to sub-select groups of clients of a = particular software version. >> =20 >> Option 2 (single parameter): >> =20 >> software_id >> This value MAY be required by registration endpoints. The value MAY = be a unique identifier (UUID) self-assigned by a the client application = developer, or it MAY be an assertion. The value SHOULD be the same = across all instances of a client on an application platform. For = example, software used in a mobile phone should be considered as = different from a web server implementation though it may share the same = code. The identifier SHOULD change when the client software has changed = such as with a version update or a platform change. >> =20 >> Signed assertions MAY be used as software identifiers to allow = different dynamic registration end-points to recognize approval from a = common issuer (for example in cases where the resource API released by a = single publisher but deployed in many different domains). The decision = to use assertions and the method by which developers know how to obtain = assertions is out of scope for this specification. >> =20 >> [note: same editorial note as option 1] >> =20 >> Option 3 (no change): >> =20 >> In this option, no changes to the draft are made.=20 >> =20 >> Personal comment: It has been proposed by several on the list that = another extension draft be written for these features as an extension to = the dynamic registration draft. In my opinion, such a draft would be = very small in size without clear reason for separation. My feeling is = that some technical justification for keeping these features separated = will likely be needed. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=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 --Apple-Mail=_E79B91F2-CD62-4F73-9DD6-B7F464BEAB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 At = the moment for Mobile devices and other native apps all we have to = reliably identify the app is the redirect_uri. =  

The client_id is trivially faked in native = apps. 

Yes in a well groomed enterprise = trusting a self asserted software identifier is nice but probably = doesn't scale to the real world.

I have had = discussions with MDM venders about how you might be able to tie access = tokens to a instance of software on a device and determine if that = software is allowed to be run by that user on that = device.
These are all much more complicated discussions than = just sticking another registration parameter = on.

I don't think this should block the basic = dynamic registration spec.   App lifecycle needs a full spec, and = additional registration parameters can be added later if = required.

I am not insensitive to the = problem.

John B.
On = 2013-05-22, at 6:00 PM, prateek mishra <prateek.mishra@oracle.com>= ; wrote:

=20 =20
Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a =93software_id=94 field and it=92s named = =93redirect_uris=94
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary = purpose!!

Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth.  It should be taken into account in = the client registration process.

I hope we will take the time to discuss this issue carefully and not rush  to finalize a specification which has NOT received much = review
from the OAuth community.

- prateek



+1

 

We already have a =93software_id=94 field and it=92s named =93redirect_uris=94.

 

This doesn=92t seem well thought-out.  We shouldn=92t try to = jam it into the spec at the last minute.

 

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don=92t have to = do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other = thread,  redirect_uri is the thing that ties together the = clients as that is the place the responses need to go to so is hard to fake.

 

All instances of a particular client application will share the same redirect_uri across all instances.   

 

Adding a bunch of self asserted informational fields to the base spec is not really helping.  In a enterprise situation where all the apps play nice = it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app = versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil = Hunt <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some = progress.

 

Background: =  

In RFC6749, public clients, = had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance. =  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client = identifier. 

 

The new draft proposes that = each instance be identified separately. However it does so without keeping track of client software that is the same.

 

Never-the-less, I think both interpretations can be accommodated.

 

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This = is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses = knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval = process.

 

Proposal:

What I have worked out with = Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing = clients. 

 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

 

The solution here is not = intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

 

Question:  What happens = if the server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3. =  Specifically:

 The Client Registration Endpoint MUST ignore =
all parameters it does not understand.

 

Below are 3 options for the = group to consider.  My recommendation is for option 1. = My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most = cases.

 

Option 1 (2 = parameters):

 

software_id

This value MAY = be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change = between software updates. While a client = application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT = change.

 

Signed = assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

 

software_version

RECOMMENDED. A = version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

 

Option 2 (single = parameter):

 

software_id

This value MAY = be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when = the client software has changed such as with a version update or a platform change.

 <= /span>

Signed = assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[note: same editorial note as option = 1]

 

Option 3 (no = change):

 

In this option, no changes = to the draft are made. 

 

Personal comment:  It = has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be = needed.

 

 



 

_______________________________________________
OAuth mailing 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=_E79B91F2-CD62-4F73-9DD6-B7F464BEAB20-- --Apple-Mail=_4E4F355E-A1EC-4A00-A5ED-C79B775FD301 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIyMjIxNTU0WjAjBgkqhkiG9w0BCQQxFgQUSvf3DqIf hWPMQ+0y9L/4yXkvsMIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAWoHHupjOOYF86n19KzDuHeovBdyHg5QU4ydFKbnM CDbZWVWDe+5tkcpVD52EFcRIe+mHOoC+EBw+SSjMmQTuUu8EaCcqtQ4SI2v7MkVjKEU8fa3LknYY UA/+c2/QSXfuDsNhVCA+mJOp+fNS/R5IXSZgRPSJaQIPdI+XFAqXCVkW7k+6mkeJhKx45k/9Ycqa 8JJ8CCR5dapUZXgkpYbquZUveKlXUmGNuPemcYfXh01/mINAgn7lO5bSP9RLeLpqTpOOR7mB741I R6P3TARhoFRByPnets8MCVlTw7RtAhfzIMX3z/r1OObYcyjYK0HIUzPgkEoVymNtp0F2679MKQAA AAAAAA== --Apple-Mail=_4E4F355E-A1EC-4A00-A5ED-C79B775FD301-- From phil.hunt@oracle.com Wed May 22 15:16:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDE511E813A for ; Wed, 22 May 2013 15:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMeRe1Y+XWGt for ; Wed, 22 May 2013 15:16:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DA27E21F8E8E for ; Wed, 22 May 2013 15:16:16 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MMGF62032209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 22:16:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MMGER6026277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 22:16:14 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MMGDQ2003174; Wed, 22 May 2013 22:16:13 GMT Received: from [25.129.30.15] (/24.114.94.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 May 2013 15:16:13 -0700 References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <519D2BE4.6080303@mitre.org> <8ae4313deafe4397b0b312ef38dcf182@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8ae4313deafe4397b0b312ef38dcf182@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4733A914-17CD-4EC5-A659-68A1B54699B2 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 22 May 2013 15:16:07 -0700 To: Anthony Nadalin X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:16:23 -0000 --Apple-Mail-4733A914-17CD-4EC5-A659-68A1B54699B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm having trouble understanding > We already have OAuth doing dynamic registration, I don=E2=80=99t think th= ere is a need to force it into OAuth. > =20 I would be open to a scim dyn reg version. Particularly to discuss instance m= etadata mgt which scim is good at and the credential managemenr/bootstrap pr= ocess as it pertains to oauth. Never-the-less the overwhelming priority has= been apparently to simply standardize oidc and uma implementations as is. T= his I am not comfortable with but i can live with if there is give and take.= =20 I feel the subject is well in charter and is an important issue due to the l= ife-cycle management issues behind clients and the need to make public clien= ts the security equiv. of confidential clients.=20 Phil On 2013-05-22, at 14:22, Anthony Nadalin wrote: > I totally disagree with your characterization of SCIM, while it can be use= d from server to server (provision one system to another) it can also be cli= ent to endpoint (initial provisioning and JIT provisioning). SCIM is fairly s= imple (but can be complex), I also have concerns about SCIM not being 100% r= estful but that does not stop us from using it. I also agree that we should l= et OAuth do what it=E2=80=99s good at and don=E2=80=99t try to force it into= something that it=E2=80=99s not. We already have OAuth doing dynamic regist= ration, I don=E2=80=99t think there is a need to force it into OAuth. > =20 > =20 > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Wednesday, May 22, 2013 1:35 PM > To: Anthony Nadalin > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > =20 > I'm not sure why you don't think it's in scope, it's in the working group'= s charter: >=20 > http://www.ietf.org/dyn/wg/charter/oauth-charter.html >=20 > So ... it's definitely in scope, and has been for over a year and a half. T= his is the tenth version of this document-- an IETF Working Group document a= t that-- that's been posted to the group with every revision and there has b= een significant conversation around it, especially over the last six months s= ince I took over the editor role. There are also a handful of implementation= s of this, and while most of them are built to do OpenID Connect or UMA (whi= ch are directly built on OAuth), I know there are some that also do plain OA= uth. (Not the least of which is one that I have personally implemented and d= eployed.) >=20 > SCIM doesn't solve client management particularly well, since it's made fo= r users more than anything. The usage model of SCIM is also quite different -= - it's really intended to be used between two servers to transfer informatio= n, as opposed to handling self-asserted claims. I understand that some imple= mentations like UAA have done their static registration using a SCIM profile= , but it's not dynamic registration, really. I think it's too much of a squa= re-peg-round-hole problem, at least with SCIM as it is today; so let SCIM do= what it's good at, and don't try to force it into something it's not. >=20 > Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynami= c Registration was meant to be a fairly simple REST/JSON API that would be e= asy to implement, especially for clients. Just because SCIM is RESTful doesn= 't mean it's a good structure for other RESTful APIs. Namely, I don't think t= he extra structure and hooks with SCIM really buy you anything here, especia= lly with the additions and changes you'd have to make to SCIM. >=20 > And finally, nobody to date has actually written a proposal that is even r= emotely SCIM based.=20 >=20 > -- Justin >=20 > On 05/22/2013 02:39 PM, Anthony Nadalin wrote: > So, I really don=E2=80=99t understand why dynamic registration is in scope= , I understand this relative to OpenID Connect but not OAuth, if this is ind= eed in scope then I would have expected that the endpoint be based upon SCIM= and not something else like what has been done here. > =20 > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Monday, May 20, 2013 11:10 AM > To: Anthony Nadalin > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > =20 > Tony, can you be more specific? What needs to be changed in your opinion? W= hat text changes would you suggest? >=20 > -- Justin >=20 > On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > Agree > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt > Sent: Monday, May 20, 2013 9:42 AM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > =20 > This draft isn't ready for LC.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:49, Justin Richer wrote: >=20 > But also keep in mind that this is last-call, and that we don't really wan= t to encourage avoidable drastic changes at this stage.=20 >=20 > -- Justin >=20 >=20 >=20 >=20 > On 05/20/2013 11:21 AM, Phil Hunt wrote: > Keep in mind there may be other changes coming.=20 > =20 > The issue is that new developers can't figure out what token is being refe= rred to.=20 >=20 > Phil >=20 > On 2013-05-20, at 8:09, Justin Richer wrote: >=20 > Phil Hunt's review of the Dynamic Registration specification has raised a c= ouple of issues that I felt were getting buried by the larger discussion (wh= ich I still strongly encourage others to jump in to). Namely, Phil has sugge= sted a couple of syntax changes to the names of several parameters.=20 >=20 >=20 > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >=20 >=20 > I'd like to get a feeling, especially from developers who have deployed th= is draft spec, what we ought to do for each of these: >=20 > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify >=20 > In all cases, clarifying text will be added to the parameter *definitions*= so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned, since we s= houldn't change syntax without very good reason to do so. That said, if it's= going to be better for developers with the new parameter names, I am open t= o fixing them now. >=20 > Naming things is hard. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 --Apple-Mail-4733A914-17CD-4EC5-A659-68A1B54699B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm having trouble understanding
=

We already h= ave OAuth doing dynamic registration, I don=E2=80=99t think there is a need t= o force it into OAuth.

 


I would be open to= a scim dyn reg version. Particularly to discuss instance metadata mgt which= scim is good at and the credential managemenr/bootstrap process as it perta= ins to oauth.  Never-the-less the overwhelming priority has been appare= ntly to simply standardize oidc and uma implementations as is. This I am not= comfortable with but i can live with if there is give and take. 
=

I feel the subject is well in charter and is an importan= t issue due to the life-cycle management issues behind clients and the need t= o make public clients the security equiv. of confidential clients. 

Phil

On 2013-05-22, at 14:22, Anthony Na= dalin <tonynad@microsoft.com= > wrote:

I totally disagree with you= r characterization of SCIM, while it can be used from server to server (prov= ision one system to another) it can also be client to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple= (but can be complex), I also have concerns about SCIM not being 100% restfu= l but that does not stop us from using it. I also agree that we should let O= Auth do what it=E2=80=99s good at and don=E2=80=99t try to force it into something that it=E2=80=99s not. We alre= ady have OAuth doing dynamic registration, I don=E2=80=99t think there is a n= eed to force it into OAuth.

 

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrati= on

 

I'm not sure why you d= on't think it's in scope, it's in the working group's charter:

  htt= p://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a half. Th= is is the tenth version of this document-- an IETF Working Group document at= that-- that's been posted to the group with every revision and there has be= en significant conversation around it, especially over the last six months since I took over the editor role. T= here are also a handful of implementations of this, and while most of them a= re built to do OpenID Connect or UMA (which are directly built on OAuth), I k= now there are some that also do plain OAuth. (Not the least of which is one that I have personally imple= mented and deployed.)

SCIM doesn't solve client management particularly well, since it's made for u= sers more than anything. The usage model of SCIM is also quite different -- i= t's really intended to be used between two servers to transfer information, a= s opposed to handling self-asserted claims. I understand that some implementations like UAA have done their sta= tic registration using a SCIM profile, but it's not dynamic registration, re= ally. I think it's too much of a square-peg-round-hole problem, at least wit= h SCIM as it is today; so let SCIM do what it's good at, and don't try to force it into something it's no= t.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic R= egistration was meant to be a fairly simple REST/JSON API that would be easy= to implement, especially for clients. Just because SCIM is RESTful doesn't m= ean it's a good structure for other RESTful APIs. Namely, I don't think the extra structure and hooks wit= h SCIM really buy you anything here, especially with the additions and chang= es you'd have to make to SCIM.

And finally, nobody to date has actually written a proposal that is even rem= otely SCIM based.

 -- Justin

On 05/22/2013 02:39 PM, Anthony Nadalin wrote:

So, I really don=E2=80=99t u= nderstand why dynamic registration is in scope, I understand this relative t= o OpenID Connect but not OAuth, if this is indeed in scope then I would have expected that the endpoint be based upon SCIM and not somethin= g else like what has been done here.

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrati= on

 

Tony, can you be more s= pecific? What needs to be changed in your opinion? What text changes would y= ou suggest?

 -- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin wrote:

Agree

=

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrati= on

 

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind t= hat this is last-call, and that we don't really want to encourage avoidable d= rastic changes at this stage.

 -- Justin



On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. =

 

The issue is that new developers can't figure out wha= t token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specif= ication has raised a couple of issues that I felt were getting buried by the= larger discussion (which I still strongly encourage others to jump in to). N= amely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deploy= ed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* s= o that it's more clear to people reading the spec what each piece does. Spea= king as the editor: "A" is the default as far as I'm concerned, since we sho= uldn't change syntax without very good reason to do so. That said, if it's going to be better for develo= pers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 

 

 

= --Apple-Mail-4733A914-17CD-4EC5-A659-68A1B54699B2-- From phil.hunt@oracle.com Wed May 22 15:19:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739221F8454 for ; Wed, 22 May 2013 15:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swT4jOAD1zPg for ; Wed, 22 May 2013 15:19:41 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB821F8B98 for ; Wed, 22 May 2013 15:19:40 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MMJba8020844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 22:19:38 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MMJd1M002012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 22:19:39 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MMJcbh002000; Wed, 22 May 2013 22:19:38 GMT Received: from [25.129.30.15] (/24.114.94.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 May 2013 15:19:37 -0700 References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> Content-Type: multipart/alternative; boundary=Apple-Mail-A4DB2B92-CA77-40F2-AC2D-8C66E5B98D60 Content-Transfer-Encoding: 7bit Message-Id: <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 22 May 2013 15:19:32 -0700 To: John Bradley X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:19:46 -0000 --Apple-Mail-A4DB2B92-CA77-40F2-AC2D-8C66E5B98D60 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I dont see a big issue with a faked software_id. As i said it was a minimal p= roposal with the door open to stronger assertions.=20 Rogue clients pretending to be something they are not is actually more evide= nce of a problem. In draft 10 you cant even do that.=20 Phil On 2013-05-22, at 15:15, John Bradley wrote: > At the moment for Mobile devices and other native apps all we have to reli= ably identify the app is the redirect_uri. =20 >=20 > The client_id is trivially faked in native apps.=20 >=20 > Yes in a well groomed enterprise trusting a self asserted software identif= ier is nice but probably doesn't scale to the real world. >=20 > I have had discussions with MDM venders about how you might be able to tie= access tokens to a instance of software on a device and determine if that s= oftware is allowed to be run by that user on that device. > These are all much more complicated discussions than just sticking another= registration parameter on. >=20 > I don't think this should block the basic dynamic registration spec. App= lifecycle needs a full spec, and additional registration parameters can be a= dded later if required. >=20 > I am not insensitive to the problem. >=20 > John B. > On 2013-05-22, at 6:00 PM, prateek mishra wrot= e: >=20 >> Well, I have to say that if anything seems poorly thought out, it would b= e a design with the following characteristics. >>=20 >> [quote] >> We already have a =E2=80=9Csoftware_id=E2=80=9D field and it=E2=80=99s na= med =E2=80=9Credirect_uris=E2=80=9D >> [\quote] >>=20 >> This seems to violate the most basic principles of software design - over= loading a field with meaning distinct from its primary purpose!! >>=20 >> Phil has raised some substantive questions regarding client meta-data and= the registration process. This information (software_id) is >> essential for identifying and disabling a class of clients that may have b= een found to have some security flaws, for example.=20 >> This is a practical deployment issue that also impacts the security chara= cteristics of OAuth. It should be taken into account in the client registra= tion process.=20 >>=20 >> I hope we will take the time to discuss this issue carefully and not rush= to finalize a specification which has NOT received much review >> from the OAuth community. >>=20 >> - prateek >>=20 >>=20 >>=20 >>> +1 >>> =20 >>> We already have a =E2=80=9Csoftware_id=E2=80=9D field and it=E2=80=99s n= amed =E2=80=9Credirect_uris=E2=80=9D. >>> =20 >>> This doesn=E2=80=99t seem well thought-out. We shouldn=E2=80=99t try to= jam it into the spec at the last minute. >>> =20 >>> The good news is that since the registration spec allows for extensions,= and the proposed fields are optional, these could be added later as a non-b= reaking change by another spec if the working group eventually decides to pu= rsue a route like the one proposed below. We don=E2=80=99t have to do it no= w for this to eventually come into being after deliberate consideration of a= complete specification including these features by the working group. >>> =20 >>> = -- Mike >>> =20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f John Bradley >>> Sent: Wednesday, May 22, 2013 2:21 PM >>> To: Phil Hunt >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to clien= t_id definition issue (was: Client Instances) >>> =20 >>> Phil, >>> =20 >>> As I pointed out in the other thread, redirect_uri is the thing that ti= es together the clients as that is the place the responses need to go to so i= s hard to fake. >>> =20 >>> All instances of a particular client application will share the same red= irect_uri across all instances. =20 >>> =20 >>> Adding a bunch of self asserted informational fields to the base spec is= not really helping. In a enterprise situation where all the apps play nice= it might be helpfull but the reality is that you probably allready have a M= DM that lets you manage app versions. >>> =20 >>> John=20 >>> =20 >>> On 2013-05-22, at 3:59 PM, Phil Hunt wrote: >>>=20 >>>=20 >>> I had a conversation with Justin yesterday to try to come to a resolutio= n regarding my concerns about client instances and being able to associate c= lient instances that are issued for the same client software. I think we mad= e some progress. >>> =20 >>> Background: =20 >>> In RFC6749, public clients, had a common client_id. Many interpreted cli= ent_id as refering to the client application software (e.g. the iPhone Faceb= ook app). This is probably due to the types of OAuth2 implementations that e= xisted at the time, where there was a single SP instance. Others have inter= preted that client_id does not refer to client application= s but rather ideally should point to instances of software. To me this seems= like equating a client_id to being a user-id -- IOW the key part of a crede= ntial rather than a client identifier.=20 >>> =20 >>> The new draft proposes that each instance be identified separately. Howe= ver it does so without keeping track of client software that is the same. >>> =20 >>> Never-the-less, I think both interpretations can be accommodated. >>> =20 >>> Finally, in single instance services (like Facebook, Twitter, etc), ther= e was a natural registration and approval cycle bound into the client_id iss= uance process. The developer was able to talk to the single service provider= and obtain a client_id for all deployments. It wasn't stated, but the clien= t_id registration sites served a useful way to do application approvals. Th= is is a difficult problem to solve when there are multiple instance of Resou= rce API deployed in multiple locations. The developer can't contact them all= . Further, because the current draft loses knowledge of how to recognize th= at two instances of clients share the same software, there's no ability to h= ave an approval process. Each instance is essentially anonymous, and thus ap= proval processes would not be possible. Though it does not require it, this= proposal makes it possible for service providers to recognize new software a= nd to have approval process. >>> =20 >>> Proposal: >>> What I have worked out with Justin (and he may not yet fully agree with e= verything) is a proposal that solves the problem in an optional way that wil= l not break existing clients.=20 >>> =20 >>> I also propose that optional version numbers also be supported. This is u= seful to service providers who need to know which client_ids are affected wh= en certain software clients and/or versions are deprecated. The re-introduct= ion of the renamed software_id further enables "local" reg= istration to occur. The first time a client tries to register, a service pro= vider could for example, choose to hold the registration to obtain administr= ative approval. >>> =20 >>> The solution here is not intended to provide software "authentication" o= r software verification. The solution simply allows service providers to mak= e pragmatic decisions about sets of clients that typically work the same way= in a change managed environment.=20 >>> =20 >>> Question: What happens if the server does not support these new paramet= ers and the client provides them? The current draft already covers this in S= ection 3. Specifically: >>> The Client Registration Endpoint MUST ignore all parameters it does not= understand. >>> =20 >>> Below are 3 options for the group to consider. My recommendation is for= option 1. My concern is option 2 will lead to complexity because clients an= d service providers will attempt to encode versions and software identifiers= into one field. I would rather keep this to simple UUIDs for most cases. >>> =20 >>> Option 1 (2 parameters): >>> =20 >>> software_id >>> This value MAY be required by registration endpoints. The value MAY be a= unique identifier (UUID) self-assigned by a the client application develope= r, or it MAY be an assertion. The value SHOULD be the same across all instan= ces of a client on an application platform. For ex= ample, software used in a mobile phone should be considered as different fro= m a web server implementation though it may share the same code. The identif= ier SHOULD NOT change between software updates. While a client application M= AY be issued multiple client_id's and client credentials over its deployment= lifecycle, the software_id SHOULD NOT change. >>> =20 >>> Signed assertions MAY be used as software identifiers to allow different= dynamic registration end-points to recognize approval from a common issuer (= for example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and t= he method by which developers know how to obtain assertions is out of scope f= or this specification. >>> =20 >>> [editorial note: some current deployments are using temporary client cre= dential assertions for this purpose. I propose to standardize this in this f= ield since an assertion would server the same purpose as a UUID only providi= ng third party signing and other claims. I am concerned that passing a clien= t assertion for this purpose creates complexity in client authentication pro= cessing - though obviously Justin has it working] >>> =20 >>> software_version >>> RECOMMENDED. A version indicates a client developer chosen version numbe= r. The identifier SHOULD BE the same across all copies of client software. T= he version number SHOULD change between different cl= ient updates. The intention is that Service Providers MAY perform equality m= atching with software_id to sub-select groups of clients of a particular sof= tware version. >>> =20 >>> Option 2 (single parameter): >>> =20 >>> software_id >>> This value MAY be required by registration endpoints. The value MAY be a= unique identifier (UUID) self-assigned by a the client application develope= r, or it MAY be an assertion. The value SHOULD be the same across all instan= ces of a client on an application platform. For example, software used in a m= obile phone should be considered as different from a web server implementati= on though it may share the same code. The identifier SHOULD change when the c= lient software has changed such as with a version update or a platform chang= e. >>> =20 >>> Signed assertions MAY be used as software identifiers to allow different= dynamic registration end-points to recognize approval from a common issuer (= for example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and t= he method by which developers know how to obtain assertions is out of scope f= or this specification. >>> =20 >>> [note: same editorial note as option 1] >>> =20 >>> Option 3 (no change): >>> =20 >>> In this option, no changes to the draft are made.=20 >>> =20 >>> Personal comment: It has been proposed by several on the list that anot= her extension draft be written for these features as an extension to the dyn= amic registration draft. In my opinion, such a draft would be very small in s= ize without clear reason for separation. My feeling is t= hat some technical justification for keeping these features separated will l= ikely be needed. >>> =20 >>> Phil >>> =20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>> =20 >>>=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 --Apple-Mail-A4DB2B92-CA77-40F2-AC2D-8C66E5B98D60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I dont see a big issue with a faked so= ftware_id. As i said it was a minimal proposal with the door open to stronge= r assertions. 

Rogue clients pretending to be s= omething they are not is actually more evidence of a problem. In draft 10 yo= u cant even do that. 

Phil

On 2013-05-22, at 15:15= , John Bradley <ve7jtb@ve7jtb.com> wrote:

At the moment fo= r Mobile devices and other native apps all we have to reliably identify the a= pp is the redirect_uri.  

The client_id is trivially= faked in native apps. 

Yes in a well groomed e= nterprise trusting a self asserted software identifier is nice but probably d= oesn't scale to the real world.

I have had discussi= ons with MDM venders about how you might be able to tie access tokens to a i= nstance of software on a device and determine if that software is allowed to= be run by that user on that device.
These are all much more compl= icated discussions than just sticking another registration parameter on.

I don't think this should block the basic dynamic regi= stration spec.   App lifecycle needs a full spec, and additional regist= ration parameters can be added later if required.

I= am not insensitive to the problem.

John B.
=20 =20
Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a =E2=80=9Csoftware_id=E2=80=9D field and it=E2=80=99s na= med =E2=80=9Credirect_uris=E2=80=9D
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!
=
Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth.  It should be taken into account in the client registration process.

I hope we will take the time to discuss this issue carefully and not rush  to finalize a specification which has NOT received much revie= w
from the OAuth community.

- prateek



+1

 

We already have a =E2=80=9Csoftware_id=E2=80=9D field and it=E2=80=99= s named =E2=80=9Credirect_uris=E2=80=9D.

 

This doesn=E2=80=99t seem well thought-out.  We shouldn=E2=80=99= t try to jam it into the spec at the last minute.

 

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don=E2=80=99t have t= o do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other thread,  redirect_uri is the thing that ties together the clients a= s that is the place the responses need to go to so is hard to fake.

 

All instances of a particular client application will share the same redirect_uri across all instances.   

 

Adding a bunch of self asserted informational fields to the base spec is not really helping.  In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil Hunt= <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

 

Background:  

In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance.  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

 

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

 

Never-the-less, I think both interpretations can be accommodated.

 

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This is a= difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses knowledge= of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

 

Proposal:=

What I have worked out with Justin= (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients. 

=

 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

 

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

 

Question:  What happens if th= e server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3.  Specifically: 

 The Client R=
egistration Endpoint MUST ignore all parameters it does not understand.=

 

Below are 3 options for the group to consider.  My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

 

Option 1 (2 parameters):

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change betw= een software updates. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.<= /o:p>

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

 

software_version

RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

 

Option 2 (single parameter):=

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when the c= lient software has changed such as with a version update or a platform change.

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[note: same editorial note as option 1]=

 

Option 3 (no change):

 

In this option, no changes to th= e draft are made. 

 

Personal comment:  It has b= een proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

=

 

 

___________________________________= ____________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 



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


= --Apple-Mail-A4DB2B92-CA77-40F2-AC2D-8C66E5B98D60-- From jricher@mitre.org Wed May 22 15:22:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E604711E814C for ; Wed, 22 May 2013 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSebfLjS5EQU for ; Wed, 22 May 2013 15:22:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 093CD11E813A for ; Wed, 22 May 2013 15:22:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 813A6229000F; Wed, 22 May 2013 18:22:09 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 58D611F07A5; Wed, 22 May 2013 18:22:09 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 18:22:09 -0400 Message-ID: <519D44F2.7080506@mitre.org> Date: Wed, 22 May 2013 18:21:38 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> In-Reply-To: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> Content-Type: multipart/alternative; boundary="------------000008080302020300010707" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:22:24 -0000 --------------000008080302020300010707 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit There are two main things that I dislike about this proposal, but neither are insurmountable in my view. 1) Version. I think that the entire notion of "version" is as slippery a slope as "software identifier" is in the first place. And as soon as you start talking about "version" people are going to want to do linear comparisons, to say things like "version > 3.1.0" and not just "version == 3.1.0, 3.1.1, 3.1.2, ...". I would suggest dropping version all together. 2) Assertions. I think that if you're going to do assertions, do them as part of the the initial registration request's authorization (via an OAuth token). That's exactly the kind of thing that the oauth-token functionality was put there for, and we don't need to conflate this with the software identifier. I would suggest not mentioning assertions at all. If you want to tie down things like software_id (or redirect_uri, or anything else), you'll need to specify other things in order to do it in an interoperable way, like how to format or parse the assertion or how to call a discovery service to correlate things. So if this were to go in, I would rather see it like this (Option 4): software_id The value an identifier for the client software being registered. It is RECOMMENDED that clients send this value to help Authorization Servers facilitate client management. The content and structure of this value are out of scope for this specification, and as all Client Metadata is assumed to be self-asserted the Authorization Server MUST NOT make any security decisions based on the value of this field alone. This field MAY be a random value (such as a UUID) self-assigned by the client application developer or it may be supplied by another party. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code.While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change. While I don't think it gives you *real* hooks without specifying ways to verify and validate the value in this field, and I don't think such mechanisms belong in this spec, I don't think that adding this field hurts much. On the same token, I'm not convinced it's worth it, but if Phil, Prateek, and others thing that this would provide enough of a hook for what they want to do without breaking existing extensions and profiles of Dyn Reg (clients don't have to send it, servers can ignore it) that we could actually unstick this issue and move things forward. I think that the *real* work is still ahead of us with regard to instance management, as I think there's a lot more to this particular nut to be cracked that can be solved better in its own specification. -- Justin On 05/22/2013 03:59 PM, Phil Hunt wrote: > I had a conversation with Justin yesterday to try to come to a > resolution regarding my concerns about client instances and being able > to associate client instances that are issued for the same client > software. I think we made some progress. > > */Background: /* > In RFC6749, public clients, had a common client_id. Many interpreted > client_id as refering to the client application software (e.g. the > iPhone Facebook app). This is probably due to the types of OAuth2 > implementations that existed at the time, where there was a single SP > instance. Others have interpreted that client_id does not refer to > client applications but rather ideally should point to instances of > software. To me this seems like equating a client_id to being a > user-id -- IOW the key part of a credential rather than a client > identifier. > > The new draft proposes that each instance be identified separately. > However it does so without keeping track of client software that is > the same. > > Never-the-less, I think both interpretations can be accommodated. > > Finally, in single instance services (like Facebook, Twitter, etc), > there was a natural registration and approval cycle bound into the > client_id issuance process. The developer was able to talk to the > single service provider and obtain a client_id for all deployments. It > wasn't stated, but the client_id registration sites served a useful > way to do application approvals. This is a difficult problem to solve > when there are multiple instance of Resource API deployed in multiple > locations. The developer can't contact them all. Further, because the > current draft loses knowledge of how to recognize that two instances > of clients share the same software, there's no ability to have an > approval process. Each instance is essentially anonymous, and thus > approval processes would not be possible. Though it does not require > it, this proposal makes it possible for service providers to recognize > new software and to have approval process. > > */Proposal:/* > What I have worked out with Justin (and he may not yet fully agree > with everything) is a proposal that solves the problem in an optional > way that will not break existing clients. > > I also propose that optional version numbers also be supported. This > is useful to service providers who need to know which client_ids are > affected when certain software clients and/or versions are deprecated. > The re-introduction of the renamed software_id further enables "local" > registration to occur. The first time a client tries to register, a > service provider could for example, choose to hold the registration to > obtain administrative approval. > > The solution here is not intended to provide software "authentication" > or software verification. The solution simply allows service providers > to make pragmatic decisions about sets of clients that typically work > the same way in a change managed environment. > > Question: What happens if the server does not support these new > parameters and the client provides them? The current draft already > covers this in Section 3. Specifically: >> The Client Registration Endpoint MUST ignore all parameters it does >> not understand. > > Below are 3 options for the group to consider. My recommendation is > for option 1. My concern is option 2 will lead to complexity because > clients and service providers will attempt to encode versions and > software identifiers into one field. I would rather keep this to > simple UUIDs for most cases. > > *Option 1 (2 parameters):* > > software_id > This value MAY be required by registration endpoints. The value MAY be > a unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same > across all instances of a client on an application platform. For > example, software used in a mobile phone should be considered as > different from a web server implementation though it may share the > same code.The identifier *SHOULD NOT *change between software > updates. While a client application MAY be issued multiple client_id's > and client credentials over its deployment lifecycle, the software_id > SHOULD NOT change. > > Signed assertions MAY be used as software identifiers to allow > different dynamic registration end-points to recognize approval from a > common issuer (for example in cases where the resource API released by > a single publisher but deployed in many different domains). The > decision to use assertions and the method by which developers know how > to obtain assertions is out of scope for this specification. > > [editorial note: some current deployments are using temporary client > credential assertions for this purpose. I propose to standardize this > in this field since an assertion would server the same purpose as a > UUID only providing third party signing and other claims. I am > concerned that passing a client assertion for this purpose creates > complexity in client authentication processing - though obviously > Justin has it working] > > software_version > RECOMMENDED. A version indicates a client developer chosen version > number. The identifier SHOULD BE the same across all copies of client > software. The version number SHOULD change between different client > updates. The intention is that Service Providers MAY perform equality > matching with software_id to sub-select groups of clients of a > particular software version. > > *Option 2 (single parameter):* > > software_id > This value MAY be required by registration endpoints. The value MAY be > a unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same > across all instances of a client on an application platform. For > example, software used in a mobile phone should be considered as > different from a web server implementation though it may share the > same code. The identifier *SHOULD* change when the client software has > changed such as with a version update or a platform change. > > Signed assertions MAY be used as software identifiers to allow > different dynamic registration end-points to recognize approval from a > common issuer (for example in cases where the resource API released by > a single publisher but deployed in many different domains). The > decision to use assertions and the method by which developers know how > to obtain assertions is out of scope for this specification. > > [note: same editorial note as option 1] > > *Option 3 (no change):* > > In this option, no changes to the draft are made. > > Personal comment: It has been proposed by several on the list that > another extension draft be written for these features as an extension > to the dynamic registration draft. In my opinion, such a draft would > be very small in size without clear reason for separation. My feeling > is that some technical justification for keeping these features > separated will likely be needed. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000008080302020300010707 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit There are two main things that I dislike about this proposal, but neither are insurmountable in my view.

1) Version. I think that the entire notion of "version" is as slippery a slope as "software identifier" is in the first place. And as soon as you start talking about "version" people are going to want to do linear comparisons, to say things like "version > 3.1.0" and not just "version == 3.1.0, 3.1.1, 3.1.2, ...". I would suggest dropping version all together.

2) Assertions. I think that if you're going to do assertions, do them as part of the the initial registration request's authorization (via an OAuth token). That's exactly the kind of thing that the oauth-token functionality was put there for, and we don't need to conflate this with the software identifier. I would suggest not mentioning assertions at all. If you want to tie down things like software_id (or redirect_uri, or anything else), you'll need to specify other things in order to do it in an interoperable way, like how to format or parse the assertion or how to call a discovery service to correlate things.

So if this were to go in, I would rather see it like this (Option 4):

software_id
The value an identifier for the client software being registered. It is RECOMMENDED that clients send this value to help Authorization Servers facilitate client management. The content and structure of this value are out of scope for this specification, and as all Client Metadata is assumed to be self-asserted the Authorization Server MUST NOT make any security decisions based on the value of this field alone. This field MAY be a random value (such as a UUID) self-assigned by the client application developer or it may be supplied by another party. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.


While I don't think it gives you *real* hooks without specifying ways to verify and validate the value in this field, and I don't think such mechanisms belong in this spec, I don't think that adding this field hurts much.

On the same token, I'm not convinced it's worth it, but if Phil, Prateek, and others thing that this would provide enough of a hook for what they want to do without breaking existing extensions and profiles of Dyn Reg (clients don't have to send it, servers can ignore it) that we could actually unstick this issue and move things forward.

I think that the *real* work is still ahead of us with regard to instance management, as I think there's a lot more to this particular nut to be cracked that can be solved better in its own specification.

 -- Justin

On 05/22/2013 03:59 PM, Phil Hunt wrote:
I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

Background:  
In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance.  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

Never-the-less, I think both interpretations can be accommodated.

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

Proposal:
What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients. 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

Question:  What happens if the server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3.  Specifically:
 The Client Registration Endpoint MUST ignore all parameters it does not understand.

Below are 3 options for the group to consider.  My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

Option 1 (2 parameters):

software_id
This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change between software updates. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

software_version
RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

Option 2 (single parameter):

software_id
This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when the client software has changed such as with a version update or a platform change.
Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[note: same editorial note as option 1]

Option 3 (no change):

In this option, no changes to the draft are made. 

Personal comment:  It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.




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

--------------000008080302020300010707-- From jricher@mitre.org Wed May 22 15:47:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8844F21F90D2 for ; Wed, 22 May 2013 15:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHToBCfrw9su for ; Wed, 22 May 2013 15:47:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 17D9221F90EE for ; Wed, 22 May 2013 15:47:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6D7962290011; Wed, 22 May 2013 18:47:39 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4B7271F026D; Wed, 22 May 2013 18:47:39 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 18:47:39 -0400 Message-ID: <519D4AEC.9040303@mitre.org> Date: Wed, 22 May 2013 18:47:08 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> In-Reply-To: <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> Content-Type: multipart/alternative; boundary="------------030305070107000506020108" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:47:45 -0000 --------------030305070107000506020108 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I agree with Prateek that redirect_uri isn't sufficient or well-suited for this, but I also agree with John that software_id on its own doesn't buy you a whole lot as a standalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is then: is it really worth it to define a field now when the real work will come later? Why not just define the field then and make it fit better? -- Justin On 05/22/2013 06:19 PM, Phil Hunt wrote: > I dont see a big issue with a faked software_id. As i said it was a > minimal proposal with the door open to stronger assertions. > > Rogue clients pretending to be something they are not is actually more > evidence of a problem. In draft 10 you cant even do that. > > Phil > > On 2013-05-22, at 15:15, John Bradley > wrote: > >> At the moment for Mobile devices and other native apps all we have to >> reliably identify the app is the redirect_uri. >> >> The client_id is trivially faked in native apps. >> >> Yes in a well groomed enterprise trusting a self asserted software >> identifier is nice but probably doesn't scale to the real world. >> >> I have had discussions with MDM venders about how you might be able >> to tie access tokens to a instance of software on a device and >> determine if that software is allowed to be run by that user on that >> device. >> These are all much more complicated discussions than just sticking >> another registration parameter on. >> >> I don't think this should block the basic dynamic registration spec. >> App lifecycle needs a full spec, and additional registration >> parameters can be added later if required. >> >> I am not insensitive to the problem. >> >> John B. >> On 2013-05-22, at 6:00 PM, prateek mishra > > wrote: >> >>> Well, I have to say that if anything seems poorly thought out, it >>> would be a design with the following characteristics. >>> >>> [quote] >>> We already have a "software_id" field and it's named "redirect_uris" >>> [\quote] >>> >>> This seems to violate the most basic principles of software design - >>> overloading a field with meaning distinct from its primary purpose!! >>> >>> Phil has raised some substantive questions regarding client >>> meta-data and the registration process. This information >>> (software_id) is >>> essential for identifying and disabling a class of clients that may >>> have been found to have some security flaws, for example. >>> This is a practical deployment issue that also impacts the security >>> characteristics of OAuth. It should be taken into account in the >>> client registration process. >>> >>> I hope we will take the time to discuss this issue carefully and not >>> rush to finalize a specification which has NOT received much review >>> from the OAuth community. >>> >>> - prateek >>> >>> >>> >>>> +1 >>>> >>>> We already have a "software_id" field and it's named "redirect_uris". >>>> >>>> This doesn't seem well thought-out. We shouldn't try to jam it >>>> into the spec at the last minute. >>>> >>>> The good news is that since the registration spec allows for >>>> extensions, and the proposed fields are optional, these could be >>>> added later as a non-breaking change by another spec if the working >>>> group eventually decides to pursue a route like the one proposed >>>> below. We don't have to do it now for this to eventually come into >>>> being after deliberate consideration of a complete specification >>>> including these features by the working group. >>>> >>>> -- Mike >>>> >>>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >>>> Behalf Of *John Bradley >>>> *Sent:* Wednesday, May 22, 2013 2:21 PM >>>> *To:* Phil Hunt >>>> *Cc:* oauth@ietf.org WG >>>> *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix >>>> to client_id definition issue (was: Client Instances) >>>> >>>> Phil, >>>> >>>> As I pointed out in the other thread, redirect_uri is the thing >>>> that ties together the clients as that is the place the responses >>>> need to go to so is hard to fake. >>>> >>>> All instances of a particular client application will share the >>>> same redirect_uri across all instances. >>>> >>>> Adding a bunch of self asserted informational fields to the base >>>> spec is not really helping. In a enterprise situation where all >>>> the apps play nice it might be helpfull but the reality is that you >>>> probably allready have a MDM that lets you manage app versions. >>>> >>>> John >>>> >>>> On 2013-05-22, at 3:59 PM, Phil Hunt >>> > wrote: >>>> >>>> >>>> >>>> I had a conversation with Justin yesterday to try to come to a >>>> resolution regarding my concerns about client instances and being >>>> able to associate client instances that are issued for the same >>>> client software. I think we made some progress. >>>> >>>> */Background: /* >>>> >>>> In RFC6749, public clients, had a common client_id. Many >>>> interpreted client_id as refering to the client application >>>> software (e.g. the iPhone Facebook app). This is probably due to >>>> the types of OAuth2 implementations that existed at the time, where >>>> there was a single SP instance. Others have interpreted that >>>> client_id does not refer to client applications but rather ideally >>>> should point to instances of software. To me this seems like >>>> equating a client_id to being a user-id -- IOW the key part of a >>>> credential rather than a client identifier. >>>> >>>> The new draft proposes that each instance be identified separately. >>>> However it does so without keeping track of client software that is >>>> the same. >>>> >>>> Never-the-less, I think both interpretations can be accommodated. >>>> >>>> Finally, in single instance services (like Facebook, Twitter, etc), >>>> there was a natural registration and approval cycle bound into the >>>> client_id issuance process. The developer was able to talk to the >>>> single service provider and obtain a client_id for all deployments. >>>> It wasn't stated, but the client_id registration sites served a >>>> useful way to do application approvals. This is a difficult >>>> problem to solve when there are multiple instance of Resource API >>>> deployed in multiple locations. The developer can't contact them >>>> all. Further, because the current draft loses knowledge of how to >>>> recognize that two instances of clients share the same software, >>>> there's no ability to have an approval process. Each instance is >>>> essentially anonymous, and thus approval processes would not be >>>> possible. Though it does not require it, this proposal makes it >>>> possible for service providers to recognize new software and to >>>> have approval process. >>>> >>>> */Proposal:/* >>>> >>>> What I have worked out with Justin (and he may not yet fully agree >>>> with everything) is a proposal that solves the problem in an >>>> optional way that will not break existing clients. >>>> >>>> I also propose that optional version numbers also be supported. >>>> This is useful to service providers who need to know which >>>> client_ids are affected when certain software clients and/or >>>> versions are deprecated. The re-introduction of the renamed >>>> software_id further enables "local" registration to occur. The >>>> first time a client tries to register, a service provider could for >>>> example, choose to hold the registration to obtain administrative >>>> approval. >>>> >>>> The solution here is not intended to provide software >>>> "authentication" or software verification. The solution simply >>>> allows service providers to make pragmatic decisions about sets of >>>> clients that typically work the same way in a change managed >>>> environment. >>>> >>>> Question: What happens if the server does not support these new >>>> parameters and the client provides them? The current draft already >>>> covers this in Section 3. Specifically: >>>> >>>> The Client Registration Endpoint MUST ignore all parameters it does not understand. >>>> >>>> Below are 3 options for the group to consider. My recommendation >>>> is for option 1. My concern is option 2 will lead to complexity >>>> because clients and service providers will attempt to encode >>>> versions and software identifiers into one field. I would rather >>>> keep this to simple UUIDs for most cases. >>>> >>>> *Option 1 (2 parameters):* >>>> >>>> software_id >>>> >>>> This value MAY be required by registration endpoints. The value MAY >>>> be a unique identifier (UUID) self-assigned by a the client >>>> application developer, or it MAY be an assertion. The value SHOULD >>>> be the same across all instances of a client on an application >>>> platform. For example, software used in a mobile phone should be >>>> considered as different from a web server implementation though it >>>> may share the same code.The identifier *SHOULD NOT *change between >>>> software updates. While a client application MAY be issued multiple >>>> client_id's and client credentials over its deployment lifecycle, >>>> the software_id SHOULD NOT change. >>>> >>>> Signed assertions MAY be used as software identifiers to allow >>>> different dynamic registration end-points to recognize approval >>>> from a common issuer (for example in cases where the resource API >>>> released by a single publisher but deployed in many different >>>> domains). The decision to use assertions and the method by which >>>> developers know how to obtain assertions is out of scope for this >>>> specification. >>>> >>>> [editorial note: some current deployments are using temporary >>>> client credential assertions for this purpose. I propose to >>>> standardize this in this field since an assertion would server the >>>> same purpose as a UUID only providing third party signing and other >>>> claims. I am concerned that passing a client assertion for this >>>> purpose creates complexity in client authentication processing - >>>> though obviously Justin has it working] >>>> >>>> software_version >>>> >>>> RECOMMENDED. A version indicates a client developer chosen version >>>> number. The identifier SHOULD BE the same across all copies of >>>> client software. The version number SHOULD change between different >>>> client updates. The intention is that Service Providers MAY perform >>>> equality matching with software_id to sub-select groups of clients >>>> of a particular software version. >>>> >>>> *Option 2 (single parameter):* >>>> >>>> software_id >>>> >>>> This value MAY be required by registration endpoints. The value MAY >>>> be a unique identifier (UUID) self-assigned by a the client >>>> application developer, or it MAY be an assertion. The value SHOULD >>>> be the same across all instances of a client on an application >>>> platform. For example, software used in a mobile phone should be >>>> considered as different from a web server implementation though it >>>> may share the same code. The identifier *SHOULD* change when the >>>> client software has changed such as with a version update or a >>>> platform change. >>>> >>>> Signed assertions MAY be used as software identifiers to allow >>>> different dynamic registration end-points to recognize approval >>>> from a common issuer (for example in cases where the resource API >>>> released by a single publisher but deployed in many different >>>> domains). The decision to use assertions and the method by which >>>> developers know how to obtain assertions is out of scope for this >>>> specification. >>>> >>>> [note: same editorial note as option 1] >>>> >>>> *Option 3 (no change):* >>>> >>>> In this option, no changes to the draft are made. >>>> >>>> Personal comment: It has been proposed by several on the list that >>>> another extension draft be written for these features as an >>>> extension to the dynamic registration draft. In my opinion, such a >>>> draft would be very small in size without clear reason for >>>> separation. My feeling is that some technical justification for >>>> keeping these features separated will likely be needed. >>>> >>>> Phil >>>> >>>> @independentid >>>> >>>> www.independentid.com >>>> >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030305070107000506020108 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I agree with Prateek that redirect_uri isn't sufficient or well-suited for this, but I also agree with John that software_id on its own doesn't buy you a whole lot as a standalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is then: is it really worth it to define a field now when the real work will come later? Why not just define the field then and make it fit better?

 -- Justin

On 05/22/2013 06:19 PM, Phil Hunt wrote:
I dont see a big issue with a faked software_id. As i said it was a minimal proposal with the door open to stronger assertions. 

Rogue clients pretending to be something they are not is actually more evidence of a problem. In draft 10 you cant even do that. 

Phil

On 2013-05-22, at 15:15, John Bradley <ve7jtb@ve7jtb.com> wrote:

At the moment for Mobile devices and other native apps all we have to reliably identify the app is the redirect_uri.  

The client_id is trivially faked in native apps. 

Yes in a well groomed enterprise trusting a self asserted software identifier is nice but probably doesn't scale to the real world.

I have had discussions with MDM venders about how you might be able to tie access tokens to a instance of software on a device and determine if that software is allowed to be run by that user on that device.
These are all much more complicated discussions than just sticking another registration parameter on.

I don't think this should block the basic dynamic registration spec.   App lifecycle needs a full spec, and additional registration parameters can be added later if required.

I am not insensitive to the problem.

John B.
On 2013-05-22, at 6:00 PM, prateek mishra <prateek.mishra@oracle.com> wrote:

Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a “software_id” field and it’s named “redirect_uris”
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth.  It should be taken into account in the client registration process.

I hope we will take the time to discuss this issue carefully and not rush  to finalize a specification which has NOT received much review
from the OAuth community.

- prateek



+1

 

We already have a “software_id” field and it’s named “redirect_uris”.

 

This doesn’t seem well thought-out.  We shouldn’t try to jam it into the spec at the last minute.

 

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.  We don’t have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

 

                                                                -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other thread,  redirect_uri is the thing that ties together the clients as that is the place the responses need to go to so is hard to fake.

 

All instances of a particular client application will share the same redirect_uri across all instances.   

 

Adding a bunch of self asserted informational fields to the base spec is not really helping.  In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

 

Background:  

In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance.  Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

 

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

 

Never-the-less, I think both interpretations can be accommodated.

 

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals.  This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all.  Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible.  Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

 

Proposal:

What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients. 

 

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

 

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment. 

 

Question:  What happens if the server does not support these new parameters and the client provides them?  The current draft already covers this in Section 3.  Specifically:

 The Client Registration Endpoint MUST ignore all parameters it does not understand.

 

Below are 3 options for the group to consider.  My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

 

Option 1 (2 parameters):

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD NOT change between software updates. While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

 

software_version

RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

 

Option 2 (single parameter):

 

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier SHOULD change when the client software has changed such as with a version update or a platform change.

 

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

 

[note: same editorial note as option 1]

 

Option 3 (no change):

 

In this option, no changes to the draft are made. 

 

Personal comment:  It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

 

 



 

_______________________________________________
OAuth mailing 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

--------------030305070107000506020108-- From tonynad@microsoft.com Wed May 22 15:49:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2111E8153 for ; Wed, 22 May 2013 15:49:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM4T6c+CzfZN for ; Wed, 22 May 2013 15:49:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9E11E815B for ; Wed, 22 May 2013 15:49:35 -0700 (PDT) Received: from BL2FFO11FD018.protection.gbl (10.173.161.201) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 22:49:33 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 22:49:33 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 22 May 2013 22:49:17 +0000 Received: from mail8-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 22:48:09 +0000 Received: from mail8-tx2 (localhost [127.0.0.1]) by mail8-tx2-R.bigfish.com (Postfix) with ESMTP id 73FDD1C027C for ; Wed, 22 May 2013 22:48:09 +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: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh936eI1e83Mc857hdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail8-tx2: 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:BY2PR03MB041; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail8-tx2 (localhost.localdomain [127.0.0.1]) by mail8-tx2 (MessageSwitch) id 136926288744974_12920; Wed, 22 May 2013 22:48:07 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.247]) by mail8-tx2.bigfish.com (Postfix) with ESMTP id F07F040010D; Wed, 22 May 2013 22:48:06 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 22:48:06 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 22 May 2013 22:48:04 +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.698.13; Wed, 22 May 2013 22:48:02 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) with mapi id 15.00.0698.010; Wed, 22 May 2013 22:48:02 +0000 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVWw2HOVR1MGBX02Be07cmNz/cpkOMHcAgAAH54CAAA6lAIAAGIDAgAAAQ4CAAytGAIAAIbEAgAALjfCAABDGgIAACMHw Date: Wed, 22 May 2013 22:48:01 +0000 Message-ID: References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <519D2BE4.6080303@mitre.org> <8ae4313deafe4397b0b312ef38dcf182@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_be7043660ea2476ab64b7e42895c8793BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB041.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%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454002)(189002)(479174002)(377454002)(377424003)(78114002)(199002)(76482001)(512874002)(47976001)(54316002)(46102001)(71186001)(81342001)(56816002)(56776001)(81542001)(77982001)(74366001)(59766001)(31966008)(49866001)(74502001)(47736001)(47446002)(79102001)(54356001)(74662001)(50986001)(4396001)(16236675002)(74876001)(69226001)(74706001)(74316001)(15202345002)(44976003)(16676001)(561944002)(66066001)(63696002)(20776003)(80022001)(33646001)(53806001)(6806003)(65816001)(51856001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB013; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:49:42 -0000 --_000_be7043660ea2476ab64b7e42895c8793BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgbWlzdGFrZSwgd2FzIHRvIHNheSwgV2UgYWxyZWFkeSBoYXZlIE9wZW5JRCBDb25uZWN0IGRv aW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYSBuZWVk IHRvIGZvcmNlIGl0IGludG8gT0F1dGguDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMzoxNiBQTQ0K VG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IEp1c3RpbiBSaWNoZXI7IG9hdXRoQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWlj IFJlZ2lzdHJhdGlvbg0KDQpJJ20gaGF2aW5nIHRyb3VibGUgdW5kZXJzdGFuZGluZw0KV2UgYWxy ZWFkeSBoYXZlIE9BdXRoIGRvaW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uLCBJIGRvbuKAmXQgdGhp bmsgdGhlcmUgaXMgYSBuZWVkIHRvIGZvcmNlIGl0IGludG8gT0F1dGguDQoNCg0KSSB3b3VsZCBi ZSBvcGVuIHRvIGEgc2NpbSBkeW4gcmVnIHZlcnNpb24uIFBhcnRpY3VsYXJseSB0byBkaXNjdXNz IGluc3RhbmNlIG1ldGFkYXRhIG1ndCB3aGljaCBzY2ltIGlzIGdvb2QgYXQgYW5kIHRoZSBjcmVk ZW50aWFsIG1hbmFnZW1lbnIvYm9vdHN0cmFwIHByb2Nlc3MgYXMgaXQgcGVydGFpbnMgdG8gb2F1 dGguICBOZXZlci10aGUtbGVzcyB0aGUgb3ZlcndoZWxtaW5nIHByaW9yaXR5IGhhcyBiZWVuIGFw cGFyZW50bHkgdG8gc2ltcGx5IHN0YW5kYXJkaXplIG9pZGMgYW5kIHVtYSBpbXBsZW1lbnRhdGlv bnMgYXMgaXMuIFRoaXMgSSBhbSBub3QgY29tZm9ydGFibGUgd2l0aCBidXQgaSBjYW4gbGl2ZSB3 aXRoIGlmIHRoZXJlIGlzIGdpdmUgYW5kIHRha2UuDQoNCkkgZmVlbCB0aGUgc3ViamVjdCBpcyB3 ZWxsIGluIGNoYXJ0ZXIgYW5kIGlzIGFuIGltcG9ydGFudCBpc3N1ZSBkdWUgdG8gdGhlIGxpZmUt Y3ljbGUgbWFuYWdlbWVudCBpc3N1ZXMgYmVoaW5kIGNsaWVudHMgYW5kIHRoZSBuZWVkIHRvIG1h a2UgcHVibGljIGNsaWVudHMgdGhlIHNlY3VyaXR5IGVxdWl2LiBvZiBjb25maWRlbnRpYWwgY2xp ZW50cy4NCg0KUGhpbA0KDQpPbiAyMDEzLTA1LTIyLCBhdCAxNDoyMiwgQW50aG9ueSBOYWRhbGlu IDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KSSB0b3RhbGx5IGRpc2FncmVlIHdpdGggeW91ciBjaGFyYWN0ZXJpemF0aW9uIG9mIFND SU0sIHdoaWxlIGl0IGNhbiBiZSB1c2VkIGZyb20gc2VydmVyIHRvIHNlcnZlciAocHJvdmlzaW9u IG9uZSBzeXN0ZW0gdG8gYW5vdGhlcikgaXQgY2FuIGFsc28gYmUgY2xpZW50IHRvIGVuZHBvaW50 IChpbml0aWFsIHByb3Zpc2lvbmluZyBhbmQgSklUIHByb3Zpc2lvbmluZykuIFNDSU0gaXMgZmFp cmx5IHNpbXBsZSAoYnV0IGNhbiBiZSBjb21wbGV4KSwgSSBhbHNvIGhhdmUgY29uY2VybnMgYWJv dXQgU0NJTSBub3QgYmVpbmcgMTAwJSByZXN0ZnVsIGJ1dCB0aGF0IGRvZXMgbm90IHN0b3AgdXMg ZnJvbSB1c2luZyBpdC4gSSBhbHNvIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGxldCBPQXV0aCBkbyB3 aGF0IGl04oCZcyBnb29kIGF0IGFuZCBkb27igJl0IHRyeSB0byBmb3JjZSBpdCBpbnRvIHNvbWV0 aGluZyB0aGF0IGl04oCZcyBub3QuIFdlIGFscmVhZHkgaGF2ZSBPQXV0aCBkb2luZyBkeW5hbWlj IHJlZ2lzdHJhdGlvbiwgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEgbmVlZCB0byBmb3JjZSBp dCBpbnRvIE9BdXRoLg0KDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1p dHJlLm9yZ10NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDIyLCAyMDEzIDE6MzUgUE0NClRvOiBBbnRo b255IE5hZGFsaW4NCkNjOiBQaGlsIEh1bnQ7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2Vz IGluIER5bmFtaWMgUmVnaXN0cmF0aW9uDQoNCkknbSBub3Qgc3VyZSB3aHkgeW91IGRvbid0IHRo aW5rIGl0J3MgaW4gc2NvcGUsIGl0J3MgaW4gdGhlIHdvcmtpbmcgZ3JvdXAncyBjaGFydGVyOg0K DQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvZHluL3dnL2NoYXJ0ZXIvb2F1dGgtY2hhcnRlci5odG1s DQoNClNvIC4uLiBpdCdzIGRlZmluaXRlbHkgaW4gc2NvcGUsIGFuZCBoYXMgYmVlbiBmb3Igb3Zl ciBhIHllYXIgYW5kIGEgaGFsZi4gVGhpcyBpcyB0aGUgdGVudGggdmVyc2lvbiBvZiB0aGlzIGRv Y3VtZW50LS0gYW4gSUVURiBXb3JraW5nIEdyb3VwIGRvY3VtZW50IGF0IHRoYXQtLSB0aGF0J3Mg YmVlbiBwb3N0ZWQgdG8gdGhlIGdyb3VwIHdpdGggZXZlcnkgcmV2aXNpb24gYW5kIHRoZXJlIGhh cyBiZWVuIHNpZ25pZmljYW50IGNvbnZlcnNhdGlvbiBhcm91bmQgaXQsIGVzcGVjaWFsbHkgb3Zl ciB0aGUgbGFzdCBzaXggbW9udGhzIHNpbmNlIEkgdG9vayBvdmVyIHRoZSBlZGl0b3Igcm9sZS4g VGhlcmUgYXJlIGFsc28gYSBoYW5kZnVsIG9mIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzLCBhbmQg d2hpbGUgbW9zdCBvZiB0aGVtIGFyZSBidWlsdCB0byBkbyBPcGVuSUQgQ29ubmVjdCBvciBVTUEg KHdoaWNoIGFyZSBkaXJlY3RseSBidWlsdCBvbiBPQXV0aCksIEkga25vdyB0aGVyZSBhcmUgc29t ZSB0aGF0IGFsc28gZG8gcGxhaW4gT0F1dGguIChOb3QgdGhlIGxlYXN0IG9mIHdoaWNoIGlzIG9u ZSB0aGF0IEkgaGF2ZSBwZXJzb25hbGx5IGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4pDQoNClND SU0gZG9lc24ndCBzb2x2ZSBjbGllbnQgbWFuYWdlbWVudCBwYXJ0aWN1bGFybHkgd2VsbCwgc2lu Y2UgaXQncyBtYWRlIGZvciB1c2VycyBtb3JlIHRoYW4gYW55dGhpbmcuIFRoZSB1c2FnZSBtb2Rl bCBvZiBTQ0lNIGlzIGFsc28gcXVpdGUgZGlmZmVyZW50IC0tIGl0J3MgcmVhbGx5IGludGVuZGVk IHRvIGJlIHVzZWQgYmV0d2VlbiB0d28gc2VydmVycyB0byB0cmFuc2ZlciBpbmZvcm1hdGlvbiwg YXMgb3Bwb3NlZCB0byBoYW5kbGluZyBzZWxmLWFzc2VydGVkIGNsYWltcy4gSSB1bmRlcnN0YW5k IHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgbGlrZSBVQUEgaGF2ZSBkb25lIHRoZWlyIHN0YXRp YyByZWdpc3RyYXRpb24gdXNpbmcgYSBTQ0lNIHByb2ZpbGUsIGJ1dCBpdCdzIG5vdCBkeW5hbWlj IHJlZ2lzdHJhdGlvbiwgcmVhbGx5LiBJIHRoaW5rIGl0J3MgdG9vIG11Y2ggb2YgYSBzcXVhcmUt cGVnLXJvdW5kLWhvbGUgcHJvYmxlbSwgYXQgbGVhc3Qgd2l0aCBTQ0lNIGFzIGl0IGlzIHRvZGF5 OyBzbyBsZXQgU0NJTSBkbyB3aGF0IGl0J3MgZ29vZCBhdCwgYW5kIGRvbid0IHRyeSB0byBmb3Jj ZSBpdCBpbnRvIHNvbWV0aGluZyBpdCdzIG5vdC4NCg0KRnVydGhlcm1vcmUsIGJlIGNhcmVmdWwg bm90IHRvIGNvbmZsYXRlIFNDSU0gd2l0aCBSRVNULiBVbHRpbWF0ZWx5LCBEeW5hbWljIFJlZ2lz dHJhdGlvbiB3YXMgbWVhbnQgdG8gYmUgYSBmYWlybHkgc2ltcGxlIFJFU1QvSlNPTiBBUEkgdGhh dCB3b3VsZCBiZSBlYXN5IHRvIGltcGxlbWVudCwgZXNwZWNpYWxseSBmb3IgY2xpZW50cy4gSnVz dCBiZWNhdXNlIFNDSU0gaXMgUkVTVGZ1bCBkb2Vzbid0IG1lYW4gaXQncyBhIGdvb2Qgc3RydWN0 dXJlIGZvciBvdGhlciBSRVNUZnVsIEFQSXMuIE5hbWVseSwgSSBkb24ndCB0aGluayB0aGUgZXh0 cmEgc3RydWN0dXJlIGFuZCBob29rcyB3aXRoIFNDSU0gcmVhbGx5IGJ1eSB5b3UgYW55dGhpbmcg aGVyZSwgZXNwZWNpYWxseSB3aXRoIHRoZSBhZGRpdGlvbnMgYW5kIGNoYW5nZXMgeW91J2QgaGF2 ZSB0byBtYWtlIHRvIFNDSU0uDQoNCkFuZCBmaW5hbGx5LCBub2JvZHkgdG8gZGF0ZSBoYXMgYWN0 dWFsbHkgd3JpdHRlbiBhIHByb3Bvc2FsIHRoYXQgaXMgZXZlbiByZW1vdGVseSBTQ0lNIGJhc2Vk Lg0KDQogLS0gSnVzdGluDQpPbiAwNS8yMi8yMDEzIDAyOjM5IFBNLCBBbnRob255IE5hZGFsaW4g d3JvdGU6DQpTbywgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBkeW5hbWljIHJlZ2lz dHJhdGlvbiBpcyBpbiBzY29wZSwgSSB1bmRlcnN0YW5kIHRoaXMgcmVsYXRpdmUgdG8gT3BlbklE IENvbm5lY3QgYnV0IG5vdCBPQXV0aCwgaWYgdGhpcyBpcyBpbmRlZWQgaW4gc2NvcGUgdGhlbiBJ IHdvdWxkIGhhdmUgZXhwZWN0ZWQgdGhhdCB0aGUgZW5kcG9pbnQgYmUgYmFzZWQgdXBvbiBTQ0lN IGFuZCBub3Qgc29tZXRoaW5nIGVsc2UgbGlrZSB3aGF0IGhhcyBiZWVuIGRvbmUgaGVyZS4NCg0K RnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KU2VudDogTW9u ZGF5LCBNYXkgMjAsIDIwMTMgMTE6MTAgQU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBQaGls IEh1bnQ7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFByb3Bvc2VkIFN5bnRheCBDaGFuZ2VzIGluIER5bmFtaWMgUmVnaXN0cmF0 aW9uDQoNClRvbnksIGNhbiB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gV2hhdCBuZWVkcyB0byBiZSBj aGFuZ2VkIGluIHlvdXIgb3Bpbmlvbj8gV2hhdCB0ZXh0IGNoYW5nZXMgd291bGQgeW91IHN1Z2dl c3Q/DQoNCiAtLSBKdXN0aW4NCk9uIDA1LzIwLzIwMTMgMDI6MDkgUE0sIEFudGhvbnkgTmFkYWxp biB3cm90ZToNCkFncmVlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogTW9uZGF5LCBNYXkgMjAsIDIwMTMgOTo0MiBBTQ0K VG86IEp1c3RpbiBSaWNoZXINCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBE eW5hbWljIFJlZ2lzdHJhdGlvbg0KDQpUaGlzIGRyYWZ0IGlzbid0IHJlYWR5IGZvciBMQy4NCg0K UGhpbA0KDQpPbiAyMDEzLTA1LTIwLCBhdCA4OjQ5LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCkJ1dCBhbHNvIGtlZXAg aW4gbWluZCB0aGF0IHRoaXMgaXMgbGFzdC1jYWxsLCBhbmQgdGhhdCB3ZSBkb24ndCByZWFsbHkg d2FudCB0byBlbmNvdXJhZ2UgYXZvaWRhYmxlIGRyYXN0aWMgY2hhbmdlcyBhdCB0aGlzIHN0YWdl Lg0KDQogLS0gSnVzdGluDQoNCg0KDQoNCk9uIDA1LzIwLzIwMTMgMTE6MjEgQU0sIFBoaWwgSHVu dCB3cm90ZToNCktlZXAgaW4gbWluZCB0aGVyZSBtYXkgYmUgb3RoZXIgY2hhbmdlcyBjb21pbmcu DQoNClRoZSBpc3N1ZSBpcyB0aGF0IG5ldyBkZXZlbG9wZXJzIGNhbid0IGZpZ3VyZSBvdXQgd2hh dCB0b2tlbiBpcyBiZWluZyByZWZlcnJlZCB0by4NCg0KUGhpbA0KDQpPbiAyMDEzLTA1LTIwLCBh dCA4OjA5LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBt aXRyZS5vcmc+PiB3cm90ZToNClBoaWwgSHVudCdzIHJldmlldyBvZiB0aGUgRHluYW1pYyBSZWdp c3RyYXRpb24gc3BlY2lmaWNhdGlvbiBoYXMgcmFpc2VkIGEgY291cGxlIG9mIGlzc3VlcyB0aGF0 IEkgZmVsdCB3ZXJlIGdldHRpbmcgYnVyaWVkIGJ5IHRoZSBsYXJnZXIgZGlzY3Vzc2lvbiAod2hp Y2ggSSBzdGlsbCBzdHJvbmdseSBlbmNvdXJhZ2Ugb3RoZXJzIHRvIGp1bXAgaW4gdG8pLiBOYW1l bHksIFBoaWwgaGFzIHN1Z2dlc3RlZCBhIGNvdXBsZSBvZiBzeW50YXggY2hhbmdlcyB0byB0aGUg bmFtZXMgb2Ygc2V2ZXJhbCBwYXJhbWV0ZXJzLg0KDQoNCjEpIGV4cGlyZXNfYXQgLT4gY2xpZW50 X3NlY3JldF9leHBpcmVzX2F0DQoyKSBpc3N1ZWRfYXQgLT4gY2xpZW50X2lkX2lzc3VlZF9hdA0K MykgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgLT4gdG9rZW5fZW5kcG9pbnRfY2xpZW50X2F1 dGhfbWV0aG9kDQoNCg0KSSdkIGxpa2UgdG8gZ2V0IGEgZmVlbGluZywgZXNwZWNpYWxseSBmcm9t IGRldmVsb3BlcnMgd2hvIGhhdmUgZGVwbG95ZWQgdGhpcyBkcmFmdCBzcGVjLCB3aGF0IHdlIG91 Z2h0IHRvIGRvIGZvciBlYWNoIG9mIHRoZXNlOg0KDQogQSkgS2VlcCB0aGUgcGFyYW1ldGVyIG5h bWVzIGFzLWlzDQogQikgQWRvcHQgdGhlIG5ldyBuYW1lcyBhcyBhYm92ZQ0KIEMpIEFkb3B0IGEg bmV3IG5hbWUgdGhhdCBJIHdpbGwgc3BlY2lmeQ0KDQpJbiBhbGwgY2FzZXMsIGNsYXJpZnlpbmcg dGV4dCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBwYXJhbWV0ZXIgKmRlZmluaXRpb25zKiBzbyB0aGF0 IGl0J3MgbW9yZSBjbGVhciB0byBwZW9wbGUgcmVhZGluZyB0aGUgc3BlYyB3aGF0IGVhY2ggcGll Y2UgZG9lcy4gU3BlYWtpbmcgYXMgdGhlIGVkaXRvcjogIkEiIGlzIHRoZSBkZWZhdWx0IGFzIGZh ciBhcyBJJ20gY29uY2VybmVkLCBzaW5jZSB3ZSBzaG91bGRuJ3QgY2hhbmdlIHN5bnRheCB3aXRo b3V0IHZlcnkgZ29vZCByZWFzb24gdG8gZG8gc28uIFRoYXQgc2FpZCwgaWYgaXQncyBnb2luZyB0 byBiZSBiZXR0ZXIgZm9yIGRldmVsb3BlcnMgd2l0aCB0aGUgbmV3IHBhcmFtZXRlciBuYW1lcywg SSBhbSBvcGVuIHRvIGZpeGluZyB0aGVtIG5vdy4NCg0KTmFtaW5nIHRoaW5ncyBpcyBoYXJkLg0K DQogLS0gSnVzdGluDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K DQo= --_000_be7043660ea2476ab64b7e42895c8793BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TXkgbWlzdGFrZSwgd2FzIHRvIHNheSwNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYWxyZWFkeSBoYXZlIE9wZW5JRCBD b25uZWN0IGRvaW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUg aXMgYSBuZWVkIHRvIGZvcmNlIGl0IGludG8gT0F1dGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFBoaWwgSHVudCBbbWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDIy LCAyMDEzIDM6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNj OjwvYj4gSnVzdGluIFJpY2hlcjsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUHJvcG9zZWQgU3ludGF4IENoYW5nZXMgaW4gRHluYW1pYyBSZWdpc3Ry YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSdtIGhhdmluZyB0cm91YmxlIHVuZGVyc3RhbmRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQ7LXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAu Mjk2ODc1KTstd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIy NywgMC4yMzA0NjkpOy13ZWJraXQtY29tcG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEy OCwgMTgwLCAwLjIzMDQ2OSkiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFscmVhZHkgaGF2ZSBPQXV0 aCBkb2luZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiwgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEg bmVlZCB0byBmb3JjZSBpdCBpbnRvDQogT0F1dGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYmUgb3BlbiB0byBhIHNjaW0gZHluIHJl ZyB2ZXJzaW9uLiBQYXJ0aWN1bGFybHkgdG8gZGlzY3VzcyBpbnN0YW5jZSBtZXRhZGF0YSBtZ3Qg d2hpY2ggc2NpbSBpcyBnb29kIGF0IGFuZCB0aGUgY3JlZGVudGlhbCBtYW5hZ2VtZW5yL2Jvb3Rz dHJhcCBwcm9jZXNzIGFzIGl0IHBlcnRhaW5zIHRvIG9hdXRoLiAmbmJzcDtOZXZlci10aGUtbGVz cyB0aGUgb3ZlcndoZWxtaW5nIHByaW9yaXR5IGhhcyBiZWVuIGFwcGFyZW50bHkNCiB0byBzaW1w bHkgc3RhbmRhcmRpemUgb2lkYyBhbmQgdW1hIGltcGxlbWVudGF0aW9ucyBhcyBpcy4gVGhpcyBJ IGFtIG5vdCBjb21mb3J0YWJsZSB3aXRoIGJ1dCBpIGNhbiBsaXZlIHdpdGggaWYgdGhlcmUgaXMg Z2l2ZSBhbmQgdGFrZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBmZWVsIHRoZSBzdWJqZWN0IGlzIHdlbGwgaW4gY2hhcnRlciBh bmQgaXMgYW4gaW1wb3J0YW50IGlzc3VlIGR1ZSB0byB0aGUgbGlmZS1jeWNsZSBtYW5hZ2VtZW50 IGlzc3VlcyBiZWhpbmQgY2xpZW50cyBhbmQgdGhlIG5lZWQgdG8gbWFrZSBwdWJsaWMgY2xpZW50 cyB0aGUgc2VjdXJpdHkgZXF1aXYuIG9mIGNvbmZpZGVudGlhbCBjbGllbnRzLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIwMTMtMDUtMjIsIGF0IDE0OjIyLCBBbnRo b255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRv bnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB0b3RhbGx5IGRpc2FncmVlIHdpdGggeW91ciBjaGFyYWN0ZXJp emF0aW9uIG9mIFNDSU0sIHdoaWxlIGl0IGNhbiBiZSB1c2VkIGZyb20gc2VydmVyIHRvIHNlcnZl ciAocHJvdmlzaW9uIG9uZSBzeXN0ZW0gdG8gYW5vdGhlcikgaXQgY2FuIGFsc28gYmUgY2xpZW50 IHRvDQogZW5kcG9pbnQgKGluaXRpYWwgcHJvdmlzaW9uaW5nIGFuZCBKSVQgcHJvdmlzaW9uaW5n KS4gU0NJTSBpcyBmYWlybHkgc2ltcGxlIChidXQgY2FuIGJlIGNvbXBsZXgpLCBJIGFsc28gaGF2 ZSBjb25jZXJucyBhYm91dCBTQ0lNIG5vdCBiZWluZyAxMDAlIHJlc3RmdWwgYnV0IHRoYXQgZG9l cyBub3Qgc3RvcCB1cyBmcm9tIHVzaW5nIGl0LiBJIGFsc28gYWdyZWUgdGhhdCB3ZSBzaG91bGQg bGV0IE9BdXRoIGRvIHdoYXQgaXTigJlzIGdvb2QgYXQgYW5kDQogZG9u4oCZdCB0cnkgdG8gZm9y Y2UgaXQgaW50byBzb21ldGhpbmcgdGhhdCBpdOKAmXMgbm90LiBXZSBhbHJlYWR5IGhhdmUgT0F1 dGggZG9pbmcgZHluYW1pYyByZWdpc3RyYXRpb24sIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBh IG5lZWQgdG8gZm9yY2UgaXQgaW50byBPQXV0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4gSnVzdGluIFJpY2hlciBbPGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3Jn Ij5tYWlsdG86anJpY2hlckBtaXRyZS5vcmc8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgTWF5IDIyLCAyMDEzIDE6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxp bjxicj4NCjxiPkNjOjwvYj4gUGhpbCBIdW50OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lzdHJhdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSdtIG5vdCBzdXJlIHdoeSB5b3UgZG9uJ3QgdGhpbmsgaXQncyBpbiBzY29w ZSwgaXQncyBpbiB0aGUgd29ya2luZyBncm91cCdzIGNoYXJ0ZXI6PGJyPg0KPGJyPg0KJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvZHluL3dnL2NoYXJ0ZXIvb2F1dGgtY2hhcnRl ci5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL2R5bi93Zy9jaGFydGVyL29hdXRoLWNoYXJ0ZXIu aHRtbDwvYT48YnI+DQo8YnI+DQpTbyAuLi4gaXQncyBkZWZpbml0ZWx5IGluIHNjb3BlLCBhbmQg aGFzIGJlZW4gZm9yIG92ZXIgYSB5ZWFyIGFuZCBhIGhhbGYuIFRoaXMgaXMgdGhlIHRlbnRoIHZl cnNpb24gb2YgdGhpcyBkb2N1bWVudC0tIGFuIElFVEYgV29ya2luZyBHcm91cCBkb2N1bWVudCBh dCB0aGF0LS0gdGhhdCdzIGJlZW4gcG9zdGVkIHRvIHRoZSBncm91cCB3aXRoIGV2ZXJ5IHJldmlz aW9uIGFuZCB0aGVyZSBoYXMgYmVlbiBzaWduaWZpY2FudCBjb252ZXJzYXRpb24gYXJvdW5kDQog aXQsIGVzcGVjaWFsbHkgb3ZlciB0aGUgbGFzdCBzaXggbW9udGhzIHNpbmNlIEkgdG9vayBvdmVy IHRoZSBlZGl0b3Igcm9sZS4gVGhlcmUgYXJlIGFsc28gYSBoYW5kZnVsIG9mIGltcGxlbWVudGF0 aW9ucyBvZiB0aGlzLCBhbmQgd2hpbGUgbW9zdCBvZiB0aGVtIGFyZSBidWlsdCB0byBkbyBPcGVu SUQgQ29ubmVjdCBvciBVTUEgKHdoaWNoIGFyZSBkaXJlY3RseSBidWlsdCBvbiBPQXV0aCksIEkg a25vdyB0aGVyZSBhcmUgc29tZSB0aGF0IGFsc28NCiBkbyBwbGFpbiBPQXV0aC4gKE5vdCB0aGUg bGVhc3Qgb2Ygd2hpY2ggaXMgb25lIHRoYXQgSSBoYXZlIHBlcnNvbmFsbHkgaW1wbGVtZW50ZWQg YW5kIGRlcGxveWVkLik8YnI+DQo8YnI+DQpTQ0lNIGRvZXNuJ3Qgc29sdmUgY2xpZW50IG1hbmFn ZW1lbnQgcGFydGljdWxhcmx5IHdlbGwsIHNpbmNlIGl0J3MgbWFkZSBmb3IgdXNlcnMgbW9yZSB0 aGFuIGFueXRoaW5nLiBUaGUgdXNhZ2UgbW9kZWwgb2YgU0NJTSBpcyBhbHNvIHF1aXRlIGRpZmZl cmVudCAtLSBpdCdzIHJlYWxseSBpbnRlbmRlZCB0byBiZSB1c2VkIGJldHdlZW4gdHdvIHNlcnZl cnMgdG8gdHJhbnNmZXIgaW5mb3JtYXRpb24sIGFzIG9wcG9zZWQgdG8gaGFuZGxpbmcgc2VsZi1h c3NlcnRlZA0KIGNsYWltcy4gSSB1bmRlcnN0YW5kIHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMg bGlrZSBVQUEgaGF2ZSBkb25lIHRoZWlyIHN0YXRpYyByZWdpc3RyYXRpb24gdXNpbmcgYSBTQ0lN IHByb2ZpbGUsIGJ1dCBpdCdzIG5vdCBkeW5hbWljIHJlZ2lzdHJhdGlvbiwgcmVhbGx5LiBJIHRo aW5rIGl0J3MgdG9vIG11Y2ggb2YgYSBzcXVhcmUtcGVnLXJvdW5kLWhvbGUgcHJvYmxlbSwgYXQg bGVhc3Qgd2l0aCBTQ0lNIGFzIGl0IGlzIHRvZGF5OyBzbyBsZXQNCiBTQ0lNIGRvIHdoYXQgaXQn cyBnb29kIGF0LCBhbmQgZG9uJ3QgdHJ5IHRvIGZvcmNlIGl0IGludG8gc29tZXRoaW5nIGl0J3Mg bm90Ljxicj4NCjxicj4NCkZ1cnRoZXJtb3JlLCBiZSBjYXJlZnVsIG5vdCB0byBjb25mbGF0ZSBT Q0lNIHdpdGggUkVTVC4gVWx0aW1hdGVseSwgRHluYW1pYyBSZWdpc3RyYXRpb24gd2FzIG1lYW50 IHRvIGJlIGEgZmFpcmx5IHNpbXBsZSBSRVNUL0pTT04gQVBJIHRoYXQgd291bGQgYmUgZWFzeSB0 byBpbXBsZW1lbnQsIGVzcGVjaWFsbHkgZm9yIGNsaWVudHMuIEp1c3QgYmVjYXVzZSBTQ0lNIGlz IFJFU1RmdWwgZG9lc24ndCBtZWFuIGl0J3MgYSBnb29kIHN0cnVjdHVyZSBmb3INCiBvdGhlciBS RVNUZnVsIEFQSXMuIE5hbWVseSwgSSBkb24ndCB0aGluayB0aGUgZXh0cmEgc3RydWN0dXJlIGFu ZCBob29rcyB3aXRoIFNDSU0gcmVhbGx5IGJ1eSB5b3UgYW55dGhpbmcgaGVyZSwgZXNwZWNpYWxs eSB3aXRoIHRoZSBhZGRpdGlvbnMgYW5kIGNoYW5nZXMgeW91J2QgaGF2ZSB0byBtYWtlIHRvIFND SU0uPGJyPg0KPGJyPg0KQW5kIGZpbmFsbHksIG5vYm9keSB0byBkYXRlIGhhcyBhY3R1YWxseSB3 cml0dGVuIGEgcHJvcG9zYWwgdGhhdCBpcyBldmVuIHJlbW90ZWx5IFNDSU0gYmFzZWQuDQo8YnI+ DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAwNS8yMi8yMDEzIDAyOjM5IFBNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBJIHJlYWxseSBkb27igJl0IHVu ZGVyc3RhbmQgd2h5IGR5bmFtaWMgcmVnaXN0cmF0aW9uIGlzIGluIHNjb3BlLCBJIHVuZGVyc3Rh bmQgdGhpcyByZWxhdGl2ZSB0byBPcGVuSUQgQ29ubmVjdCBidXQgbm90IE9BdXRoLCBpZiB0aGlz IGlzIGluZGVlZCBpbiBzY29wZSB0aGVuDQogSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoYXQgdGhl IGVuZHBvaW50IGJlIGJhc2VkIHVwb24gU0NJTSBhbmQgbm90IHNvbWV0aGluZyBlbHNlIGxpa2Ug d2hhdCBoYXMgYmVlbiBkb25lIGhlcmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBKdXN0aW4gUmljaGVyIFs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXRyZS5vcmciPm1haWx0bzpqcmljaGVyQG1pdHJlLm9yZzwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMjAsIDIwMTMgMTE6MTAgQU08YnI+DQo8Yj5Ubzo8L2I+ IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gUGhpbCBIdW50OyA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBQcm9wb3NlZCBTeW50YXggQ2hhbmdlcyBpbiBEeW5hbWljIFJlZ2lz dHJhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VG9ueSwgY2FuIHlvdSBiZSBtb3JlIHNwZWNpZmlj PyBXaGF0IG5lZWRzIHRvIGJlIGNoYW5nZWQgaW4geW91ciBvcGluaW9uPyBXaGF0IHRleHQgY2hh bmdlcyB3b3VsZCB5b3Ugc3VnZ2VzdD88YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNS8yMC8yMDEzIDAyOjA5 IFBNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFncmVlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBNYXkgMjAsIDIwMTMgOTo0MiBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlcjxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUHJvcG9zZWQgU3lu dGF4IENoYW5nZXMgaW4gRHluYW1pYyBSZWdpc3RyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBpc24ndCByZWFkeSBm b3IgTEMuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiAyMDEzLTA1LTIwLCBhdCA4OjQ5LCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls dG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QnV0IGFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhpcyBp cyBsYXN0LWNhbGwsIGFuZCB0aGF0IHdlIGRvbid0IHJlYWxseSB3YW50IHRvIGVuY291cmFnZSBh dm9pZGFibGUgZHJhc3RpYyBjaGFuZ2VzIGF0IHRoaXMgc3RhZ2UuDQo8YnI+DQo8YnI+DQombmJz cDstLSBKdXN0aW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNS8yMC8yMDEzIDExOjIxIEFNLCBQaGls IEh1bnQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPktlZXAgaW4gbWluZCB0aGVyZSBtYXkgYmUgb3RoZXIgY2hhbmdlcyBjb21pbmcu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBpc3N1ZSBpcyB0aGF0IG5ldyBkZXZlbG9wZXJzIGNhbid0IGZpZ3VyZSBvdXQgd2hh dCB0b2tlbiBpcyBiZWluZyByZWZlcnJlZCB0by4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gMjAxMy0wNS0yMCwgYXQgODowOSwgSnVzdGluIFJpY2hlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QaGlsIEh1bnQncyByZXZpZXcgb2YgdGhlIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNw ZWNpZmljYXRpb24gaGFzIHJhaXNlZCBhIGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBJIGZlbHQgd2Vy ZSBnZXR0aW5nIGJ1cmllZCBieSB0aGUgbGFyZ2VyIGRpc2N1c3Npb24gKHdoaWNoIEkgc3RpbGwg c3Ryb25nbHkgZW5jb3VyYWdlIG90aGVycyB0byBqdW1wIGluIHRvKS4gTmFtZWx5LCBQaGlsIGhh cyBzdWdnZXN0ZWQgYSBjb3VwbGUNCiBvZiBzeW50YXggY2hhbmdlcyB0byB0aGUgbmFtZXMgb2Yg c2V2ZXJhbCBwYXJhbWV0ZXJzLiA8YnI+DQo8YnI+DQo8YnI+DQoxKSBleHBpcmVzX2F0IC0mZ3Q7 IGNsaWVudF9zZWNyZXRfZXhwaXJlc19hdDxicj4NCjIpIGlzc3VlZF9hdCAtJmd0OyBjbGllbnRf aWRfaXNzdWVkX2F0PGJyPg0KMykgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QgLSZndDsgdG9r ZW5fZW5kcG9pbnRfY2xpZW50X2F1dGhfbWV0aG9kPGJyPg0KPGJyPg0KPGJyPg0KSSdkIGxpa2Ug dG8gZ2V0IGEgZmVlbGluZywgPGI+ZXNwZWNpYWxseSBmcm9tIGRldmVsb3BlcnM8L2I+IHdobyBo YXZlIGRlcGxveWVkIHRoaXMgZHJhZnQgc3BlYywgd2hhdCB3ZSBvdWdodCB0byBkbyBmb3IgZWFj aCBvZiB0aGVzZTo8YnI+DQo8YnI+DQombmJzcDtBKSBLZWVwIHRoZSBwYXJhbWV0ZXIgbmFtZXMg YXMtaXM8YnI+DQombmJzcDtCKSBBZG9wdCB0aGUgbmV3IG5hbWVzIGFzIGFib3ZlPGJyPg0KJm5i c3A7QykgQWRvcHQgYSBuZXcgbmFtZSB0aGF0IEkgd2lsbCBzcGVjaWZ5PGJyPg0KPGJyPg0KSW4g YWxsIGNhc2VzLCBjbGFyaWZ5aW5nIHRleHQgd2lsbCBiZSBhZGRlZCB0byB0aGUgcGFyYW1ldGVy ICpkZWZpbml0aW9ucyogc28gdGhhdCBpdCdzIG1vcmUgY2xlYXIgdG8gcGVvcGxlIHJlYWRpbmcg dGhlIHNwZWMgd2hhdCBlYWNoIHBpZWNlIGRvZXMuIFNwZWFraW5nIGFzIHRoZSBlZGl0b3I6ICZx dW90O0EmcXVvdDsgaXMgdGhlIGRlZmF1bHQgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQsIHNpbmNl IHdlIHNob3VsZG4ndCBjaGFuZ2Ugc3ludGF4IHdpdGhvdXQNCiB2ZXJ5IGdvb2QgcmVhc29uIHRv IGRvIHNvLiBUaGF0IHNhaWQsIGlmIGl0J3MgZ29pbmcgdG8gYmUgYmV0dGVyIGZvciBkZXZlbG9w ZXJzIHdpdGggdGhlIG5ldyBwYXJhbWV0ZXIgbmFtZXMsIEkgYW0gb3BlbiB0byBmaXhpbmcgdGhl bSBub3cuPGJyPg0KPGJyPg0KTmFtaW5nIHRoaW5ncyBpcyBoYXJkLjxicj4NCjxicj4NCiZuYnNw Oy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_be7043660ea2476ab64b7e42895c8793BY2PR03MB041namprd03pro_-- From jricher@mitre.org Wed May 22 15:52:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981DB11E8161 for ; Wed, 22 May 2013 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4evJL-KZPAtn for ; Wed, 22 May 2013 15:52:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBE511E8151 for ; Wed, 22 May 2013 15:52:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 938CE1F07A5; Wed, 22 May 2013 18:52:33 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 801001F0515; Wed, 22 May 2013 18:52:33 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 18:52:33 -0400 Message-ID: <519D4C12.7070209@mitre.org> Date: Wed, 22 May 2013 18:52:02 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Anthony Nadalin References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <519D2BE4.6080303@mitre.org> <8ae4313deafe4397b0b312ef38dcf182@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080207060301090504040206" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:52:42 -0000 --------------080207060301090504040206 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit In fact, one of the driving factors in this draft was so that OIDC and UMA wouldn't have to invent their own protocols and that we could abstract the knowledge in both of these for a well-considered basic use case. We as a working group long ago agreed that we needed to do dynamic registration in OAuth, and instead of trying to invent from whole cloth, we combined these two known protocols. This was the deliberate process and you can see that reflected in the document's history. So there's no forcing involved. -- Justin On 05/22/2013 06:48 PM, Anthony Nadalin wrote: > > My mistake, was to say, We already have OpenID Connect doing dynamic > registration, I don’t think there is a need to force it into OAuth. > > *From:*Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Wednesday, May 22, 2013 3:16 PM > *To:* Anthony Nadalin > *Cc:* Justin Richer; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > I'm having trouble understanding > > We already have OAuth doing dynamic registration, I don’t think > there is a need to force it into OAuth. > > I would be open to a scim dyn reg version. Particularly to discuss > instance metadata mgt which scim is good at and the credential > managemenr/bootstrap process as it pertains to oauth. Never-the-less > the overwhelming priority has been apparently to simply standardize > oidc and uma implementations as is. This I am not comfortable with but > i can live with if there is give and take. > > I feel the subject is well in charter and is an important issue due to > the life-cycle management issues behind clients and the need to make > public clients the security equiv. of confidential clients. > > Phil > > > On 2013-05-22, at 14:22, Anthony Nadalin > wrote: > > I totally disagree with your characterization of SCIM, while it > can be used from server to server (provision one system to > another) it can also be client to endpoint (initial provisioning > and JIT provisioning). SCIM is fairly simple (but can be complex), > I also have concerns about SCIM not being 100% restful but that > does not stop us from using it. I also agree that we should let > OAuth do what it’s good at and don’t try to force it into > something that it’s not. We already have OAuth doing dynamic > registration, I don’t think there is a need to force it into OAuth. > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Wednesday, May 22, 2013 1:35 PM > *To:* Anthony Nadalin > *Cc:* Phil Hunt; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic > Registration > > I'm not sure why you don't think it's in scope, it's in the > working group's charter: > > http://www.ietf.org/dyn/wg/charter/oauth-charter.html > > So ... it's definitely in scope, and has been for over a year and > a half. This is the tenth version of this document-- an IETF > Working Group document at that-- that's been posted to the group > with every revision and there has been significant conversation > around it, especially over the last six months since I took over > the editor role. There are also a handful of implementations of > this, and while most of them are built to do OpenID Connect or UMA > (which are directly built on OAuth), I know there are some that > also do plain OAuth. (Not the least of which is one that I have > personally implemented and deployed.) > > SCIM doesn't solve client management particularly well, since it's > made for users more than anything. The usage model of SCIM is also > quite different -- it's really intended to be used between two > servers to transfer information, as opposed to handling > self-asserted claims. I understand that some implementations like > UAA have done their static registration using a SCIM profile, but > it's not dynamic registration, really. I think it's too much of a > square-peg-round-hole problem, at least with SCIM as it is today; > so let SCIM do what it's good at, and don't try to force it into > something it's not. > > Furthermore, be careful not to conflate SCIM with REST. > Ultimately, Dynamic Registration was meant to be a fairly simple > REST/JSON API that would be easy to implement, especially for > clients. Just because SCIM is RESTful doesn't mean it's a good > structure for other RESTful APIs. Namely, I don't think the extra > structure and hooks with SCIM really buy you anything here, > especially with the additions and changes you'd have to make to SCIM. > > And finally, nobody to date has actually written a proposal that > is even remotely SCIM based. > > -- Justin > > On 05/22/2013 02:39 PM, Anthony Nadalin wrote: > > So, I really don’t understand why dynamic registration is in > scope, I understand this relative to OpenID Connect but not > OAuth, if this is indeed in scope then I would have expected > that the endpoint be based upon SCIM and not something else > like what has been done here. > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Monday, May 20, 2013 11:10 AM > *To:* Anthony Nadalin > *Cc:* Phil Hunt; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic > Registration > > Tony, can you be more specific? What needs to be changed in > your opinion? What text changes would you suggest? > > -- Justin > > On 05/20/2013 02:09 PM, Anthony Nadalin wrote: > > Agree > > *From:*oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Monday, May 20, 2013 9:42 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in > Dynamic Registration > > This draft isn't ready for LC. > > Phil > > > On 2013-05-20, at 8:49, Justin Richer > wrote: > > But also keep in mind that this is last-call, and that > we don't really want to encourage avoidable drastic > changes at this stage. > > -- Justin > > > > > On 05/20/2013 11:21 AM, Phil Hunt wrote: > > Keep in mind there may be other changes coming. > > The issue is that new developers can't figure out > what token is being referred to. > > > Phil > > > On 2013-05-20, at 8:09, Justin Richer > > wrote: > > Phil Hunt's review of the Dynamic Registration > specification has raised a couple of issues > that I felt were getting buried by the larger > discussion (which I still strongly encourage > others to jump in to). Namely, Phil has > suggested a couple of syntax changes to the > names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> > token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from > developers* who have deployed this draft spec, > what we ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to > the parameter *definitions* so that it's more > clear to people reading the spec what each > piece does. Speaking as the editor: "A" is the > default as far as I'm concerned, since we > shouldn't change syntax without very good > reason to do so. That said, if it's going to > be better for developers with the new > parameter names, I am open to fixing them now. > > Naming things is hard. > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------080207060301090504040206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit In fact, one of the driving factors in this draft was so that OIDC and UMA wouldn't have to invent their own protocols and that we could abstract the knowledge in both of these for a well-considered basic use case. We as a working group long ago agreed that we needed to do dynamic registration in OAuth, and instead of trying to invent from whole cloth, we combined these two known protocols. This was the deliberate process and you can see that reflected in the document's history.

So there's no forcing involved.
 -- Justin

On 05/22/2013 06:48 PM, Anthony Nadalin wrote:

My mistake, was to say, We already have OpenID Connect doing dynamic registration, I don’t think there is a need to force it into OAuth.

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

I'm having trouble understanding

We already have OAuth doing dynamic registration, I don’t think there is a need to force it into OAuth.

 

 

I would be open to a scim dyn reg version. Particularly to discuss instance metadata mgt which scim is good at and the credential managemenr/bootstrap process as it pertains to oauth.  Never-the-less the overwhelming priority has been apparently to simply standardize oidc and uma implementations as is. This I am not comfortable with but i can live with if there is give and take. 

 

I feel the subject is well in charter and is an important issue due to the life-cycle management issues behind clients and the need to make public clients the security equiv. of confidential clients. 

 

Phil


On 2013-05-22, at 14:22, Anthony Nadalin <tonynad@microsoft.com> wrote:

I totally disagree with your characterization of SCIM, while it can be used from server to server (provision one system to another) it can also be client to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple (but can be complex), I also have concerns about SCIM not being 100% restful but that does not stop us from using it. I also agree that we should let OAuth do what it’s good at and don’t try to force it into something that it’s not. We already have OAuth doing dynamic registration, I don’t think there is a need to force it into OAuth.

 

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

I'm not sure why you don't think it's in scope, it's in the working group's charter:

  http://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a half. This is the tenth version of this document-- an IETF Working Group document at that-- that's been posted to the group with every revision and there has been significant conversation around it, especially over the last six months since I took over the editor role. There are also a handful of implementations of this, and while most of them are built to do OpenID Connect or UMA (which are directly built on OAuth), I know there are some that also do plain OAuth. (Not the least of which is one that I have personally implemented and deployed.)

SCIM doesn't solve client management particularly well, since it's made for users more than anything. The usage model of SCIM is also quite different -- it's really intended to be used between two servers to transfer information, as opposed to handling self-asserted claims. I understand that some implementations like UAA have done their static registration using a SCIM profile, but it's not dynamic registration, really. I think it's too much of a square-peg-round-hole problem, at least with SCIM as it is today; so let SCIM do what it's good at, and don't try to force it into something it's not.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic Registration was meant to be a fairly simple REST/JSON API that would be easy to implement, especially for clients. Just because SCIM is RESTful doesn't mean it's a good structure for other RESTful APIs. Namely, I don't think the extra structure and hooks with SCIM really buy you anything here, especially with the additions and changes you'd have to make to SCIM.

And finally, nobody to date has actually written a proposal that is even remotely SCIM based.

 -- Justin

On 05/22/2013 02:39 PM, Anthony Nadalin wrote:

So, I really don’t understand why dynamic registration is in scope, I understand this relative to OpenID Connect but not OAuth, if this is indeed in scope then I would have expected that the endpoint be based upon SCIM and not something else like what has been done here.

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

Tony, can you be more specific? What needs to be changed in your opinion? What text changes would you suggest?

 -- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin wrote:

Agree

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

This draft isn't ready for LC. 

Phil


On 2013-05-20, at 8:49, Justin Richer <jricher@mitre.org> wrote:

But also keep in mind that this is last-call, and that we don't really want to encourage avoidable drastic changes at this stage.

 -- Justin




On 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes coming. 

 

The issue is that new developers can't figure out what token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer <jricher@mitre.org> wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin

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

 

 

 


--------------080207060301090504040206-- From Michael.Jones@microsoft.com Wed May 22 15:57:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6765D11E8168 for ; Wed, 22 May 2013 15:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi+L1DwZWYO4 for ; Wed, 22 May 2013 15:57:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id CD98911E814B for ; Wed, 22 May 2013 15:57:40 -0700 (PDT) Received: from BL2FFO11FD026.protection.gbl (10.173.161.200) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 22 May 2013 22:57:38 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 22 May 2013 22:57:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 22 May 2013 22:56:37 +0000 From: Mike Jones To: Justin Richer , Phil Hunt Thread-Topic: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) Thread-Index: AQHOVzfktoqTEMHNbUiHNzipr6xriZkRxWiAgAABBQCAAAe3AIAAAiIA Date: Wed, 22 May 2013 22:56:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436775672D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> <519D4AEC.9040303@mitre.org> In-Reply-To: <519D4AEC.9040303@mitre.org> 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_4E1F6AAD24975D4BA5B16804296739436775672DTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377424003)(24454002)(479174002)(199002)(377454002)(63696002)(20776003)(81342001)(54316002)(74662001)(47446002)(74502001)(50986001)(54356001)(4396001)(512954002)(69226001)(49866001)(56776001)(81542001)(51856001)(56816002)(55846006)(47736001)(46102001)(44976003)(71186001)(76482001)(47976001)(15974865001)(74706001)(53806001)(33656001)(74876001)(79102001)(80022001)(561944002)(66066001)(6806003)(16236675002)(74366001)(16406001)(31966008)(59766001)(77982001)(65816001)(15202345002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0854128AF0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:57:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436775672DTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that any new field or fields should be defined once the requirement= s and flows are well-specified and well-understood as part of a complete sp= ecification for those flows and use cases. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Wednesday, May 22, 2013 3:47 PM To: Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_i= d definition issue (was: Client Instances) I agree with Prateek that redirect_uri isn't sufficient or well-suited for = this, but I also agree with John that software_id on its own doesn't buy yo= u a whole lot as a standalone field. It could be a reasonable stepping ston= e to future, more high-assurance work, but my question is then: is it reall= y worth it to define a field now when the real work will come later? Why no= t just define the field then and make it fit better? -- Justin On 05/22/2013 06:19 PM, Phil Hunt wrote: I dont see a big issue with a faked software_id. As i said it was a minimal= proposal with the door open to stronger assertions. Rogue clients pretending to be something they are not is actually more evid= ence of a problem. In draft 10 you cant even do that. Phil On 2013-05-22, at 15:15, John Bradley > wrote: At the moment for Mobile devices and other native apps all we have to relia= bly identify the app is the redirect_uri. The client_id is trivially faked in native apps. Yes in a well groomed enterprise trusting a self asserted software identifi= er is nice but probably doesn't scale to the real world. I have had discussions with MDM venders about how you might be able to tie = access tokens to a instance of software on a device and determine if that s= oftware is allowed to be run by that user on that device. These are all much more complicated discussions than just sticking another = registration parameter on. I don't think this should block the basic dynamic registration spec. App = lifecycle needs a full spec, and additional registration parameters can be = added later if required. I am not insensitive to the problem. John B. On 2013-05-22, at 6:00 PM, prateek mishra > wrote: Well, I have to say that if anything seems poorly thought out, it would be = a design with the following characteristics. [quote] We already have a "software_id" field and it's named "redirect_uris" [\quote] This seems to violate the most basic principles of software design - overlo= ading a field with meaning distinct from its primary purpose!! Phil has raised some substantive questions regarding client meta-data and t= he registration process. This information (software_id) is essential for identifying and disabling a class of clients that may have be= en found to have some security flaws, for example. This is a practical deployment issue that also impacts the security charact= eristics of OAuth. It should be taken into account in the client registrat= ion process. I hope we will take the time to discuss this issue carefully and not rush = to finalize a specification which has NOT received much review from the OAuth community. - prateek +1 We already have a "software_id" field and it's named "redirect_uris". This doesn't seem well thought-out. We shouldn't try to jam it into the sp= ec at the last minute. The good news is that since the registration spec allows for extensions, an= d the proposed fields are optional, these could be added later as a non-bre= aking change by another spec if the working group eventually decides to pur= sue a route like the one proposed below. We don't have to do it now for th= is to eventually come into being after deliberate consideration of a comple= te specification including these features by the working group. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, May 22, 2013 2:21 PM To: Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_i= d definition issue (was: Client Instances) Phil, As I pointed out in the other thread, redirect_uri is the thing that ties = together the clients as that is the place the responses need to go to so is= hard to fake. All instances of a particular client application will share the same redire= ct_uri across all instances. Adding a bunch of self asserted informational fields to the base spec is no= t really helping. In a enterprise situation where all the apps play nice i= t might be helpfull but the reality is that you probably allready have a MD= M that lets you manage app versions. John On 2013-05-22, at 3:59 PM, Phil Hunt > wrote: I had a conversation with Justin yesterday to try to come to a resolution r= egarding my concerns about client instances and being able to associate cli= ent instances that are issued for the same client software. I think we made= some progress. Background: In RFC6749, public clients, had a common client_id. Many interpreted client= _id as refering to the client application software (e.g. the iPhone Faceboo= k app). This is probably due to the types of OAuth2 implementations that ex= isted at the time, where there was a single SP instance. Others have inter= preted that client_id does not refer to client applications but rather idea= lly should point to instances of software. To me this seems like equating a= client_id to being a user-id -- IOW the key part of a credential rather th= an a client identifier. The new draft proposes that each instance be identified separately. However= it does so without keeping track of client software that is the same. Never-the-less, I think both interpretations can be accommodated. Finally, in single instance services (like Facebook, Twitter, etc), there w= as a natural registration and approval cycle bound into the client_id issua= nce process. The developer was able to talk to the single service provider = and obtain a client_id for all deployments. It wasn't stated, but the clien= t_id registration sites served a useful way to do application approvals. T= his is a difficult problem to solve when there are multiple instance of Res= ource API deployed in multiple locations. The developer can't contact them = all. Further, because the current draft loses knowledge of how to recogniz= e that two instances of clients share the same software, there's no ability= to have an approval process. Each instance is essentially anonymous, and t= hus approval processes would not be possible. Though it does not require i= t, this proposal makes it possible for service providers to recognize new s= oftware and to have approval process. Proposal: What I have worked out with Justin (and he may not yet fully agree with eve= rything) is a proposal that solves the problem in an optional way that will= not break existing clients. I also propose that optional version numbers also be supported. This is use= ful to service providers who need to know which client_ids are affected whe= n certain software clients and/or versions are deprecated. The re-introduct= ion of the renamed software_id further enables "local" registration to occu= r. The first time a client tries to register, a service provider could for = example, choose to hold the registration to obtain administrative approval. The solution here is not intended to provide software "authentication" or s= oftware verification. The solution simply allows service providers to make = pragmatic decisions about sets of clients that typically work the same way = in a change managed environment. Question: What happens if the server does not support these new parameters= and the client provides them? The current draft already covers this in Se= ction 3. Specifically: The Client Registration Endpoint MUST ignore all parameters it does not un= derstand. Below are 3 options for the group to consider. My recommendation is for op= tion 1. My concern is option 2 will lead to complexity because clients and = service providers will attempt to encode versions and software identifiers = into one field. I would rather keep this to simple UUIDs for most cases. Option 1 (2 parameters): software_id This value MAY be required by registration endpoints. The value MAY be a un= ique identifier (UUID) self-assigned by a the client application developer,= or it MAY be an assertion. The value SHOULD be the same across all instanc= es of a client on an application platform. For example, software used in a = mobile phone should be considered as different from a web server implementa= tion though it may share the same code. The identifier SHOULD NOT change be= tween software updates. While a client application MAY be issued multiple c= lient_id's and client credentials over its deployment lifecycle, the softwa= re_id SHOULD NOT change. Signed assertions MAY be used as software identifiers to allow different dy= namic registration end-points to recognize approval from a common issuer (f= or example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and = the method by which developers know how to obtain assertions is out of scop= e for this specification. [editorial note: some current deployments are using temporary client creden= tial assertions for this purpose. I propose to standardize this in this fie= ld since an assertion would server the same purpose as a UUID only providin= g third party signing and other claims. I am concerned that passing a clien= t assertion for this purpose creates complexity in client authentication pr= ocessing - though obviously Justin has it working] software_version RECOMMENDED. A version indicates a client developer chosen version number. = The identifier SHOULD BE the same across all copies of client software. The= version number SHOULD change between different client updates. The intenti= on is that Service Providers MAY perform equality matching with software_id= to sub-select groups of clients of a particular software version. Option 2 (single parameter): software_id This value MAY be required by registration endpoints. The value MAY be a un= ique identifier (UUID) self-assigned by a the client application developer,= or it MAY be an assertion. The value SHOULD be the same across all instanc= es of a client on an application platform. For example, software used in a = mobile phone should be considered as different from a web server implementa= tion though it may share the same code. The identifier SHOULD change when t= he client software has changed such as with a version update or a platform = change. Signed assertions MAY be used as software identifiers to allow different dy= namic registration end-points to recognize approval from a common issuer (f= or example in cases where the resource API released by a single publisher b= ut deployed in many different domains). The decision to use assertions and = the method by which developers know how to obtain assertions is out of scop= e for this specification. [note: same editorial note as option 1] Option 3 (no change): In this option, no changes to the draft are made. Personal comment: It has been proposed by several on the list that another= extension draft be written for these features as an extension to the dynam= ic registration draft. In my opinion, such a draft would be very small in s= ize without clear reason for separation. My feeling is that some technical = justification for keeping these features separated will likely be needed. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436775672DTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that any new fiel= d or fields should be defined once the requirements and flows are well-spec= ified and well-understood as part of a complete specification for those flows and use cases.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 3:47 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to c= lient_id definition issue (was: Client Instances)

 

I agree with Prateek = that redirect_uri isn't sufficient or well-suited for this, but I also agre= e with John that software_id on its own doesn't buy you a whole lot as a st= andalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is the= n: is it really worth it to define a field now when the real work will come= later? Why not just define the field then and make it fit better?

 -- Justin

On 05/22/2013 06:19 PM, Phil Hunt wrote:<= /p>

I dont see a big issue with a faked software_id. As = i said it was a minimal proposal with the door open to stronger assertions.=  

 

Rogue clients pretending to be something they are no= t is actually more evidence of a problem. In draft 10 you cant even do that= . 

Phil


On 2013-05-22, at 15:15, John Bradley <ve7jtb@ve7jtb.com> wrote:

At the moment for Mobile devices and other native ap= ps all we have to reliably identify the app is the redirect_uri.  

 

The client_id is trivially faked in native apps.&nbs= p;

 

Yes in a well groomed enterprise trusting a self ass= erted software identifier is nice but probably doesn't scale to the real wo= rld.

 

I have had discussions with MDM venders about how yo= u might be able to tie access tokens to a instance of software on a device = and determine if that software is allowed to be run by that user on that de= vice.

These are all much more complicated discussions than= just sticking another registration parameter on.

 

I don't think this should block the basic dynamic re= gistration spec.   App lifecycle needs a full spec, and additional reg= istration parameters can be added later if required.

 

I am not insensitive to the problem.

 

John B.

On 2013-05-22, at 6:00 PM, prateek mishra <prateek.mishra@oracle.com> wr= ote:



Well, I have to say that if anything seems poorly th= ought out, it would be a design with the following characteristics.

[quote]
We already have a “software_id” fiel= d and it’s named “redirect_uris”
[\quote]

This seems to violate the most basic principles of software design - overlo= ading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data and t= he registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have be= en found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security charact= eristics of OAuth.  It should be taken into account in the client regi= stration process.

I hope we will take the time to discuss this issue carefully and not rush&n= bsp; to finalize a specification which has NOT received much review
from the OAuth community.

- prateek




+1<= /p>

 <= /p>

We already have a “= software_id” field and it’s named “redirect_uris”.<= /span>

 <= /p>

This doesn’t seem w= ell thought-out.  We shouldn’t try to jam it into the spec at th= e last minute.

 <= /p>

The good news is that sin= ce the registration spec allows for extensions, and the proposed fields are= optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a= route like the one proposed below.  We don’t have to do it now = for this to eventually come into being after deliberate consideration of a = complete specification including these features by the working group.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to c= lient_id definition issue (was: Client Instances)

 

Phil,

 

As I pointed out in the other thread,  redirect= _uri is the thing that ties together the clients as that is the place the r= esponses need to go to so is hard to fake.

 

All instances of a particular client application wil= l share the same redirect_uri across all instances.   =

 

Adding a bunch of self asserted informational fields= to the base spec is not really helping.  In a enterprise situation wh= ere all the apps play nice it might be helpfull but the reality is that you= probably allready have a MDM that lets you manage app versions.

 

John 

 

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=




I had a conversation with Justin yesterday to try to= come to a resolution regarding my concerns about client instances and bein= g able to associate client instances that are issued for the same client so= ftware. I think we made some progress.

 

Background:  

In RFC6749, public clients, had a common client_id. = Many interpreted client_id as refering to the client application software (= e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 = implementations that existed at the time, where there was a single SP instance.  Others have interpreted = that client_id does not refer to client applications but rather ideally sho= uld point to instances of software. To me this seems like equating a client= _id to being a user-id -- IOW the key part of a credential rather than a client identifier. 

 

The new draft proposes that each instance be identif= ied separately. However it does so without keeping track of client software= that is the same.

 

Never-the-less, I think both interpretations can be = accommodated.

 

Finally, in single instance services (like Facebook,= Twitter, etc), there was a natural registration and approval cycle bound i= nto the client_id issuance process. The developer was able to talk to the s= ingle service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id regis= tration sites served a useful way to do application approvals.  This i= s a difficult problem to solve when there are multiple instance of Resource= API deployed in multiple locations. The developer can't contact them all.  Further, because the current d= raft loses knowledge of how to recognize that two instances of clients shar= e the same software, there's no ability to have an approval process. Each i= nstance is essentially anonymous, and thus approval processes would not be possible.  Though it does not re= quire it, this proposal makes it possible for service providers to recogniz= e new software and to have approval process.

 

Proposal:

What I have worked out with Justin (and he may not y= et fully agree with everything) is a proposal that solves the problem in an= optional way that will not break existing clients. 

 

I also propose that optional version numbers also be= supported. This is useful to service providers who need to know which clie= nt_ids are affected when certain software clients and/or versions are depre= cated. The re-introduction of the renamed software_id further enables "local" registration to occu= r. The first time a client tries to register, a service provider could for = example, choose to hold the registration to obtain administrative approval.=

 

The solution here is not intended to provide softwar= e "authentication" or software verification. The solution simply = allows service providers to make pragmatic decisions about sets of clients = that typically work the same way in a change managed environment. 

 

Question:  What happens if the server does not = support these new parameters and the client provides them?  The curren= t draft already covers this in Section 3.  Specifically: 

 The Client Registration End=
point MUST ignore all parameters it does not understand.<=
/pre>

 

Below are 3 options for the group to consider.  = ;My recommendation is for option 1. My concern is option 2 will lead to com= plexity because clients and service providers will attempt to encode versio= ns and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

 

Option 1 (2 parameters):

 

software_id

This value MAY be required by registration endpoints= . The value MAY be a unique identifier (UUID) self-assigned by a the client= application developer, or it MAY be an assertion. The value SHOULD be the = same across all instances of a client on an application platform. For example, = software used in a mobile phone should be considered as different from a we= b server implementation though it may share the same code.&nb= sp;The identifier SHOULD NOT change between software updates.&nb= sp;While a client application MAY be issued multiple client_id's and client= credentials over its deployment lifecycle, the software_id SHOULD NOT chan= ge.

 

Signed assertions MAY be used as software identifier= s to allow different dynamic registration end-points to recognize approval = from a common issuer (for example in cases where the resource API released = by a single publisher but deployed in many different domains). The decision to use assertions and the method = by which developers know how to obtain assertions is out of scope for this = specification.

 

[editorial note: some current deployments are using tempor= ary client credential assertions for this purpose. I propose to standardize= this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims= . I am concerned that passing a client assertion for this purpose creates c= omplexity in client authentication processing - though obviously Justin has= it working]

 

software_version

RECOMMENDED. A version indicates a client developer = chosen version number. The identifier SHOULD BE the same across all copies = of client software. The version number SHOULD change between different clie= nt updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-se= lect groups of clients of a particular software version.

 

Option 2 (single p= arameter):

 

software_id

This value MAY be required by registration endpoints= . The value MAY be a unique identifier (UUID) self-assigned by a the client= application developer, or it MAY be an assertion. The value SHOULD be the = same across all instances of a client on an application platform. For example, software used in a mobile phone s= hould be considered as different from a web server implementation though it= may share the same code. The identifier SHOULD change whe= n the client software has changed such as with a version update or a platform change.

 

Signed assertions MAY be used as software identifier= s to allow different dynamic registration end-points to recognize approval = from a common issuer (for example in cases where the resource API released = by a single publisher but deployed in many different domains). The decision to use assertions and the method = by which developers know how to obtain assertions is out of scope for this = specification.

 

[note: same editorial note as option 1]<= /p>

 

Option 3 (no change):

 

In this option, no changes to the draft are made.&nb= sp;

 

Personal comment:  It has been proposed by seve= ral on the list that another extension draft be written for these features = as an extension to the dynamic registration draft. In my opinion, such a dr= aft would be very small in size without clear reason for separation. My feeling is that some technical justificati= on for keeping these features separated will likely be needed.

 

 




 

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

 




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

 

 




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

 

--_000_4E1F6AAD24975D4BA5B16804296739436775672DTK5EX14MBXC283r_-- From sakimura@gmail.com Wed May 22 15:58:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B352011E815C for ; Wed, 22 May 2013 15:58:35 -0700 (PDT) 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.988, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SZAd1fHStYV for ; Wed, 22 May 2013 15:58:31 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 07B3311E814B for ; Wed, 22 May 2013 15:58:27 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id x10so2656186lbi.7 for ; Wed, 22 May 2013 15:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pdh9XAYTXRrEFKc3kkBp1sMvZ99ZIp5vGMW0xEOMixw=; b=dYpE74Y9J4gndujSml8FZji+J8Ni5TOOFCLp6dhSiRrm8dZt7ASzTFfTMBqDcNXpXC RnE05Bw+o7LmWLIWm7VKTgqy4UnDMqYDpdpWBaOo93twgfme4twFTJIHth+Q1L5pjyN/ +9Ofg7zci2sjuUakZn5SJUu2+5Ezq2rTLqqROzQ3j+tHX5rKXD9nCTkPZfBDWrQMCAMm rXiEHsT50UQNIWeG0/VGz+9LHRelNUzGrEs0F6hc/S4YSATX/oWAZD3h8JClU0PfRChG /jUgSGgmbiiGTrDTDh4SYSgFTjX2Su5Lz28F/z+cjylDRoebtjKlLW+I3vnn5jWdYn4x sYzA== MIME-Version: 1.0 X-Received: by 10.112.6.135 with SMTP id b7mr5080266lba.104.1369263506842; Wed, 22 May 2013 15:58:26 -0700 (PDT) Received: by 10.112.81.9 with HTTP; Wed, 22 May 2013 15:58:26 -0700 (PDT) In-Reply-To: <519D4AEC.9040303@mitre.org> References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> <519D4AEC.9040303@mitre.org> Date: Thu, 23 May 2013 07:58:26 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=14dae947303bedef7804dd568031 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 22:58:35 -0000 --14dae947303bedef7804dd568031 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It is not worth defining it now. It actually is harmful. I can see developers start trusting the identifier and causing problems later. We should do it together with more thought out security measures. 2013/5/23 Justin Richer > I agree with Prateek that redirect_uri isn't sufficient or well-suited > for this, but I also agree with John that software_id on its own doesn't > buy you a whole lot as a standalone field. It could be a reasonable > stepping stone to future, more high-assurance work, but my question is > then: is it really worth it to define a field now when the real work will > come later? Why not just define the field then and make it fit better? > > -- Justin > > > On 05/22/2013 06:19 PM, Phil Hunt wrote: > > I dont see a big issue with a faked software_id. As i said it was a > minimal proposal with the door open to stronger assertions. > > Rogue clients pretending to be something they are not is actually more > evidence of a problem. In draft 10 you cant even do that. > > Phil > > On 2013-05-22, at 15:15, John Bradley wrote: > > At the moment for Mobile devices and other native apps all we have to > reliably identify the app is the redirect_uri. > > The client_id is trivially faked in native apps. > > Yes in a well groomed enterprise trusting a self asserted software > identifier is nice but probably doesn't scale to the real world. > > I have had discussions with MDM venders about how you might be able to > tie access tokens to a instance of software on a device and determine if > that software is allowed to be run by that user on that device. > These are all much more complicated discussions than just sticking anothe= r > registration parameter on. > > I don't think this should block the basic dynamic registration spec. > App lifecycle needs a full spec, and additional registration parameters c= an > be added later if required. > > I am not insensitive to the problem. > > John B. > On 2013-05-22, at 6:00 PM, prateek mishra > wrote: > > Well, I have to say that if anything seems poorly thought out, it would > be a design with the following characteristics. > > [quote] > We already have a =93software_id=94 field and it=92s named =93redirect_ur= is=94 > [\quote] > > This seems to violate the most basic principles of software design - > overloading a field with meaning distinct from its primary purpose!! > > Phil has raised some substantive questions regarding client meta-data and > the registration process. This information (software_id) is > essential for identifying and disabling a class of clients that may have > been found to have some security flaws, for example. > This is a practical deployment issue that also impacts the security > characteristics of OAuth. It should be taken into account in the client > registration process. > > I hope we will take the time to discuss this issue carefully and not rush > to finalize a specification which has NOT received much review > from the OAuth community. > > - prateek > > > > +1**** > > > > We already have a =93software_id=94 field and it=92s named =93redirect_ur= is=94.**** > > > > This doesn=92t seem well thought-out. We shouldn=92t try to jam it into = the > spec at the last minute.**** > > > > The good news is that since the registration spec allows for extensions, > and the proposed fields are optional, these could be added later as a > non-breaking change by another spec if the working group eventually decid= es > to pursue a route like the one proposed below. We don=92t have to do it = now > for this to eventually come into being after deliberate consideration of = a > complete specification including these features by the working group.**** > > > > -- Mike**= * > * > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *John Bradley > *Sent:* Wednesday, May 22, 2013 2:21 PM > *To:* Phil Hunt > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to > client_id definition issue (was: Client Instances)**** > > ** ** > > Phil,**** > > ** ** > > As I pointed out in the other thread, redirect_uri is the thing that tie= s > together the clients as that is the place the responses need to go to so = is > hard to fake.**** > > ** ** > > All instances of a particular client application will share the same > redirect_uri across all instances. **** > > ** ** > > Adding a bunch of self asserted informational fields to the base spec is > not really helping. In a enterprise situation where all the apps play ni= ce > it might be helpfull but the reality is that you probably allready have a > MDM that lets you manage app versions.**** > > ** ** > > John **** > > ** ** > > On 2013-05-22, at 3:59 PM, Phil Hunt wrote:**** > > > > **** > > I had a conversation with Justin yesterday to try to come to a resolution > regarding my concerns about client instances and being able to associate > client instances that are issued for the same client software. I think we > made some progress.**** > > ** ** > > *Background: ***** > > In RFC6749, public clients, had a common client_id. Many interpreted > client_id as refering to the client application software (e.g. the iPhone > Facebook app). This is probably due to the types of OAuth2 implementation= s > that existed at the time, where there was a single SP instance. Others > have interpreted that client_id does not refer to client applications but > rather ideally should point to instances of software. To me this seems li= ke > equating a client_id to being a user-id -- IOW the key part of a credenti= al > rather than a client identifier. **** > > ** ** > > The new draft proposes that each instance be identified separately. > However it does so without keeping track of client software that is the > same.**** > > ** ** > > Never-the-less, I think both interpretations can be accommodated.**** > > ** ** > > Finally, in single instance services (like Facebook, Twitter, etc), there > was a natural registration and approval cycle bound into the client_id > issuance process. The developer was able to talk to the single service > provider and obtain a client_id for all deployments. It wasn't stated, bu= t > the client_id registration sites served a useful way to do application > approvals. This is a difficult problem to solve when there are multiple > instance of Resource API deployed in multiple locations. The developer > can't contact them all. Further, because the current draft loses knowled= ge > of how to recognize that two instances of clients share the same software= , > there's no ability to have an approval process. Each instance is > essentially anonymous, and thus approval processes would not be possible. > Though it does not require it, this proposal makes it possible for servi= ce > providers to recognize new software and to have approval process.**** > > ** ** > > *Proposal:***** > > What I have worked out with Justin (and he may not yet fully agree with > everything) is a proposal that solves the problem in an optional way that > will not break existing clients. **** > > ** ** > > I also propose that optional version numbers also be supported. This is > useful to service providers who need to know which client_ids are affecte= d > when certain software clients and/or versions are deprecated. The > re-introduction of the renamed software_id further enables "local" > registration to occur. The first time a client tries to register, a servi= ce > provider could for example, choose to hold the registration to obtain > administrative approval.**** > > ** ** > > The solution here is not intended to provide software "authentication" or > software verification. The solution simply allows service providers to ma= ke > pragmatic decisions about sets of clients that typically work the same wa= y > in a change managed environment. **** > > ** ** > > Question: What happens if the server does not support these new > parameters and the client provides them? The current draft already cover= s > this in Section 3. Specifically:**** > > The Client Registration Endpoint MUST ignore all parameters it does not = understand.**** > > ** ** > > Below are 3 options for the group to consider. My recommendation is for > option 1. My concern is option 2 will lead to complexity because clients > and service providers will attempt to encode versions and software > identifiers into one field. I would rather keep this to simple UUIDs for > most cases.**** > > ** ** > > *Option 1 (2 parameters):***** > > ** ** > > software_id**** > > This value MAY be required by registration endpoints. The value MAY be a > unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same across > all instances of a client on an application platform. For example, > software used in a mobile phone should be considered as different from a > web server implementation though it may share the same code. The > identifier *SHOULD NOT *change between software updates. While a client > application MAY be issued multiple client_id's and client credentials ove= r > its deployment lifecycle, the software_id SHOULD NOT change.**** > > ** ** > > Signed assertions MAY be used as software identifiers to allow different > dynamic registration end-points to recognize approval from a common issue= r > (for example in cases where the resource API released by a single publish= er > but deployed in many different domains). The decision to use assertions a= nd > the method by which developers know how to obtain assertions is out of > scope for this specification.**** > > ** ** > > [editorial note: some current deployments are using temporary client > credential assertions for this purpose. I propose to standardize this in > this field since an assertion would server the same purpose as a UUID onl= y > providing third party signing and other claims. I am concerned that passi= ng > a client assertion for this purpose creates complexity in client > authentication processing - though obviously Justin has it working]**** > > ** ** > > software_version**** > > RECOMMENDED. A version indicates a client developer chosen version number= . > The identifier SHOULD BE the same across all copies of client software. T= he > version number SHOULD change between different client updates. The > intention is that Service Providers MAY perform equality matching with > software_id to sub-select groups of clients of a particular software > version.**** > > ** ** > > *Option 2 (single parameter):***** > > ** ** > > software_id**** > > This value MAY be required by registration endpoints. The value MAY be a > unique identifier (UUID) self-assigned by a the client application > developer, or it MAY be an assertion. The value SHOULD be the same across > all instances of a client on an application platform. For example, softwa= re > used in a mobile phone should be considered as different from a web serve= r > implementation though it may share the same code. The identifier *SHOULD*= change > when the client software has changed such as with a version update or a > platform change.**** > > > > Signed assertions MAY be used as software identifiers to allow different > dynamic registration end-points to recognize approval from a common issue= r > (for example in cases where the resource API released by a single publish= er > but deployed in many different domains). The decision to use assertions a= nd > the method by which developers know how to obtain assertions is out of > scope for this specification.**** > > ** ** > > [note: same editorial note as option 1]**** > > ** ** > > *Option 3 (no change):***** > > ** ** > > In this option, no changes to the draft are made. **** > > ** ** > > Personal comment: It has been proposed by several on the list that > another extension draft be written for these features as an extension to > the dynamic registration draft. In my opinion, such a draft would be very > small in size without clear reason for separation. My feeling is that som= e > technical justification for keeping these features separated will likely = be > needed.**** > > ** ** > > Phil**** > > > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > > > > > **** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > 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 --14dae947303bedef7804dd568031 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It is not worth defining it now. It actually is harmful.= =A0
I can see developers start trusting the identifier and causing prob= lems later.=A0
We should do it together with more thought out sec= urity measures.=A0


2013/5/= 23 Justin Richer <jricher@mitre.org>
=20 =20 =20
I agree with Prateek that redirect_uri isn't sufficient or well-suited for this, but I also agree with John that software_id on its own doesn't buy you a whole lot as a standalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is then: is it really worth it to define a field now when the real work will come later? Why not just define the field then and make it fit better?

=A0-- Justin


On 05/22/2013 06:19 PM, Phil Hunt wrote:
=20
I dont see a big issue with a faked software_id. As i said it was a minimal proposal with the door open to stronger assertions.=A0

Rogue clients pretending to be something they are not is actually more evidence of a problem. In draft 10 you cant even do that.=A0

Phil

On 2013-05-22, at 15:15, John Bradley <ve7jtb@ve7jtb.com> wrote:

At the moment for Mobile devices and other native apps all we have to reliably identify the app is the redirect_uri. =A0

The client_id is trivially faked in native apps.=A0

Yes in a well groomed enterprise trusting a self asserted software identifier is nice but probably doesn't scale to the real world.

I have had discussions with MDM venders about how you might be able to tie access tokens to a instance of software on a device and determine if that software is allowed to be run by that user on that device.
These are all much more complicated discussions than just sticking another registration parameter on.

I don't think this should block the basic dynamic registration spec. =A0 App lifecycle needs a full spec, and additional registration parameters can be added later if required.

I am not insensitive to the problem.

John B.
On 2013-05-22, at 6:00 PM, prateek mishra <prateek.mishra@oracle.= com> wrote:

Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a =93software_id=94 field and it=92s named =93redirect_uris=94
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth.=A0 It should be taken into account in the client registration process.

I hope we will take the time to discuss this issue carefully and not rush=A0 to finalize a specification which has NOT received much review
from the OAuth community.

- prateek



=20 =20

+1<= u>

=A0=

We already have a =93software_id=94 field and it=92s named =93redirect_uris=94.

=A0=

Thi= s doesn=92t seem well thought-out.=A0 We shouldn=92= t try to jam it into the spec at the last minute.

=A0=

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below.=A0 We don=92t have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

=A0=

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

=A0

Phil,

=A0

As I pointed out in the other thread, =A0redirect_uri is the thing that ties together the clients as that is the place the responses need to go to so is hard to fake.

=A0

All instances of a particular client application will share the same redirect_uri across all instances. =A0=A0=

=A0

Adding a bunch of self asserted informational fields to the base spec is not really helping. =A0In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

=A0

John=A0

=A0

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

=A0

Background: =A0<= /i>

In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance. =A0Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier.=A0

=A0

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

=A0

Never-the-less, I think both interpretations can be accommodated.

=A0

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals. =A0This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contac= t them all. =A0Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approva= l process. Each instance is essentially anonymous, and thus approval processes would not be possible. =A0Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

=A0

Proposal:

What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients.=A0

=A0

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. Th= e first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

=A0

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment.=A0

=A0

Question: =A0What happens if the server does not support these new parameters and the client provides them? =A0The current draft already covers this in Section 3. =A0Specifically:

 The Client Registration Endp=
oint MUST ignore all parameters it does not understand.

=A0

Below are 3 options for the group to consider. =A0My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.<= /p>

=A0

Option 1 (2 parameters):

=A0

software_id<= /span>

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform.=A0For ex= ample, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code.<= /span>=A0The identifier=A0SHOULD NOT=A0change between software updates.=A0While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.=

=A0<= /p>

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.<= u>

=A0<= /p>

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

=A0<= /p>

software_ver= sion

RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.=

=A0

Option 2 (single parameter):

=A0

software_id<= /span>

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifier=A0SHOULD=A0change when the client software has changed such as with a version update or a platform change.<= /u>

=A0

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

=A0

[note: same editorial note as option 1]

=A0

Option 3 (no change):

=A0

In this option, no changes to the draft are made.=A0<= u>

=A0

Personal comment: =A0It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

=A0

= Phil

= =A0

= @independentid

phil.hunt@oracle.com

=A0



=A0

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= u>

=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


_______________________________________________
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
--14dae947303bedef7804dd568031-- From jricher@mitre.org Wed May 22 16:08:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1311E814E for ; Wed, 22 May 2013 16:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRnNOV5LTaWY for ; Wed, 22 May 2013 16:08:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3B11E814B for ; Wed, 22 May 2013 16:08:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7AD18265001E; Wed, 22 May 2013 19:08:41 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 623C11F067F; Wed, 22 May 2013 19:08:41 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 22 May 2013 19:08:41 -0400 Message-ID: <519D4FDA.6030302@mitre.org> Date: Wed, 22 May 2013 19:08:10 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nat Sakimura References: <68F766CA-A361-4590-94B5-73EC9065B695@oracle.com> <6E673A4C-5723-4C51-9C70-5AEF9B1F4A02@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677531A1@TK5EX14MBXC283.redmond.corp.microsoft.com> <519D3FFB.1060208@oracle.com> <0024047A-0164-4FBC-9636-262402B9F4EB@ve7jtb.com> <4764909A-B0FA-4B54-B07A-98B72266AD15@oracle.com> <519D4AEC.9040303@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060405010704080702060201" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2013 23:08:47 -0000 --------------060405010704080702060201 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit I think that's the crux of it: what, exactly, are the risks and the benefits of defining this as a single parameter now as opposed to part of a larger extension framework later? From my view, the risk to the protocol is fairly low (just another self-asserted client field). The risks to deployment are potentially high if servers start to use and trust the software_id as something they can trust to be anything meaningful on its own. I think we have to be very careful about avoiding that situation. The benefits, from my view, are equally low, though. On its own, it's just a single hook, something else to add in to the table of heuristics of client behavior over the network, and only if you care about such things. But it at least gives you the *chance* of doing something right. Extension protocols and enterprise servers are free to use it, extend it, further specify it as needed (indeed, as they are allowed to do without it being in the base spec -- but they might pick different names for it). So long as the field is properly limited (like what I've suggested in Phil's other thread), I'm neither particularly for nor against including it. -- Justin On 05/22/2013 06:58 PM, Nat Sakimura wrote: > It is not worth defining it now. It actually is harmful. > I can see developers start trusting the identifier and causing > problems later. > We should do it together with more thought out security measures. > > > 2013/5/23 Justin Richer > > > I agree with Prateek that redirect_uri isn't sufficient or > well-suited for this, but I also agree with John that software_id > on its own doesn't buy you a whole lot as a standalone field. It > could be a reasonable stepping stone to future, more > high-assurance work, but my question is then: is it really worth > it to define a field now when the real work will come later? Why > not just define the field then and make it fit better? > > -- Justin > > > On 05/22/2013 06:19 PM, Phil Hunt wrote: >> I dont see a big issue with a faked software_id. As i said it was >> a minimal proposal with the door open to stronger assertions. >> >> Rogue clients pretending to be something they are not is actually >> more evidence of a problem. In draft 10 you cant even do that. >> >> Phil >> >> On 2013-05-22, at 15:15, John Bradley > > wrote: >> >>> At the moment for Mobile devices and other native apps all we >>> have to reliably identify the app is the redirect_uri. >>> >>> The client_id is trivially faked in native apps. >>> >>> Yes in a well groomed enterprise trusting a self asserted >>> software identifier is nice but probably doesn't scale to the >>> real world. >>> >>> I have had discussions with MDM venders about how you might be >>> able to tie access tokens to a instance of software on a device >>> and determine if that software is allowed to be run by that user >>> on that device. >>> These are all much more complicated discussions than just >>> sticking another registration parameter on. >>> >>> I don't think this should block the basic dynamic registration >>> spec. App lifecycle needs a full spec, and additional >>> registration parameters can be added later if required. >>> >>> I am not insensitive to the problem. >>> >>> John B. >>> On 2013-05-22, at 6:00 PM, prateek mishra >>> > >>> wrote: >>> >>>> Well, I have to say that if anything seems poorly thought out, >>>> it would be a design with the following characteristics. >>>> >>>> [quote] >>>> We already have a software_id field and its named >>>> redirect_uris >>>> [\quote] >>>> >>>> This seems to violate the most basic principles of software >>>> design - overloading a field with meaning distinct from its >>>> primary purpose!! >>>> >>>> Phil has raised some substantive questions regarding client >>>> meta-data and the registration process. This information >>>> (software_id) is >>>> essential for identifying and disabling a class of clients that >>>> may have been found to have some security flaws, for example. >>>> This is a practical deployment issue that also impacts the >>>> security characteristics of OAuth. It should be taken into >>>> account in the client registration process. >>>> >>>> I hope we will take the time to discuss this issue carefully >>>> and not rush to finalize a specification which has NOT >>>> received much review >>>> from the OAuth community. >>>> >>>> - prateek >>>> >>>> >>>> >>>>> +1 >>>>> >>>>> We already have a software_id field and its named >>>>> redirect_uris. >>>>> >>>>> This doesnt seem well thought-out. We shouldnt try to jam it >>>>> into the spec at the last minute. >>>>> >>>>> The good news is that since the registration spec allows for >>>>> extensions, and the proposed fields are optional, these could >>>>> be added later as a non-breaking change by another spec if the >>>>> working group eventually decides to pursue a route like the >>>>> one proposed below. We dont have to do it now for this to >>>>> eventually come into being after deliberate consideration of a >>>>> complete specification including these features by the working >>>>> group. >>>>> >>>>> -- Mike >>>>> >>>>> *From:*oauth-bounces@ietf.org >>>>> [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley >>>>> *Sent:* Wednesday, May 22, 2013 2:21 PM >>>>> *To:* Phil Hunt >>>>> *Cc:* oauth@ietf.org WG >>>>> *Subject:* Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - >>>>> Fix to client_id definition issue (was: Client Instances) >>>>> >>>>> Phil, >>>>> >>>>> As I pointed out in the other thread, redirect_uri is the >>>>> thing that ties together the clients as that is the place the >>>>> responses need to go to so is hard to fake. >>>>> >>>>> All instances of a particular client application will share >>>>> the same redirect_uri across all instances. >>>>> >>>>> Adding a bunch of self asserted informational fields to the >>>>> base spec is not really helping. In a enterprise situation >>>>> where all the apps play nice it might be helpfull but the >>>>> reality is that you probably allready have a MDM that lets you >>>>> manage app versions. >>>>> >>>>> John >>>>> >>>>> On 2013-05-22, at 3:59 PM, Phil Hunt >>>> > wrote: >>>>> >>>>> >>>>> >>>>> I had a conversation with Justin yesterday to try to come to a >>>>> resolution regarding my concerns about client instances and >>>>> being able to associate client instances that are issued for >>>>> the same client software. I think we made some progress. >>>>> >>>>> */Background: /* >>>>> >>>>> In RFC6749, public clients, had a common client_id. Many >>>>> interpreted client_id as refering to the client application >>>>> software (e.g. the iPhone Facebook app). This is probably due >>>>> to the types of OAuth2 implementations that existed at the >>>>> time, where there was a single SP instance. Others have >>>>> interpreted that client_id does not refer to client >>>>> applications but rather ideally should point to instances of >>>>> software. To me this seems like equating a client_id to being >>>>> a user-id -- IOW the key part of a credential rather than a >>>>> client identifier. >>>>> >>>>> The new draft proposes that each instance be identified >>>>> separately. However it does so without keeping track of client >>>>> software that is the same. >>>>> >>>>> Never-the-less, I think both interpretations can be accommodated. >>>>> >>>>> Finally, in single instance services (like Facebook, Twitter, >>>>> etc), there was a natural registration and approval cycle >>>>> bound into the client_id issuance process. The developer was >>>>> able to talk to the single service provider and obtain a >>>>> client_id for all deployments. It wasn't stated, but the >>>>> client_id registration sites served a useful way to do >>>>> application approvals. This is a difficult problem to solve >>>>> when there are multiple instance of Resource API deployed in >>>>> multiple locations. The developer can't contact them all. >>>>> Further, because the current draft loses knowledge of how to >>>>> recognize that two instances of clients share the same >>>>> software, there's no ability to have an approval process. Each >>>>> instance is essentially anonymous, and thus approval processes >>>>> would not be possible. Though it does not require it, this >>>>> proposal makes it possible for service providers to recognize >>>>> new software and to have approval process. >>>>> >>>>> */Proposal:/* >>>>> >>>>> What I have worked out with Justin (and he may not yet fully >>>>> agree with everything) is a proposal that solves the problem >>>>> in an optional way that will not break existing clients. >>>>> >>>>> I also propose that optional version numbers also be >>>>> supported. This is useful to service providers who need to >>>>> know which client_ids are affected when certain software >>>>> clients and/or versions are deprecated. The re-introduction of >>>>> the renamed software_id further enables "local" registration >>>>> to occur. The first time a client tries to register, a service >>>>> provider could for example, choose to hold the registration to >>>>> obtain administrative approval. >>>>> >>>>> The solution here is not intended to provide software >>>>> "authentication" or software verification. The solution simply >>>>> allows service providers to make pragmatic decisions about >>>>> sets of clients that typically work the same way in a change >>>>> managed environment. >>>>> >>>>> Question: What happens if the server does not support these >>>>> new parameters and the client provides them? The current >>>>> draft already covers this in Section 3. Specifically: >>>>> >>>>> The Client Registration Endpoint MUST ignore all parameters it does not understand. >>>>> >>>>> Below are 3 options for the group to consider. My >>>>> recommendation is for option 1. My concern is option 2 will >>>>> lead to complexity because clients and service providers will >>>>> attempt to encode versions and software identifiers into one >>>>> field. I would rather keep this to simple UUIDs for most cases. >>>>> >>>>> *Option 1 (2 parameters):* >>>>> >>>>> software_id >>>>> >>>>> This value MAY be required by registration endpoints. The >>>>> value MAY be a unique identifier (UUID) self-assigned by a the >>>>> client application developer, or it MAY be an assertion. The >>>>> value SHOULD be the same across all instances of a client on >>>>> an application platform. For example, software used in a >>>>> mobile phone should be considered as different from a web >>>>> server implementation though it may share the same code.The >>>>> identifier *SHOULD NOT *change between software updates. While >>>>> a client application MAY be issued multiple client_id's and >>>>> client credentials over its deployment lifecycle, the >>>>> software_id SHOULD NOT change. >>>>> >>>>> Signed assertions MAY be used as software identifiers to allow >>>>> different dynamic registration end-points to recognize >>>>> approval from a common issuer (for example in cases where the >>>>> resource API released by a single publisher but deployed in >>>>> many different domains). The decision to use assertions and >>>>> the method by which developers know how to obtain assertions >>>>> is out of scope for this specification. >>>>> >>>>> [editorial note: some current deployments are using temporary >>>>> client credential assertions for this purpose. I propose to >>>>> standardize this in this field since an assertion would server >>>>> the same purpose as a UUID only providing third party signing >>>>> and other claims. I am concerned that passing a client >>>>> assertion for this purpose creates complexity in client >>>>> authentication processing - though obviously Justin has it >>>>> working] >>>>> >>>>> software_version >>>>> >>>>> RECOMMENDED. A version indicates a client developer chosen >>>>> version number. The identifier SHOULD BE the same across all >>>>> copies of client software. The version number SHOULD change >>>>> between different client updates. The intention is that >>>>> Service Providers MAY perform equality matching with >>>>> software_id to sub-select groups of clients of a particular >>>>> software version. >>>>> >>>>> *Option 2 (single parameter):* >>>>> >>>>> software_id >>>>> >>>>> This value MAY be required by registration endpoints. The >>>>> value MAY be a unique identifier (UUID) self-assigned by a the >>>>> client application developer, or it MAY be an assertion. The >>>>> value SHOULD be the same across all instances of a client on >>>>> an application platform. For example, software used in a >>>>> mobile phone should be considered as different from a web >>>>> server implementation though it may share the same code. The >>>>> identifier *SHOULD* change when the client software has >>>>> changed such as with a version update or a platform change. >>>>> >>>>> Signed assertions MAY be used as software identifiers to allow >>>>> different dynamic registration end-points to recognize >>>>> approval from a common issuer (for example in cases where the >>>>> resource API released by a single publisher but deployed in >>>>> many different domains). The decision to use assertions and >>>>> the method by which developers know how to obtain assertions >>>>> is out of scope for this specification. >>>>> >>>>> [note: same editorial note as option 1] >>>>> >>>>> *Option 3 (no change):* >>>>> >>>>> In this option, no changes to the draft are made. >>>>> >>>>> Personal comment: It has been proposed by several on the list >>>>> that another extension draft be written for these features as >>>>> an extension to the dynamic registration draft. In my opinion, >>>>> such a draft would be very small in size without clear reason >>>>> for separation. My feeling is that some technical >>>>> justification for keeping these features separated will likely >>>>> be needed. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> >> _______________________________________________ >> OAuth mailing 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 --------------060405010704080702060201 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit I think that's the crux of it: what, exactly, are the risks and the benefits of defining this as a single parameter now as opposed to part of a larger extension framework later?

From my view, the risk to the protocol is fairly low (just another self-asserted client field). The risks to deployment are potentially high if servers start to use and trust the software_id as something they can trust to be anything meaningful on its own. I think we have to be very careful about avoiding that situation.

The benefits, from my view, are equally low, though. On its own, it's just a single hook, something else to add in to the table of heuristics of client behavior over the network, and only if you care about such things. But it at least gives you the *chance* of doing something right.

Extension protocols and enterprise servers are free to use it, extend it, further specify it as needed (indeed, as they are allowed to do without it being in the base spec -- but they might pick different names for it).

So long as the field is properly limited (like what I've suggested in Phil's other thread), I'm neither particularly for nor against including it.

-- Justin

On 05/22/2013 06:58 PM, Nat Sakimura wrote:
It is not worth defining it now. It actually is harmful.
I can see developers start trusting the identifier and causing problems later.
We should do it together with more thought out security measures.


2013/5/23 Justin Richer <jricher@mitre.org>
I agree with Prateek that redirect_uri isn't sufficient or well-suited for this, but I also agree with John that software_id on its own doesn't buy you a whole lot as a standalone field. It could be a reasonable stepping stone to future, more high-assurance work, but my question is then: is it really worth it to define a field now when the real work will come later? Why not just define the field then and make it fit better?

-- Justin


On 05/22/2013 06:19 PM, Phil Hunt wrote:
I dont see a big issue with a faked software_id. As i said it was a minimal proposal with the door open to stronger assertions.

Rogue clients pretending to be something they are not is actually more evidence of a problem. In draft 10 you cant even do that.

Phil

On 2013-05-22, at 15:15, John Bradley <ve7jtb@ve7jtb.com> wrote:

At the moment for Mobile devices and other native apps all we have to reliably identify the app is the redirect_uri.

The client_id is trivially faked in native apps.

Yes in a well groomed enterprise trusting a self asserted software identifier is nice but probably doesn't scale to the real world.

I have had discussions with MDM venders about how you might be able to tie access tokens to a instance of software on a device and determine if that software is allowed to be run by that user on that device.
These are all much more complicated discussions than just sticking another registration parameter on.

I don't think this should block the basic dynamic registration spec. App lifecycle needs a full spec, and additional registration parameters can be added later if required.

I am not insensitive to the problem.

John B.
On 2013-05-22, at 6:00 PM, prateek mishra <prateek.mishra@oracle.com> wrote:

Well, I have to say that if anything seems poorly thought out, it would be a design with the following characteristics.

[quote]
We already have a software_id field and its named redirect_uris
[\quote]

This seems to violate the most basic principles of software design - overloading a field with meaning distinct from its primary purpose!!

Phil has raised some substantive questions regarding client meta-data and the registration process. This information (software_id) is
essential for identifying and disabling a class of clients that may have been found to have some security flaws, for example.
This is a practical deployment issue that also impacts the security characteristics of OAuth. It should be taken into account in the client registration process.

I hope we will take the time to discuss this issue carefully and not rush to finalize a specification which has NOT received much review
from the OAuth community.

- prateek



+1

We already have a software_id field and its named redirect_uris.

This doesnt seem well thought-out. We shouldnt try to jam it into the spec at the last minute.

The good news is that since the registration spec allows for extensions, and the proposed fields are optional, these could be added later as a non-breaking change by another spec if the working group eventually decides to pursue a route like the one proposed below. We dont have to do it now for this to eventually come into being after deliberate consideration of a complete specification including these features by the working group.

-- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 22, 2013 2:21 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Proposed resolution - Dynamic Reg - Fix to client_id definition issue (was: Client Instances)

Phil,

As I pointed out in the other thread, redirect_uri is the thing that ties together the clients as that is the place the responses need to go to so is hard to fake.

All instances of a particular client application will share the same redirect_uri across all instances.

Adding a bunch of self asserted informational fields to the base spec is not really helping. In a enterprise situation where all the apps play nice it might be helpfull but the reality is that you probably allready have a MDM that lets you manage app versions.

John

On 2013-05-22, at 3:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I had a conversation with Justin yesterday to try to come to a resolution regarding my concerns about client instances and being able to associate client instances that are issued for the same client software. I think we made some progress.

Background:

In RFC6749, public clients, had a common client_id. Many interpreted client_id as refering to the client application software (e.g. the iPhone Facebook app). This is probably due to the types of OAuth2 implementations that existed at the time, where there was a single SP instance. Others have interpreted that client_id does not refer to client applications but rather ideally should point to instances of software. To me this seems like equating a client_id to being a user-id -- IOW the key part of a credential rather than a client identifier.

The new draft proposes that each instance be identified separately. However it does so without keeping track of client software that is the same.

Never-the-less, I think both interpretations can be accommodated.

Finally, in single instance services (like Facebook, Twitter, etc), there was a natural registration and approval cycle bound into the client_id issuance process. The developer was able to talk to the single service provider and obtain a client_id for all deployments. It wasn't stated, but the client_id registration sites served a useful way to do application approvals. This is a difficult problem to solve when there are multiple instance of Resource API deployed in multiple locations. The developer can't contact them all. Further, because the current draft loses knowledge of how to recognize that two instances of clients share the same software, there's no ability to have an approval process. Each instance is essentially anonymous, and thus approval processes would not be possible. Though it does not require it, this proposal makes it possible for service providers to recognize new software and to have approval process.

Proposal:

What I have worked out with Justin (and he may not yet fully agree with everything) is a proposal that solves the problem in an optional way that will not break existing clients.

I also propose that optional version numbers also be supported. This is useful to service providers who need to know which client_ids are affected when certain software clients and/or versions are deprecated. The re-introduction of the renamed software_id further enables "local" registration to occur. The first time a client tries to register, a service provider could for example, choose to hold the registration to obtain administrative approval.

The solution here is not intended to provide software "authentication" or software verification. The solution simply allows service providers to make pragmatic decisions about sets of clients that typically work the same way in a change managed environment.

Question: What happens if the server does not support these new parameters and the client provides them? The current draft already covers this in Section 3. Specifically:

 The Client Registration Endpoint MUST ignore all parameters it does not understand.

Below are 3 options for the group to consider. My recommendation is for option 1. My concern is option 2 will lead to complexity because clients and service providers will attempt to encode versions and software identifiers into one field. I would rather keep this to simple UUIDs for most cases.

Option 1 (2 parameters):

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform.For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code.The identifierSHOULD NOTchange between software updates.While a client application MAY be issued multiple client_id's and client credentials over its deployment lifecycle, the software_id SHOULD NOT change.

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[editorial note: some current deployments are using temporary client credential assertions for this purpose. I propose to standardize this in this field since an assertion would server the same purpose as a UUID only providing third party signing and other claims. I am concerned that passing a client assertion for this purpose creates complexity in client authentication processing - though obviously Justin has it working]

software_version

RECOMMENDED. A version indicates a client developer chosen version number. The identifier SHOULD BE the same across all copies of client software. The version number SHOULD change between different client updates. The intention is that Service Providers MAY perform equality matching with software_id to sub-select groups of clients of a particular software version.

Option 2 (single parameter):

software_id

This value MAY be required by registration endpoints. The value MAY be a unique identifier (UUID) self-assigned by a the client application developer, or it MAY be an assertion. The value SHOULD be the same across all instances of a client on an application platform. For example, software used in a mobile phone should be considered as different from a web server implementation though it may share the same code. The identifierSHOULDchange when the client software has changed such as with a version update or a platform change.

Signed assertions MAY be used as software identifiers to allow different dynamic registration end-points to recognize approval from a common issuer (for example in cases where the resource API released by a single publisher but deployed in many different domains). The decision to use assertions and the method by which developers know how to obtain assertions is out of scope for this specification.

[note: same editorial note as option 1]

Option 3 (no change):

In this option, no changes to the draft are made.

Personal comment: It has been proposed by several on the list that another extension draft be written for these features as an extension to the dynamic registration draft. In my opinion, such a draft would be very small in size without clear reason for separation. My feeling is that some technical justification for keeping these features separated will likely be needed.

_______________________________________________
OAuth mailing 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

--------------060405010704080702060201-- From roland.hedberg@adm.umu.se Thu May 23 07:28:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA9921F9610 for ; Thu, 23 May 2013 07:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gABvdrYVZEa8 for ; Thu, 23 May 2013 07:28:02 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch1.ad.umu.se [130.239.1.246]) by ietfa.amsl.com (Postfix) with ESMTP id E18A821F939E for ; Thu, 23 May 2013 07:28:00 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.2.46]) by UMDAC-CH1.ad.umu.se ([130.239.1.246]) with mapi; Thu, 23 May 2013 16:27:54 +0200 From: Roland Hedberg To: Phil Hunt Date: Thu, 23 May 2013 16:27:57 +0200 Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: Ac5XwbYysT5xjaBTSSedJjCKo4d3dg== Message-ID: <9599F577-860E-4864-9DF2-4DA7EF2E2E04@adm.umu.se> References: <519D0C4D.60002@mitre.org> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 14:28:06 -0000 As an implementor like Justin, I see no problem with changing "expires_at" = and "issued_at" to the values proposed below. It's a minor code change and I don't have a large deployment to deal with. I also agree with Justin and Phil about "token_endpoint_auth_method". 22 maj 2013 kl. 20:34 skrev Phil Hunt : > +1 >=20 > I also agree with Justin's comment on token_endpoint_auth_method. Never-t= he-less, I did want to pass along the feedback that some were confused. >=20 > The expires_at, issued_at thing though is particularly confusing (though = the text may be clear) and is a higher priority issue in my opinion. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-22, at 11:19 AM, Justin Richer wrote: >=20 >> Speaking as an implementor, I'm actually in favor of changing "expires_a= t" and "issued_at" to the values proposed below. It would require some mino= r code changes on my end, but the impact would be minimal, and I think that= the new names are *much* more clear to new developers. I think it will sav= e us a lot of questions and headaches going forward. I believe that changin= g it now will have minimal impact on any deployed and running code (there a= re no large-scale services that I am aware of), and it will make things cle= arer. So I vote for "B" for #1 and #2. >>=20 >> I believe "token_endpoint_auth_method" is sufficient as is, since the cl= ient is the only thing that authenticates to the token endpoint.=20 >>=20 >>=20 >> [[ Note: As an editor, I don't believe it's really in my power to make t= hat change unless there's support in the working group for making it. I rea= lly want more feedback from people, with explanation if you can. ]] >>=20 >> -- Justin >>=20 >>=20 >> On 05/20/2013 11:09 AM, Justin Richer wrote: >>> Phil Hunt's review of the Dynamic Registration specification has raised= a couple of issues that I felt were getting buried by the larger discussio= n (which I still strongly encourage others to jump in to). Namely, Phil has= suggested a couple of syntax changes to the names of several parameters.=20 >>>=20 >>>=20 >>> 1) expires_at -> client_secret_expires_at >>> 2) issued_at -> client_id_issued_at >>> 3) token_endpoint_auth_method -> token_endpoint_client_auth_method >>>=20 >>>=20 >>> I'd like to get a feeling, especially from developers who have deployed= this draft spec, what we ought to do for each of these: >>>=20 >>> A) Keep the parameter names as-is >>> B) Adopt the new names as above >>> C) Adopt a new name that I will specify >>>=20 >>> In all cases, clarifying text will be added to the parameter *definitio= ns* so that it's more clear to people reading the spec what each piec= e does. Speaking as the editor: "A" is the default as far as I'm concerned,= since we shouldn't change syntax without very good reason to do so. That s= aid, if it's going to be better for developers with the new parameter names= , I am open to fixing them now. >>>=20 >>> Naming things is hard. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>>=20 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Roland "Education is the path from cocky ignorance to miserable uncertainty.=94 - = Mark Twain From edmundjay@sbcglobal.net Thu May 23 07:48:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E7A21F969E for ; Thu, 23 May 2013 07:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKjQXNIwE2P2 for ; Thu, 23 May 2013 07:48:50 -0700 (PDT) Received: from nm12-vm0.access.bullet.mail.mud.yahoo.com (nm12-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE721F9692 for ; Thu, 23 May 2013 07:48:48 -0700 (PDT) Received: from [66.94.237.194] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 23 May 2013 14:48:48 -0000 Received: from [66.94.237.124] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 23 May 2013 14:48:48 -0000 Received: from [127.0.0.1] by omp1029.access.mail.mud.yahoo.com with NNFMP; 23 May 2013 14:48:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 684683.17382.bm@omp1029.access.mail.mud.yahoo.com Received: (qmail 46261 invoked by uid 60001); 23 May 2013 14:48:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1369320528; bh=OOcytzgeptkp5z+oJn/vbD4QM4SzhIlTZ+7zMYApiTY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=izW9HcuWDR9OjPKUYXGznnqxbnUXZlC3eQL1yZmmntweCDe0xcugR3pAs3qzaDVmPpw0qGwQ99wWoITIGZ3pLjNfL0JNYrwumbXLEJksvjxhSnH4WQrZVUYhWGJQXZbiZ5aTPSCeOKDBsNdzIqgaSw/DAvJpJKaeYT6aE8K587k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m7MuOs1RGc7nPSSCsAMitIaFEyGB7/js+2grJ9w37PP3kdgIZBIkOYWvI9jQAx8yjzEJ2N/7Uq0pM8XmFlqd3HTPmNnS2mBBSae1E1/1auGJMrrwbHQ8OnyLHCaAg+P5JmdOvgEVraZt0dPQv40dX2EnPovijK7knDvt8BFK2R4=; X-YMail-OSG: 1zRydzoVM1kyg_oCWoaeSdiYfVwR1Tp5cM.rof0M.hFTwLw 0dsD.3BmrniXgFlkZ8Jzp Received: from [70.36.254.42] by web184406.mail.bf1.yahoo.com via HTTP; Thu, 23 May 2013 07:48:47 PDT X-Rocket-MIMEInfo: 002.001, SSdtIE9LIHdpdGggY2hhbmdpbmcgZXhwaXJlc19hdCBhbmQgaXNzdWVkX2F0IHdoaWxlIGtlZXBpbmcgCnRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIHRoZSBzYW1lLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBSb2xhbmQgSGVkYmVyZyA8cm9sYW5kLmhlZGJlcmdAYWRtLnVtdS5zZT4KVG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20.CkNjOiAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4KU2VudDogVGh1LCBNYXkgMjMsIDIwMTMgNzoyODoyMiABMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/729 YahooMailWebService/0.8.144.546 References: <519D0C4D.60002@mitre.org> <9599F577-860E-4864-9DF2-4DA7EF2E2E04@adm.umu.se> Message-ID: <1369320527.26231.YahooMailRC@web184406.mail.bf1.yahoo.com> Date: Thu, 23 May 2013 07:48:47 -0700 (PDT) From: Edmund Jay To: Roland Hedberg , Phil Hunt In-Reply-To: <9599F577-860E-4864-9DF2-4DA7EF2E2E04@adm.umu.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1789658926-1844771003-1369320527=:26231" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 14:48:56 -0000 --1789658926-1844771003-1369320527=:26231 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm OK with changing expires_at and issued_at while keeping =0Atoken_endpoi= nt_auth_method the same.=0A=0A=0A=0A________________________________=0AFrom= : Roland Hedberg =0ATo: Phil Hunt =0ACc: "oauth@ietf.org" =0ASent: Thu, May 23, 2013 = 7:28:22 AM=0ASubject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Reg= istration=0A=0AAs an implementor like Justin, I see no problem with changin= g "expires_at" and =0A"issued_at" to the values proposed below.=0AIt's a mi= nor code change and I don't have a large deployment to deal with.=0A=0AI al= so agree with Justin and Phil about "token_endpoint_auth_method".=0A=0A22 m= aj 2013 kl. 20:34 skrev Phil Hunt :=0A=0A> +1=0A> =0A= > I also agree with Justin's comment on token_endpoint_auth_method. =0A>Nev= er-the-less, I did want to pass along the feedback that some were confused.= =0A> =0A> The expires_at, issued_at thing though is particularly confusing = (though the =0A>text may be clear) and is a higher priority issue in my opi= nion.=0A> =0A> Phil=0A> =0A> @independentid=0A> www.independentid.com=0A> p= hil.hunt@oracle.com=0A> =0A> =0A> =0A> =0A> =0A> On 2013-05-22, at 11:19 AM= , Justin Richer wrote:=0A> =0A>> Speaking as an implementor, I'm actually i= n favor of changing "expires_at" and =0A>>"issued_at" to the values propose= d below. It would require some minor code =0A>>changes on my end, but the i= mpact would be minimal, and I think that the new =0A>>names are *much* more= clear to new developers. I think it will save us a lot of =0A>>questions a= nd headaches going forward. I believe that changing it now will have =0A>>m= inimal impact on any deployed and running code (there are no large-scale = =0A>>services that I am aware of), and it will make things clearer. So I vo= te for "B" =0A>>for #1 and #2.=0A>> =0A>> I believe "token_endpoint_auth_me= thod" is sufficient as is, since the client is =0A>>the only thing that aut= henticates to the token endpoint. =0A>>=0A>> =0A>> =0A>> [[ Note: As an edi= tor, I don't believe it's really in my power to make that =0A>>change unles= s there's support in the working group for making it. I really want =0A>>mo= re feedback from people, with explanation if you can. ]]=0A>> =0A>> -- Jus= tin=0A>> =0A>> =0A>> On 05/20/2013 11:09 AM, Justin Richer wrote:=0A>>> Phi= l Hunt's review of the Dynamic Registration specification has raised a =0A>= >>couple of issues that I felt were getting buried by the larger discussion= (which =0A>>>I still strongly encourage others to jump in to). Namely, Phi= l has suggested a =0A>>>couple of syntax changes to the names of several pa= rameters. =0A>>>=0A>>> =0A>>> =0A>>> 1) expires_at -> client_secret_expires= _at=0A>>> 2) issued_at -> client_id_issued_at=0A>>> 3) token_endpoint_auth_= method -> token_endpoint_client_auth_method=0A>>> =0A>>> =0A>>> I'd like to= get a feeling, especially from developers who have deployed this =0A>>>dra= ft spec, what we ought to do for each of these:=0A>>> =0A>>> A) Keep the p= arameter names as-is=0A>>> B) Adopt the new names as above=0A>>> C) Adopt= a new name that I will specify=0A>>> =0A>>> In all cases, clarifying text = will be added to the parameter *definitions* so =0A>>>that it's more clear = to people reading the spec what each piece does. =0A>>>Speaking as th= e editor: "A" is the default as far as I'm concerned, since we =0A>>>should= n't change syntax without very good reason to do so. That said, if it's =0A= >>>going to be better for developers with the new parameter names, I am ope= n to =0A>>>fixing them now.=0A>>> =0A>>> Naming things is hard.=0A>>> =0A>>= > -- Justin=0A>>> =0A>>> =0A>>> __________________________________________= _____=0A>>> OAuth mailing list=0A>>> =0A>>> OAuth@ietf.org=0A>>> https://ww= w.ietf.org/mailman/listinfo/oauth=0A>> =0A>> ______________________________= _________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://= www.ietf.org/mailman/listinfo/oauth=0A> =0A> ______________________________= _________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www= .ietf.org/mailman/listinfo/oauth=0A=0A-- Roland=0A"Education is the path fr= om cocky ignorance to miserable uncertainty.=E2=80=9D - Mark =0ATwain=0A=0A= =0A=0A=0A_______________________________________________=0AOAuth mailing li= st=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A --1789658926-1844771003-1369320527=:26231 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm OK with changing expires_at and issued_at while keeping t= oken_endpoint_auth_method the same.

From: Roland H= edberg <roland.hedberg@adm.umu.se>
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "oauth@ietf.org" <oauth@ietf.o= rg>
Sent: Thu, May 2= 3, 2013 7:28:22 AM
Subject:= Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

As an implementor like Justin, I see no problem with changing "expires_at" and "= issued_at" to the values proposed below.
It's a minor code change and I = don't have a large deployment to deal with.

I also agree with Justin= and Phil about "token_endpoint_auth_method".

22 maj 2013 kl. 20:34 = skrev Phil Hunt <phil.hunt@oracle.com>:

> +1
&g= t;
> I also agree with Justin's comment on token_endpoint_auth_metho= d. Never-the-less, I did want to pass along the feedback that some were con= fused.
>
> The expires_at, issued_at thing though is particula= rly confusing (though the text may be clear) and is a higher priority issue= in my opinion.
>
> Phil
>
> @independentid
> www.ind= ependentid.com
> phil.hunt@oracle.com
>
= >
>
>
>
> On 2013-05-22, at 11:19 AM, Justin= Richer wrote:
>
>> Speaking as an implementor, I'm actuall= y in favor of changing "expires_at" and "issued_at" to the values proposed = below. It would require some minor code changes on my end, but the impact w= ould be minimal, and I think that the new names are *much* more clear to ne= w developers. I think it will save us a lot of questions and headaches goin= g forward. I believe that changing it now will have minimal impact on any d= eployed and running code (there are no large-scale services that I am aware= of), and it will make things clearer. So I vote for "B" for #1 and #2.
= >>
>> I believe "token_endpoint_auth_method" is sufficient = as is, since the client is the only thing that authenticates to the token e= ndpoint.
>>
>>
>> [[ Note: As an editor, I don't believe it's really in my power to make that change unless there's= support in the working group for making it. I really want more feedback fr= om people, with explanation if you can. ]]
>>
>>  -= - Justin
>>
>>
>> On 05/20/2013 11:09 AM, Just= in Richer wrote:
>>> Phil Hunt's review of the Dynamic Registra= tion specification has raised a couple of issues that I felt were getting b= uried by the larger discussion (which I still strongly encourage others to = jump in to). Namely, Phil has suggested a couple of syntax changes to the n= ames of several parameters.
>>>
>>>
>>&= gt; 1) expires_at -> client_secret_expires_at
>>> 2) issued_= at -> client_id_issued_at
>>> 3) token_endpoint_auth_method = -> token_endpoint_client_auth_method
>>>
>>> >>> I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:<= br>>>>
>>>  A) Keep the parameter names as-is>>>  B) Adopt the new names as above
>>>  C= ) Adopt a new name that I will specify
>>>
>>> In = all cases, clarifying text will be added to the parameter *definitions* so = that it's more clear to people reading the spec      what e= ach piece does. Speaking as the editor: "A" is the default as far as I'm co= ncerned, since we shouldn't change syntax without very good reason to do so= . That said, if it's going to be better for developers with the new paramet= er names, I am open to fixing them now.
>>>
>>> Na= ming things is hard.
>>>
>>>  -- Justin
&g= t;>>
>>>
>>> ______________________________= _________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/l= istinfo/oauth
>>
>> ________________________________= _______________
>> OAuth mailing list
>> OAuth@ietf.org
&= gt;> https://www.ietf.org/mailman/listinfo/oauth
>
> ___= ____________________________________________
> OAuth mailing list
= > OA= uth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
=
-- Roland
"Education is the path from cocky ignorance to miserable u= ncertainty.=E2=80=9D - Mark Twain




____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/oauth
=0A=0A= =0A
--1789658926-1844771003-1369320527=:26231-- From Adam.Lewis@motorolasolutions.com Thu May 23 10:34:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B421F9349 for ; Thu, 23 May 2013 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.261 X-Spam-Level: * X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[AWL=1.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgUXpgKWdNr5 for ; Thu, 23 May 2013 10:34:42 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D721F8C4C for ; Thu, 23 May 2013 10:24:02 -0700 (PDT) Received: from mail98-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; Thu, 23 May 2013 17:24:02 +0000 Received: from mail98-va3 (localhost [127.0.0.1]) by mail98-va3-R.bigfish.com (Postfix) with ESMTP id 213813C03FF for ; Thu, 23 May 2013 17:24:02 +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: -29 X-BigFish: VPS-29(zzbb2dI98dI9371Ic85fh1e83M1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1155h) Received-SPF: pass (mail98-va3: 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:BY2PRD0411HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail98-va3 (localhost.localdomain [127.0.0.1]) by mail98-va3 (MessageSwitch) id 1369329839396362_32221; Thu, 23 May 2013 17:23:59 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.247]) by mail98-va3.bigfish.com (Postfix) with ESMTP id 5940A2A006D for ; Thu, 23 May 2013 17:23:59 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 17:23:58 +0000 Received: from il06msg01.mot-solutions.com (il06vts03.mot.com [129.188.137.143]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4NHNw4W024158 for ; Thu, 23 May 2013 12:23:58 -0500 (CDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4NHNnFh024138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 May 2013 12:23:57 -0500 (CDT) Received: from mail27-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE017.bigfish.com (10.3.207.139) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 17:23:55 +0000 Received: from mail27-am1 (localhost [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id 0F9933A0091 for ; Thu, 23 May 2013 17:23:55 +0000 (UTC) Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1369329832711813_9905; Thu, 23 May 2013 17:23:52 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.242]) by mail27-am1.bigfish.com (Postfix) with ESMTP id A15FBC0049; Thu, 23 May 2013 17:23:52 +0000 (UTC) Received: from BY2PRD0411HT004.namprd04.prod.outlook.com (157.56.237.133) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 17:23:49 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.126]) by BY2PRD0411HT004.namprd04.prod.outlook.com ([10.255.128.39]) with mapi id 14.16.0311.000; Thu, 23 May 2013 17:23:36 +0000 From: Lewis Adam-CAL022 To: Justin Richer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Thread-Index: AQHOVxkrjcYEhpOC80K9Xhe0WMZcj5kTBWFA Date: Thu, 23 May 2013 17:23:35 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9659ADA34@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <519D0C4D.60002@mitre.org> In-Reply-To: <519D0C4D.60002@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.155.32] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9659ADA34BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$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 Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 17:34:59 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9659ADA34BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For what it's worth, I am in favor of making the changes to (1) and (2) and= leaving (3) unchanged. (1) and (2) are definitely confusing to me, as I w= ould normally have associated the issued and expiration times to the token.= (3) is obvious as it stands, and as other have mentioned, only clients au= thenticate to the endpoints, so adding client to the term doesn't add much = value. As mentioned, changing (1) and (2), it is not a difficult change, and anybo= dy implementing to drafts will obviously understand that things change befo= re getting RFC status. Best to fix things now, that's what the last call i= s for after all. -adam From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Wednesday, May 22, 2013 1:20 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration Speaking as an implementor, I'm actually in favor of changing "expires_at" = and "issued_at" to the values proposed below. It would require some minor c= ode changes on my end, but the impact would be minimal, and I think that th= e new names are *much* more clear to new developers. I think it will save u= s a lot of questions and headaches going forward. I believe that changing i= t now will have minimal impact on any deployed and running code (there are = no large-scale services that I am aware of), and it will make things cleare= r. So I vote for "B" for #1 and #2. I believe "token_endpoint_auth_method" is sufficient as is, since the clien= t is the only thing that authenticates to the token endpoint. [[ Note: As an editor, I don't believe it's really in my power to make that= change unless there's support in the working group for making it. I really= want more feedback from people, with explanation if you can. ]] -- Justin On 05/20/2013 11:09 AM, Justin Richer wrote: Phil Hunt's review of the Dynamic Registration specification has raised a c= ouple of issues that I felt were getting buried by the larger discussion (w= hich I still strongly encourage others to jump in to). Namely, Phil has sug= gested a couple of syntax changes to the names of several parameters. 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, especially from developers who have deployed thi= s draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter *definitions* = so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned, since we = shouldn't change syntax without very good reason to do so. That said, if it= 's going to be better for developers with the new parameter names, I am ope= n to fixing them now. Naming things is hard. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9659ADA34BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For what it’s worth= , I am in favor of making the changes to (1) and (2) and leaving (3) unchan= ged.  (1) and (2) are definitely confusing to me, as I would normally have associated the issued and expiration times to the token.  (3) is= obvious as it stands, and as other have mentioned, only clients authentica= te to the endpoints, so adding client to the term doesn’t add much va= lue. 

 <= /p>

As mentioned, changing (1= ) and (2), it is not a difficult change, and anybody implementing to drafts= will obviously understand that things change before getting RFC status.  Best to fix things now, that’s what the last call = is for after all. 

 <= /p>

-adam

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 1:20 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registrat= ion

 

Speaking as an implem= entor, I'm actually in favor of changing "expires_at" and "i= ssued_at" to the values proposed below. It would require some minor co= de changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I thin= k it will save us a lot of questions and headaches going forward. I believe= that changing it now will have minimal impact on any deployed and running = code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "= B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since= the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make t= hat change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. = ]]

 -- Justin

On 05/20/2013 11:09 AM, Justin Richer wrote:

Phil Hunt's review of the Dynamic Registration speci= fication has raised a couple of issues that I felt were getting buried by t= he larger discussion (which I still strongly encourage others to jump in to= ). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deplo= yed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* = so that it's more clear to people reading the spec what each piece does. Sp= eaking as the editor: "A" is the default as far as I'm concerned,= since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for devel= opers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin



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

 

--_000_59E470B10C4630419ED717AC79FCF9A9659ADA34BY2PRD0411MB441_-- From jricher@mitre.org Thu May 23 11:45:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE921F96CD for ; Thu, 23 May 2013 11:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMdzoSFbgOtQ for ; Thu, 23 May 2013 11:45:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B85C621F9021 for ; Thu, 23 May 2013 11:21:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D64F42260027; Thu, 23 May 2013 14:21:37 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 96EA51F0AFB; Thu, 23 May 2013 14:21:37 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 23 May 2013 14:21:37 -0400 Message-ID: <519E5E11.8090802@mitre.org> Date: Thu, 23 May 2013 14:21:05 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <519D0C4D.60002@mitre.org> <59E470B10C4630419ED717AC79FCF9A9659ADA34@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9659ADA34@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------020605090406010600000102" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 18:45:24 -0000 --------------020605090406010600000102 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thanks Adam (and others) for voicing your opinions on this. The OIDC working group has also been discussing this (since it would impact the registration draft there as well) and several of the members there have either changed to voicing support for the change or claiming ambivalence to it. As such, I am now seeing reasonable support for changing (1) and (2) to the proposed new names in the next draft, and leaving (3) as is. I will do so unless I hear strong objections. -- Justin On 05/23/2013 01:23 PM, Lewis Adam-CAL022 wrote: > > For what it's worth, I am in favor of making the changes to (1) and > (2) and leaving (3) unchanged. (1) and (2) are definitely confusing > to me, as I would normally have associated the issued and expiration > times to the token. (3) is obvious as it stands, and as other have > mentioned, only clients authenticate to the endpoints, so adding > client to the term doesn't add much value. > > As mentioned, changing (1) and (2), it is not a difficult change, and > anybody implementing to drafts will obviously understand that things > change before getting RFC status. Best to fix things now, that's what > the last call is for after all. > > -adam > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Wednesday, May 22, 2013 1:20 PM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration > > Speaking as an implementor, I'm actually in favor of changing > "expires_at" and "issued_at" to the values proposed below. It would > require some minor code changes on my end, but the impact would be > minimal, and I think that the new names are *much* more clear to new > developers. I think it will save us a lot of questions and headaches > going forward. I believe that changing it now will have minimal impact > on any deployed and running code (there are no large-scale services > that I am aware of), and it will make things clearer. So I vote for > "B" for #1 and #2. > > I believe "token_endpoint_auth_method" is sufficient as is, since the > client is the only thing that authenticates to the token endpoint. > > > *[[ Note: As an editor, I don't believe it's really in my power to > make that change unless there's support in the working group for > making it. I /really/ want more feedback from people, with explanation > if you can. ]] > * > -- Justin > > On 05/20/2013 11:09 AM, Justin Richer wrote: > > Phil Hunt's review of the Dynamic Registration specification has > raised a couple of issues that I felt were getting buried by the > larger discussion (which I still strongly encourage others to jump > in to). Namely, Phil has suggested a couple of syntax changes to > the names of several parameters. > > > 1) expires_at -> client_secret_expires_at > 2) issued_at -> client_id_issued_at > 3) token_endpoint_auth_method -> token_endpoint_client_auth_method > > > I'd like to get a feeling, *especially from developers* who have > deployed this draft spec, what we ought to do for each of these: > > A) Keep the parameter names as-is > B) Adopt the new names as above > C) Adopt a new name that I will specify > > In all cases, clarifying text will be added to the parameter > *definitions* so that it's more clear to people reading the spec > what each piece does. Speaking as the editor: "A" is the default > as far as I'm concerned, since we shouldn't change syntax without > very good reason to do so. That said, if it's going to be better > for developers with the new parameter names, I am open to fixing > them now. > > Naming things is hard. > > -- Justin > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --------------020605090406010600000102 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thanks Adam (and others) for voicing your opinions on this. The OIDC working group has also been discussing this (since it would impact the registration draft there as well) and several of the members there have either changed to voicing support for the change or claiming ambivalence to it.

As such, I am now seeing reasonable support for changing (1) and (2) to the proposed new names in the next draft, and leaving (3) as is. I will do so unless I hear strong objections.

 -- Justin

On 05/23/2013 01:23 PM, Lewis Adam-CAL022 wrote:

For what it’s worth, I am in favor of making the changes to (1) and (2) and leaving (3) unchanged.  (1) and (2) are definitely confusing to me, as I would normally have associated the issued and expiration times to the token.  (3) is obvious as it stands, and as other have mentioned, only clients authenticate to the endpoints, so adding client to the term doesn’t add much value. 

 

As mentioned, changing (1) and (2), it is not a difficult change, and anybody implementing to drafts will obviously understand that things change before getting RFC status.  Best to fix things now, that’s what the last call is for after all. 

 

-adam

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, May 22, 2013 1:20 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

Speaking as an implementor, I'm actually in favor of changing "expires_at" and "issued_at" to the values proposed below. It would require some minor code changes on my end, but the impact would be minimal, and I think that the new names are *much* more clear to new developers. I think it will save us a lot of questions and headaches going forward. I believe that changing it now will have minimal impact on any deployed and running code (there are no large-scale services that I am aware of), and it will make things clearer. So I vote for "B" for #1 and #2.

I believe "token_endpoint_auth_method" is sufficient as is, since the client is the only thing that authenticates to the token endpoint.


[[ Note: As an editor, I don't believe it's really in my power to make that change unless there's support in the working group for making it. I really want more feedback from people, with explanation if you can. ]]

 -- Justin

On 05/20/2013 11:09 AM, Justin Richer wrote:

Phil Hunt's review of the Dynamic Registration specification has raised a couple of issues that I felt were getting buried by the larger discussion (which I still strongly encourage others to jump in to). Namely, Phil has suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so that it's more clear to people reading the spec what each piece does. Speaking as the editor: "A" is the default as far as I'm concerned, since we shouldn't change syntax without very good reason to do so. That said, if it's going to be better for developers with the new parameter names, I am open to fixing them now.

Naming things is hard.

 -- Justin



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

 


--------------020605090406010600000102-- From donald.coffin@reminetworks.com Thu May 23 14:03:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167821F969F for ; Thu, 23 May 2013 14:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zYMzWb9muUc for ; Thu, 23 May 2013 14:03:41 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id E16CE21F86AE for ; Thu, 23 May 2013 13:22:13 -0700 (PDT) Received: (qmail 22861 invoked by uid 0); 23 May 2013 20:21:50 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy12.bluehost.com with SMTP; 23 May 2013 20:21:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=zxV1yPaKaJAINipR70aN3qKPzPMgMziaaoXsZtnru1E=; b=YdWPpotS1sgO3lZ1lLsMsdt4HzOcFdQU7ixKjcLxFHG/JjL0eBHe4TKXlQiwFMaZsD28a+TQub8ENI9GC2A6vdxMjEZsOzU4FOYmHzttPUtQo/biPOiq5si52W7Lnc5Q; Received: from [68.4.207.246] (port=2054 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ufc1G-0007M9-Eg; Thu, 23 May 2013 14:21:50 -0600 From: "Donald F Coffin" To: "'Anthony Nadalin'" , "'Phil Hunt'" References: <519A3C9A.8060305@mitre.org> <9D2C4D6F-EBC0-4313-B3B1-5981A865A604@oracle.com> <519A4607.1030900@mitre.org> <519A6715.9040904@mitre.org> <148ab6ca581c49358e1ba8ecdbd791b3@BY2PR03MB041.namprd03.prod.outlook.com> <519D2BE4.6080303@mitre.org> <8ae4313deafe4397b0b312ef38dcf182@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: Date: Thu, 23 May 2013 13:20:28 -0700 Message-ID: <00f801ce57f2$f7d3ad30$e77b0790$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F9_01CE57B8.4B771F20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE6nq+xED23CN2RhNJBxWly11UkMwH8LM9SAe6i+LUCC+U8awGbnrkDAgf3EdICPStEZwGUK1tLAd/LEWwBueVLxAGpFsGimaUzFbA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 21:03:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F9_01CE57B8.4B771F20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The issue I have with not providing Dynamic Registration capability = within OAuth (as the current document proposes) is that to provide a = Dynamic Registration capability will then require the implementation of = an additional standard to provide such support. =20 =20 At the present time, I am responsible for integrating OAuth 2.0 into the = current NAESB REQ.21 -- Energy Service Provider Interface (ESPI) = standard, which will require the existing standard to be revised. The = last thing the OpenESPI working group needs is to also require the = implementation of another standard, such as OpenID, in order to = implement a feature (i.e. Application Registration) that is already in = the current specification. The impetus for the current OAuth 2.0 = integration is to revise the ESPI standard requirement to utilize OAuth = 1.0, which was deprecated with the release of RFC6749 (The OAuth 2.0 = Authorization Framework). =20 From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 Sent: Wednesday, May 22, 2013 3:48 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration =20 My mistake, was to say, We already have OpenID Connect doing dynamic = registration, I don=E2=80=99t think there is a need to force it into = OAuth. =20 =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Wednesday, May 22, 2013 3:16 PM To: Anthony Nadalin Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration =20 I'm having trouble understanding We already have OAuth doing dynamic registration, I don=E2=80=99t think = there is a need to force it into OAuth. =20 =20 I would be open to a scim dyn reg version. Particularly to discuss = instance metadata mgt which scim is good at and the credential = managemenr/bootstrap process as it pertains to oauth. Never-the-less = the overwhelming priority has been apparently to simply standardize oidc = and uma implementations as is. This I am not comfortable with but i can = live with if there is give and take.=20 =20 I feel the subject is well in charter and is an important issue due to = the life-cycle management issues behind clients and the need to make = public clients the security equiv. of confidential clients.=20 =20 Phil On 2013-05-22, at 14:22, Anthony Nadalin wrote: I totally disagree with your characterization of SCIM, while it can be = used from server to server (provision one system to another) it can also = be client to endpoint (initial provisioning and JIT provisioning). SCIM = is fairly simple (but can be complex), I also have concerns about SCIM = not being 100% restful but that does not stop us from using it. I also = agree that we should let OAuth do what it=E2=80=99s good at and = don=E2=80=99t try to force it into something that it=E2=80=99s not. We = already have OAuth doing dynamic registration, I don=E2=80=99t think = there is a need to force it into OAuth. =20 =20 From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Wednesday, May 22, 2013 1:35 PM To: Anthony Nadalin Cc: Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration =20 I'm not sure why you don't think it's in scope, it's in the working = group's charter: http://www.ietf.org/dyn/wg/charter/oauth-charter.html So ... it's definitely in scope, and has been for over a year and a = half. This is the tenth version of this document-- an IETF Working Group = document at that-- that's been posted to the group with every revision = and there has been significant conversation around it, especially over = the last six months since I took over the editor role. There are also a = handful of implementations of this, and while most of them are built to = do OpenID Connect or UMA (which are directly built on OAuth), I know = there are some that also do plain OAuth. (Not the least of which is one = that I have personally implemented and deployed.) SCIM doesn't solve client management particularly well, since it's made = for users more than anything. The usage model of SCIM is also quite = different -- it's really intended to be used between two servers to = transfer information, as opposed to handling self-asserted claims. I = understand that some implementations like UAA have done their static = registration using a SCIM profile, but it's not dynamic registration, = really. I think it's too much of a square-peg-round-hole problem, at = least with SCIM as it is today; so let SCIM do what it's good at, and = don't try to force it into something it's not. Furthermore, be careful not to conflate SCIM with REST. Ultimately, = Dynamic Registration was meant to be a fairly simple REST/JSON API that = would be easy to implement, especially for clients. Just because SCIM is = RESTful doesn't mean it's a good structure for other RESTful APIs. = Namely, I don't think the extra structure and hooks with SCIM really buy = you anything here, especially with the additions and changes you'd have = to make to SCIM. And finally, nobody to date has actually written a proposal that is even = remotely SCIM based.=20 -- Justin On 05/22/2013 02:39 PM, Anthony Nadalin wrote: So, I really don=E2=80=99t understand why dynamic registration is in = scope, I understand this relative to OpenID Connect but not OAuth, if = this is indeed in scope then I would have expected that the endpoint be = based upon SCIM and not something else like what has been done here.=20 =20 From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Monday, May 20, 2013 11:10 AM To: Anthony Nadalin Cc: Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration =20 Tony, can you be more specific? What needs to be changed in your = opinion? What text changes would you suggest? -- Justin On 05/20/2013 02:09 PM, Anthony Nadalin wrote: Agree =20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt Sent: Monday, May 20, 2013 9:42 AM To: Justin Richer Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration =20 This draft isn't ready for LC.=20 Phil On 2013-05-20, at 8:49, Justin Richer wrote: But also keep in mind that this is last-call, and that we don't really = want to encourage avoidable drastic changes at this stage.=20 -- Justin On 05/20/2013 11:21 AM, Phil Hunt wrote: Keep in mind there may be other changes coming.=20 =20 The issue is that new developers can't figure out what token is being = referred to.=20 Phil On 2013-05-20, at 8:09, Justin Richer wrote: Phil Hunt's review of the Dynamic Registration specification has raised = a couple of issues that I felt were getting buried by the larger = discussion (which I still strongly encourage others to jump in to). = Namely, Phil has suggested a couple of syntax changes to the names of = several parameters.=20 1) expires_at -> client_secret_expires_at 2) issued_at -> client_id_issued_at 3) token_endpoint_auth_method -> token_endpoint_client_auth_method I'd like to get a feeling, especially from developers who have deployed = this draft spec, what we ought to do for each of these: A) Keep the parameter names as-is B) Adopt the new names as above C) Adopt a new name that I will specify In all cases, clarifying text will be added to the parameter = *definitions* so that it's more clear to people reading the spec what = each piece does. Speaking as the editor: "A" is the default as far as = I'm concerned, since we shouldn't change syntax without very good reason = to do so. That said, if it's going to be better for developers with the = new parameter names, I am open to fixing them now. Naming things is hard. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 ------=_NextPart_000_00F9_01CE57B8.4B771F20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The issue I = have with not providing Dynamic Registration capability within OAuth (as = the current document proposes) is that to provide a Dynamic Registration = capability will then require the implementation of an additional = standard to provide such support.=C2=A0

 

At the present = time, I am responsible for integrating OAuth 2.0 into the current NAESB = REQ.21 -- Energy Service Provider Interface (ESPI) standard, which will = require the existing standard to be revised.=C2=A0 The last thing the = OpenESPI working group needs is to also require the implementation of = another standard, such as OpenID, in order to implement a feature (i.e. = Application Registration) that is already in the current = specification.=C2=A0 The impetus for the current OAuth 2.0 integration = is to revise the ESPI standard requirement to utilize OAuth 1.0, which = was deprecated with the release of RFC6749 (The OAuth 2.0 Authorization = Framework).

 

From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: = Wednesday, May 22, 2013 3:48 PM
To: Phil Hunt
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes = in Dynamic Registration

 

My mistake, was to say, We already have OpenID Connect doing dynamic = registration, I don=E2=80=99t think there is a need to force it into = OAuth.

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.com] =
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony = Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: = [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

I'm = having trouble understanding

We already have OAuth doing dynamic registration, I don=E2=80=99t = think there is a need to force it into OAuth.

 

 

I = would be open to a scim dyn reg version. Particularly to discuss = instance metadata mgt which scim is good at and the credential = managemenr/bootstrap process as it pertains to oauth. =  Never-the-less the overwhelming priority has been apparently to = simply standardize oidc and uma implementations as is. This I am not = comfortable with but i can live with if there is give and = take. 

 

I = feel the subject is well in charter and is an important issue due to the = life-cycle management issues behind clients and the need to make public = clients the security equiv. of confidential = clients. 

 

Phil


On 2013-05-22, at 14:22, Anthony = Nadalin <tonynad@microsoft.com> = wrote:

I totally disagree with your characterization of SCIM, while it can = be used from server to server (provision one system to another) it can = also be client to endpoint (initial provisioning and JIT provisioning). = SCIM is fairly simple (but can be complex), I also have concerns about = SCIM not being 100% restful but that does not stop us from using it. I = also agree that we should let OAuth do what it=E2=80=99s good at and = don=E2=80=99t try to force it into something that it=E2=80=99s not. We = already have OAuth doing dynamic registration, I don=E2=80=99t think = there is a need to force it into OAuth.

 

 

From: Justin Richer [mailto:jricher@mitre.org] =
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony = Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: = [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

I'm not sure why you don't think it's in = scope, it's in the working group's charter:

  http://www= .ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's = definitely in scope, and has been for over a year and a half. This is = the tenth version of this document-- an IETF Working Group document at = that-- that's been posted to the group with every revision and there has = been significant conversation around it, especially over the last six = months since I took over the editor role. There are also a handful of = implementations of this, and while most of them are built to do OpenID = Connect or UMA (which are directly built on OAuth), I know there are = some that also do plain OAuth. (Not the least of which is one that I = have personally implemented and deployed.)

SCIM doesn't solve = client management particularly well, since it's made for users more than = anything. The usage model of SCIM is also quite different -- it's really = intended to be used between two servers to transfer information, as = opposed to handling self-asserted claims. I understand that some = implementations like UAA have done their static registration using a = SCIM profile, but it's not dynamic registration, really. I think it's = too much of a square-peg-round-hole problem, at least with SCIM as it is = today; so let SCIM do what it's good at, and don't try to force it into = something it's not.

Furthermore, be careful not to conflate SCIM = with REST. Ultimately, Dynamic Registration was meant to be a fairly = simple REST/JSON API that would be easy to implement, especially for = clients. Just because SCIM is RESTful doesn't mean it's a good structure = for other RESTful APIs. Namely, I don't think the extra structure and = hooks with SCIM really buy you anything here, especially with the = additions and changes you'd have to make to SCIM.

And finally, = nobody to date has actually written a proposal that is even remotely = SCIM based.

 -- Justin

On 05/22/2013 02:39 PM, Anthony Nadalin = wrote:

So, I really don=E2=80=99t understand why dynamic registration is in = scope, I understand this relative to OpenID Connect but not OAuth, if = this is indeed in scope then I would have expected that the endpoint be = based upon SCIM and not something else like what has been done here. =

 

From: Justin Richer [mailto:jricher@mitre.org] =
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony = Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: = [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

Tony, can you be more specific? What = needs to be changed in your opinion? What text changes would you = suggest?

 -- Justin

On 05/20/2013 02:09 PM, Anthony Nadalin = wrote:

Agree

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 = AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Proposed Syntax Changes in Dynamic = Registration

 

This = draft isn't ready for LC. 

Phil


On 2013-05-20, at = 8:49, Justin Richer <jricher@mitre.org> = wrote:

But also keep in mind that this is = last-call, and that we don't really want to encourage avoidable drastic = changes at this stage.

 -- = Justin



On = 05/20/2013 11:21 AM, Phil Hunt wrote:

Keep in mind there may be other changes = coming. 

 

The issue is that new developers can't figure out what = token is being referred to. 


Phil


On 2013-05-20, at 8:09, Justin Richer = <jricher@mitre.org> = wrote:

Phil Hunt's review of the Dynamic Registration = specification has raised a couple of issues that I felt were getting = buried by the larger discussion (which I still strongly encourage others = to jump in to). Namely, Phil has suggested a couple of syntax changes to = the names of several parameters.


1) expires_at -> = client_secret_expires_at
2) issued_at -> client_id_issued_at
3) = token_endpoint_auth_method -> = token_endpoint_client_auth_method


I'd like to get a feeling, = especially from developers who have deployed this draft spec, = what we ought to do for each of these:

 A) Keep the = parameter names as-is
 B) Adopt the new names as = above
 C) Adopt a new name that I will specify

In all = cases, clarifying text will be added to the parameter *definitions* so = that it's more clear to people reading the spec what each piece does. = Speaking as the editor: "A" is the default as far as I'm = concerned, since we shouldn't change syntax without very good reason to = do so. That said, if it's going to be better for developers with the new = parameter names, I am open to fixing them now.

Naming things is = hard.

 -- = Justin

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

 

 

 

------=_NextPart_000_00F9_01CE57B8.4B771F20-- From Adam.Lewis@motorolasolutions.com Thu May 23 14:45:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F411921F9050 for ; Thu, 23 May 2013 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jMtIbADZ3Dt for ; Thu, 23 May 2013 14:44:48 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 67DB721F8FB3 for ; Thu, 23 May 2013 13:57:53 -0700 (PDT) Received: from mail137-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 20:57:52 +0000 Received: from mail137-ch1 (localhost [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id 0E96B40041C for ; Thu, 23 May 2013 20:57:52 +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(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1155h) Received-SPF: pass (mail137-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:BY2PRD0411HT002.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1369342669234396_21314; Thu, 23 May 2013 20:57:49 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id 377444A006D for ; Thu, 23 May 2013 20:57:49 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 20:57:48 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4NKvmKK008399 for ; Thu, 23 May 2013 16:57:48 -0400 (EDT) Received: from CO9EHSOBE041.bigfish.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4NKvl9e008391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 May 2013 16:57:47 -0400 (EDT) Received: from mail191-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE041.bigfish.com (10.236.130.104) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 20:57:46 +0000 Received: from mail191-co9 (localhost [127.0.0.1]) by mail191-co9-R.bigfish.com (Postfix) with ESMTP id EE55C980364 for ; Thu, 23 May 2013 20:57:46 +0000 (UTC) Received: from mail191-co9 (localhost.localdomain [127.0.0.1]) by mail191-co9 (MessageSwitch) id 1369342665108764_4996; Thu, 23 May 2013 20:57:45 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.237]) by mail191-co9.bigfish.com (Postfix) with ESMTP id 18D16B00068 for ; Thu, 23 May 2013 20:57:45 +0000 (UTC) Received: from BY2PRD0411HT002.namprd04.prod.outlook.com (157.56.237.133) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 20:57:38 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.126]) by BY2PRD0411HT002.namprd04.prod.outlook.com ([10.255.128.37]) with mapi id 14.16.0311.000; Thu, 23 May 2013 20:57:35 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Question/comments on draft-ietf-oauth-revocation-09 Thread-Index: Ac5X+CYvaJn0h+PTT7OHhi4wZMWSig== Date: Thu, 23 May 2013 20:57:34 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.155.32] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9659ADB40BY2PRD0411MB441_" 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] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2013 21:45:04 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9659ADB40BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 2.2 (Revocation Response) of draft-ietf-oauth-revocation-09 states: The authorization server responds with HTTP status code 200 if the token has been revoked sucessfully or if the client submitted an invalid token. The content of the response body does not matter as all information is conveyed in the response code. Am I just missing it, or does the draft not define the response code(s)? Also, it seems a bit strange to return a 200 in response to an invalid toke= n. 200 implies that the request has succeeded, which should not be the cas= e in an error condition (invalid token). Also (small typo) ... there should be two c's in successfully. adam --_000_59E470B10C4630419ED717AC79FCF9A9659ADB40BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 2.2 (Revocation Response) of draft-ietf-oaut= h-revocation-09 states:

 

The authorization server responds with HTTP status code 20= 0 if the

   token has been revoked sucessfully or if the = client submitted an

   invalid token.  The content of the respo= nse body does not matter as

   all information is conveyed in the response c= ode.

 

Am I just missing it, or does the draft not define t= he response code(s)?

 

Also, it seems a bit strange to return a 200 in resp= onse to an invalid token.  200 implies that the request has succeeded,= which should not be the case in an error condition (invalid token).

 

Also (small typo) … there should be two c̵= 7;s in successfully.

 

adam

--_000_59E470B10C4630419ED717AC79FCF9A9659ADB40BY2PRD0411MB441_-- From sberyozkin@gmail.com Fri May 24 03:07:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52921F9720 for ; Fri, 24 May 2013 03:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyYfs55cK83L for ; Fri, 24 May 2013 03:07:45 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2F21F9717 for ; Fri, 24 May 2013 03:07:37 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e1so2281558qcx.24 for ; Fri, 24 May 2013 03:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r7uyeapSwpkmv4DsPxuc3gW0/47b5oHuXTqRzEV6gx0=; b=zUQ+cemrjedJf65tycOzxmDix81v6CXVub6/op19ijZT65hQWta+OnnnWXuiIa7ya+ pcOrBDwCHAEb5kYB8i4Jo0URCIAJ/7iUGZisoH0o6+AV6Uzprv/DSpQgwMuJ9OqbnsPX BrJ9vAmCahxx9PidOgggrv1ldlBfvwOOjlkseCLxIYq8HZEz6A60y4d/+P8cTf13GV9V YV2cQhaEPoHJnGsFJ4Xy2aEK2VDpvd8WMJilRYUcbFDNUvmsS24BAJAJ5tn6Ff1MI/vd SamM27UwzqU08bK/hsA7Na5jwaZ+Q7cke/GpJxg4O044HyDWCmAhJEh3FPPEvlld7GHK Fv6g== X-Received: by 10.229.252.196 with SMTP id mx4mr3347314qcb.45.1369390056856; Fri, 24 May 2013 03:07:36 -0700 (PDT) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPSA id u5sm14297110qeu.6.2013.05.24.03.07.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 03:07:36 -0700 (PDT) Message-ID: <519F3BE6.7060805@gmail.com> Date: Fri, 24 May 2013 11:07:34 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: oauth@ietf.org References: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 10:07:47 -0000 Hi On 23/05/13 21:57, Lewis Adam-CAL022 wrote: > Hi, > > Section 2.2 (Revocation Response) of draft-ietf-oauth-revocation-09 states: > > The authorization server responds with HTTP status code 200 if the > > token has been revoked sucessfully or if the client submitted an > > invalid token. The content of the response body does not matter as > > all information is conveyed in the response code. > > Am I just missing it, or does the draft not define the response code(s)? > > Also, it seems a bit strange to return a 200 in response to an invalid > token. 200 implies that the request has succeeded, which should not be > the case in an error condition (invalid token). > As far as I recall it was done to prevent the rogue clients from figuring out where did they fail; I asked was it something that now should apply to other similar cases, but did not get any feedback. Cheers, Sergey > Also (small typo) there should be two cs in successfully. > > adam > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Fri May 24 06:02:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43F421F8F0F for ; Fri, 24 May 2013 06:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh5a5l6EHj34 for ; Fri, 24 May 2013 06:02:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E91D21F8F7A for ; Fri, 24 May 2013 06:02:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA6EA1F0647; Fri, 24 May 2013 09:02:37 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9DE4B1F0612; Fri, 24 May 2013 09:02:37 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Fri, 24 May 2013 09:02:37 -0400 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 Thread-Index: Ac5X+CYvaJn0h+PTT7OHhi4wZMWSigAj+NkAAAYdEoA= Date: Fri, 24 May 2013 13:02:37 +0000 Message-ID: <5B06352F-6B50-4857-A1B7-E7B0F3A1500D@mitre.org> References: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> <519F3BE6.7060805@gmail.com> In-Reply-To: <519F3BE6.7060805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97527E916F02904DB331C7C7444C9F44@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 13:02:43 -0000 Sergey has the correct interpretation -- it's to prevent a class of oracle = attacks. Think of it this way, if you go to revoke a token, and the token w= asn't there in the first place, the end result is the same: the token's not= there when you're done. So it's a 200 because the result is what you wante= d even if the state going in was wrong. -- Justin On May 24, 2013, at 6:07 AM, Sergey Beryozkin wrote: > Hi > On 23/05/13 21:57, Lewis Adam-CAL022 wrote: >> Hi, >>=20 >> Section 2.2 (Revocation Response) of draft-ietf-oauth-revocation-09 stat= es: >>=20 >> The authorization server responds with HTTP status code 200 if the >>=20 >> token has been revoked sucessfully or if the client submitted an >>=20 >> invalid token. The content of the response body does not matter as >>=20 >> all information is conveyed in the response code. >>=20 >> Am I just missing it, or does the draft not define the response code(s)? >>=20 >> Also, it seems a bit strange to return a 200 in response to an invalid >> token. 200 implies that the request has succeeded, which should not be >> the case in an error condition (invalid token). >>=20 > As far as I recall it was done to prevent the rogue clients from figuring= out where did they fail; I asked was it something that now should apply to= other similar cases, but did not get any feedback. >=20 > Cheers, Sergey >=20 >> Also (small typo) =85 there should be two c=92s in successfully. >>=20 >> adam >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Fri May 24 09:13:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019E021F8AF7 for ; Fri, 24 May 2013 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3d38jLtpdNq for ; Fri, 24 May 2013 09:13:05 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6187321F8976 for ; Fri, 24 May 2013 09:13:05 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 11so3191541vbe.5 for ; Fri, 24 May 2013 09:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GvyuayDf/cZwf4PrLNDlmKhb6zrL9zqllzfYTYiDmhY=; b=SxWlNOUcA8ZuvnZ1pzy/Di/mq7UYVXZB6IeaEE2UPbTuv0x8W+lratR20SS54FeW7V 5PdX6WObPkuuJcEvxrkl3GI0Q9CZjxB3H9wF+f1jeyj6XOwWHT0KLtUD7B1rnpWYIUEo ZxIEtkhmBzyPVAcWUaAaaJP5YGQSBWtK4NPeIC8Xw/lY0QpboVG12Qx60gf7diNbRVMi /ypxL+D/MvBZsjtGCoga2DIBsKUBfyoDPMvEzKZDHHgNFN12dsofa12U6HhmYH1ZmnQX p6CJbetVacreavptPGg+J91cnm5BuRKIa6t2uHXkJsEoNx0HFrrZbqlZ53CnUxLQwE6i FMNA== MIME-Version: 1.0 X-Received: by 10.52.233.34 with SMTP id tt2mr7581408vdc.70.1369411984690; Fri, 24 May 2013 09:13:04 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Fri, 24 May 2013 09:13:04 -0700 (PDT) In-Reply-To: <5B06352F-6B50-4857-A1B7-E7B0F3A1500D@mitre.org> References: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> <519F3BE6.7060805@gmail.com> <5B06352F-6B50-4857-A1B7-E7B0F3A1500D@mitre.org> Date: Fri, 24 May 2013 12:13:04 -0400 X-Google-Sender-Auth: -k2yRbu1ACPA5nD6yK_x9K_0d2s Message-ID: From: Barry Leiba To: "Richer, Justin P." Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 16:13:06 -0000 > Sergey has the correct interpretation -- it's to prevent a class of oracle attacks. > Think of it this way, if you go to revoke a token, and the token wasn't there in the > first place, the end result is the same: the token's not there when you're done. So > it's a 200 because the result is what you wanted even if the state going in was wrong. This highlights my point in my AD review: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ ...that this is *not* revocation. It's invalidation or surrender (requested by the bearer of the token) -- revocation would be an action by another party to invalidate a token without the bearer's involvement. The usual defense against the sorts of attacks you're talking about is to make the failure conditions indistinguishable -- not to make success indistinguishable from failure. That is, you have two responses, success and failure, but the failure response doesn't say why. What, specifically, is the attack you're trying to defend against here, any why is this the best approach to that attack? I can't see how a "please invalidate this token" request can in any way take advantage of a "no" response to mount an attack. It's possible that there really is a threat here and that this is the right way to handle it, but I'd like to see that explained. Barry, Applications AD From jricher@mitre.org Fri May 24 09:21:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AE21F8E6E for ; Fri, 24 May 2013 09:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY++uBBXhh+a for ; Fri, 24 May 2013 09:21:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA421F95FD for ; Fri, 24 May 2013 09:21:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 873231F0B40; Fri, 24 May 2013 12:21:46 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6B9F71F0B5D; Fri, 24 May 2013 12:21:46 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Fri, 24 May 2013 12:21:46 -0400 From: "Richer, Justin P." To: Barry Leiba Thread-Topic: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 Thread-Index: Ac5X+CYvaJn0h+PTT7OHhi4wZMWSigAj+NkAAAYdEoAABqbCAAAATEsA Date: Fri, 24 May 2013 16:21:37 +0000 Message-ID: <71F77B04-30B2-4328-88CE-63F61D5E4D76@mitre.org> References: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> <519F3BE6.7060805@gmail.com> <5B06352F-6B50-4857-A1B7-E7B0F3A1500D@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6074485E0CDDB6449383EA7D409760F8@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 16:21:52 -0000 As I recall, the argument was that without this, someone could just keep fi= shing at the token revocation endpoint for valid tokens. Though thinking ab= out it now, even if you did get a "token was valid" response, the token wou= ldn't be valid anymore and it wouldn't do you much good.=20 It's possible that "invalidation" is a better term for this, but is there a= n established semantic precedent for this distinction?=20 -- Justin On May 24, 2013, at 12:13 PM, Barry Leiba wrote: >> Sergey has the correct interpretation -- it's to prevent a class of orac= le attacks. >> Think of it this way, if you go to revoke a token, and the token wasn't = there in the >> first place, the end result is the same: the token's not there when you'= re done. So >> it's a 200 because the result is what you wanted even if the state going= in was wrong. >=20 > This highlights my point in my AD review: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ >=20 > ...that this is *not* revocation. It's invalidation or surrender > (requested by the bearer of the token) -- revocation would be an > action by another party to invalidate a token without the bearer's > involvement. >=20 > The usual defense against the sorts of attacks you're talking about is > to make the failure conditions indistinguishable -- not to make > success indistinguishable from failure. That is, you have two > responses, success and failure, but the failure response doesn't say > why. >=20 > What, specifically, is the attack you're trying to defend against > here, any why is this the best approach to that attack? I can't see > how a "please invalidate this token" request can in any way take > advantage of a "no" response to mount an attack. It's possible that > there really is a threat here and that this is the right way to handle > it, but I'd like to see that explained. >=20 > Barry, Applications AD From barryleiba.mailing.lists@gmail.com Fri May 24 11:07:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C1721F9673 for ; Fri, 24 May 2013 11:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.992 X-Spam-Level: X-Spam-Status: No, score=-101.992 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dkO7Svfl0a7 for ; Fri, 24 May 2013 11:07:52 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2808A21F93C4 for ; Fri, 24 May 2013 11:07:52 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id b10so3736488vea.3 for ; Fri, 24 May 2013 11:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TwB5k+c0Q4mi+lQPlJcGCCY2rRmCJESAAIH2Fabz954=; b=Dfktr75MP3eBY8d0dJ0X5gaO+0PCDVKwWa9MC5mAGhjP3kUEwHgWTMBcTt+KiqtoFH YrdQIn9QkpWzwE7ekrEUjCsegYjrKN7mk8XYbL6falBNb2+ogUtckQd8T3bzxSHAuiEv HU5o5epqIvnVExG8REeASSj4VYxMU99FpM/0ps+arnSzd8H2m6ajjl2MW6Gfrq1b2w9I +fn6hNvETRrr1wdTYEX7lFFPiRs8drCJg5Khu7RWQSfLz7cjXoCPjqKjhXSUAPRNfJ1i GrDvt9wh57v5krDvTZejL3qcIGf1BK2/BLPUYdybhqHu1wGNkfRVFrsD91XhGYknX0y8 V2sA== MIME-Version: 1.0 X-Received: by 10.52.233.34 with SMTP id tt2mr7849176vdc.70.1369418871553; Fri, 24 May 2013 11:07:51 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Fri, 24 May 2013 11:07:51 -0700 (PDT) In-Reply-To: <71F77B04-30B2-4328-88CE-63F61D5E4D76@mitre.org> References: <59E470B10C4630419ED717AC79FCF9A9659ADB40@BY2PRD0411MB441.namprd04.prod.outlook.com> <519F3BE6.7060805@gmail.com> <5B06352F-6B50-4857-A1B7-E7B0F3A1500D@mitre.org> <71F77B04-30B2-4328-88CE-63F61D5E4D76@mitre.org> Date: Fri, 24 May 2013 14:07:51 -0400 X-Google-Sender-Auth: I0ZxM_raP3X_v1TxJ5GgXn6jIWw Message-ID: From: Barry Leiba To: "Richer, Justin P." Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09 X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 18:07:52 -0000 > As I recall, the argument was that without this, someone could just keep fishing at the > token revocation endpoint for valid tokens. Though thinking about it now, even if you > did get a "token was valid" response, the token wouldn't be valid anymore and it wouldn't > do you much good. Right, exactly. > It's possible that "invalidation" is a better term for this, but is there an established semantic > precedent for this distinction? In English, yes (I don't know about in Computer): If I walk down to the motor vehicle office, hand them my driver's license, and say, "Here, take this and destroy it, please. I don't need it any more," then I will no longer have a valid driver's license... but *no one* would say that my license had been "revoked". If I'm caught driving drunk one too many times, and a judge says, "Take the bus from now on," and orders my driver's license revoked, that's a real English-language "revocation". Note the connotation that it's imposed on me by another party, not done at my request. This isn't a huge point, which is why I didn't mark it as a DISCUSS point, and I won't block the document if it's not changed. But I think it *should* be changed, and might cause confusion if it's not, especially if we ever do set up a true revocation protocol. Barry From phil.hunt@oracle.com Fri May 24 11:35:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471221F8930 for ; Fri, 24 May 2013 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JShxgI5PozrM for ; Fri, 24 May 2013 11:35:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E936A21F8BC0 for ; Fri, 24 May 2013 11:35:17 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4OIZAhX006619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 May 2013 18:35:11 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OIZBvr023585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 May 2013 18:35:11 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OIZALt005431 for ; Fri, 24 May 2013 18:35:10 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2013 11:35:10 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 24 May 2013 11:35:07 -0700 Message-Id: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 18:35:23 -0000 I wanted to bring out a quick discussion to ask the question if it makes = sense to support implicit clients in dynamic registration. By definition, implicit clients are unauthenticated. Therefore the only = purpose to register an implicit client is to obtain a client_id with a = particular AS instance. A few issues to consider: * Implicit clients typically run in browsers (javascript). Do we really = want each occurrence of a browser running a client to register? --> This could mean even the same browser running implicit flow = repeat times, would register repeatedly. --> If registration occurs per occurrence, what is the value? * What use cases typically occur for deployment against different AS and = Resource API instances? --> Eg. I can see a javascript component of a web site that uses a = corresponding resource API. So it may be possible that the javascript = and the resource API are running in the same domain. In this case, the = javascript code, though written as part of a shared = library/distribution, is still bound to a configured AS deployment. Is = it really dynamic? If this is the case, wouldn't an OOB registration = that updates the client_id in the deployment be better suited? --> Are there any examples of javascript clients that need to connect = to one or more AS servers on a truly dynamic basis? * Is there a DOS attack possible (even unintentionally) because implicit = clients will start to register frequently creating huge numbers of = client_ids that cause spin-off provisioning issues depending on how AS = registration, token, and policy systems are implemented? Apparently OIDC and UMA had these profiles supported before, but I'm = really trying to understand why implicit clients should have dynamic = registration support. Would appreciate any discussion on this. At = minimum, there are probably some security considerations we need to = think through and document. Thanks for your comments, Phil @independentid www.independentid.com phil.hunt@oracle.com From phil.hunt@oracle.com Fri May 24 13:03:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A1E21F854D for ; Fri, 24 May 2013 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyqhZUrrqO6H for ; Fri, 24 May 2013 13:03:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1C321F8629 for ; Fri, 24 May 2013 13:03:04 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4OK31en024946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 May 2013 20:03:02 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OK328g009541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 May 2013 20:03:02 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OK31RK014205 for ; Fri, 24 May 2013 20:03:01 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2013 13:03:01 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_AE5C78A6-366A-431E-8472-E77AC6B4EE1C" Date: Fri, 24 May 2013 13:02:58 -0700 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 20:03:11 -0000 --Apple-Mail=_AE5C78A6-366A-431E-8472-E77AC6B4EE1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been struggling with the concept of an initial client credential = covered in the current draft (rev 10): 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. The use case is very important since it opens the door for a way for = trusted entities to sign assertions that could be accepted by a set of = deployed authorization servers. For potential software API developers = (e.g. Oracle CRM), the developer could potentially register with Oracle = CRMs registration service manually, and obtain a signed assertion for = use in their client software. Upon initiating dynamic registration, the = client software would present the assertion as its initial authorization = in the HTTP Authorization header as Justin describes above. While this has worked in practice so far, I am concerned about this = assertion being presented in this way. The authentication header has special meaning to many servers. Depending = on implementation architecture, the authorization header will first be = intercepted by the authentication components in the server. Here's = where I get worried. 1. The assertion being presented is not an Authn assertion. There is no = "authentication session" tied to the assertion 2. The assertion isn't an authentication, but rather signed client = metadata. 3. The bearer assertion is easily copied. Thus the server should only = trust this as metadata 4. It ends up performing the same role as software_id While I think it is ok for existing implementations to continue with = this practice, I would prefer to standardize passing of client software = assertion metadata outside of the authentication channel in HTTP. A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic. My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this. If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_AE5C78A6-366A-431E-8472-E77AC6B4EE1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have been struggling with the concept of an initial client credential = covered in the current draft (rev 10):
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.

The use case is very important = since it opens the door for a way for trusted entities to sign = assertions that could be accepted by a set of deployed authorization = servers.  For potential software API developers (e.g. Oracle CRM), = the developer could potentially register with Oracle CRMs registration = service manually, and obtain a signed assertion for use in their client = software.  Upon initiating dynamic registration, the client = software would present the assertion as its initial authorization in the = HTTP Authorization header as Justin describes = above.

While this has worked in practice so = far, I am concerned about this assertion being presented in this = way.

The authentication header has special = meaning to many servers. Depending on implementation architecture, the = authorization header will first be intercepted by the authentication = components in the server.  Here's where I get = worried.

1.  The assertion being presented = is not an Authn assertion. There is no "authentication session" tied to = the assertion
2.  The assertion isn't an authentication, = but rather signed client metadata.
3.  The bearer = assertion is easily copied. Thus the server should only trust this as = metadata
4.  It ends up performing the same role as = software_id

While I think it is ok for = existing implementations to continue with this practice, I would = prefer to standardize passing of client software assertion metadata = outside of the authentication channel in = HTTP.

A further benefit is that the = registration endpoint authentication system only has to deal with = locally issued credentials. The logic for handling federated client meta = data can be isolated to the registration server = logic.

My feeling is that if we keep "initial = authorization credential" as being passed in the HTTP Authorization = header, then strict rules about the contents of the token and the = processing rules must be defined so that HTTP server security systems = can be extended to support this.

If we use = software_id, and indicate that it can accept a "software registration = assertion", we can be more flexible and minimize the processing rules we = have to declare in the draft. That said, if there is a case to adopt = strict rules here too, I am open.

Phil

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





= --Apple-Mail=_AE5C78A6-366A-431E-8472-E77AC6B4EE1C-- From jmandel@gmail.com Fri May 24 13:22:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1321E8087 for ; Fri, 24 May 2013 13:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+BY83pwP+mG for ; Fri, 24 May 2013 13:22:01 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F711E80FC for ; Fri, 24 May 2013 13:22:01 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id f4so6625854oah.24 for ; Fri, 24 May 2013 13:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Lgltjlq4vxHRH1Y+Vnf/6T3AdAKNcp//gQgnsnophmY=; b=f6rXmFjvAlWxHwrI/taqwopEiyTYPGCbPePZFlOn/Qbkkq0jDQmw+BBUPEm7ghuACZ abI3xb4FGLntYuY9grv9AVKvvVIpez4lfqMUA33L8vECBLn3x38dD7e79p1f11CqQHY/ XeJCwjRnn8fYiRk/5OithekTCCi1wSLmfGy3pTF8TQehFUEk6yH3uXzgFk6N04Ky4ZzF sBYg1bYY88bNlev1IdC3IWN9rCP60MpBx9rCYTqSUrXCnolhztMAV4ObmaAvSyQ0ZiU1 YD0Kcktjq/XSR0737kZLfgfGXhPaV8kE2BqGcsgwNCMp/164iqK2zDx79aO1k9yvwOUU Uoxg== X-Received: by 10.182.134.231 with SMTP id pn7mr12698814obb.11.1369426921125; Fri, 24 May 2013 13:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.45.1 with HTTP; Fri, 24 May 2013 13:21:46 -0700 (PDT) In-Reply-To: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> From: Josh Mandel Date: Fri, 24 May 2013 13:21:46 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c2c3962dff0504dd7c8db5 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 20:22:05 -0000 --001a11c2c3962dff0504dd7c8db5 Content-Type: text/plain; charset=ISO-8859-1 I think this discussion mixes two separable questions: 1. Should dyn-reg support client-side browser-based apps (which need client_ids for each AS they talk to, even if they only talk briefly and then throw the credentials away)? 2. Which authorization flows are available to clients? I have examples of client-side browser-based apps that fetch blood pressure values from the BlueButton+ API, and do some calculations / visualizations. These apps need to run against any of a large collection of data holders (all of whom implement the same API endpoints), and may learn about new data holders in realtime from an end-user. If we believe this kind of app is a valid use case for dyn reg (Q. #1), then whether it uses Implicit or Code flow (Q. #2) has no bearing on the overall set of concerns you raise. (Unintentional DOS, for example, is no less an issue with the code flow, for browser-based apps that need a throwaway client_id for brief interactions.) And from an app developer's perspective, Implicit flow is simpler and better captures the semantics of a public client. Thoughts? -Josh On May 24, 2013 11:35 AM, "Phil Hunt" wrote: > I wanted to bring out a quick discussion to ask the question if it makes > sense to support implicit clients in dynamic registration. > > By definition, implicit clients are unauthenticated. Therefore the only > purpose to register an implicit client is to obtain a client_id with a > particular AS instance. > > A few issues to consider: > * Implicit clients typically run in browsers (javascript). Do we really > want each occurrence of a browser running a client to register? > --> This could mean even the same browser running implicit flow repeat > times, would register repeatedly. > --> If registration occurs per occurrence, what is the value? > > * What use cases typically occur for deployment against different AS and > Resource API instances? > --> Eg. I can see a javascript component of a web site that uses a > corresponding resource API. So it may be possible that the javascript and > the resource API are running in the same domain. In this case, the > javascript code, though written as part of a shared library/distribution, > is still bound to a configured AS deployment. Is it really dynamic? If > this is the case, wouldn't an OOB registration that updates the client_id > in the deployment be better suited? > --> Are there any examples of javascript clients that need to connect > to one or more AS servers on a truly dynamic basis? > > * Is there a DOS attack possible (even unintentionally) because implicit > clients will start to register frequently creating huge numbers of > client_ids that cause spin-off provisioning issues depending on how AS > registration, token, and policy systems are implemented? > > Apparently OIDC and UMA had these profiles supported before, but I'm > really trying to understand why implicit clients should have dynamic > registration support. Would appreciate any discussion on this. At > minimum, there are probably some security considerations we need to think > through and document. > > Thanks for your comments, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2c3962dff0504dd7c8db5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I think this discussion mixes two separable= questions:

1. Should dyn-reg support client-side browser-based apps = (which need =A0client_ids for each AS they talk to, even if they only talk = briefly and then throw the credentials away)?

2. Which authorization flows are available to clients?

I have examples of client-side browser-based apps that fetch blood pressur= e values from the BlueButton+ API, and do some calculations / visualization= s. =A0These apps need to run against any of a large collection of data hold= ers (all of whom implement the same API endpoints), and may learn about new= data holders in realtime from an end-user.

If we believe this kind of app is a valid use case for dyn reg= (Q. #1), then whether it uses Implicit or Code flow (Q. #2) has no bearing= on the overall set of concerns you raise. (Unintentional DOS, for example,= is no less an issue with the code flow, for browser-based apps that need a= throwaway client_id for brief interactions.) And from an app developer'= ;s perspective, Implicit flow is simpler and better captures the semantics = of a public client.

Thoughts?

=A0 -Josh

On May 24, 2013 11:35 AM, "Phil Hunt" = <phil.hunt@ora= cle.com> wrote:
I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration.

By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance.

A few issues to consider:
* Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register?
=A0 =A0--> This could mean even the same browser running implicit flow r= epeat times, would register repeatedly.
=A0 =A0--> If registration occurs per occurrence, what is the value?

* What use cases typically occur for deployment against different AS and Re= source API instances?
=A0 =A0--> Eg. I can see a javascript component of a web site that uses = a corresponding resource API. =A0So it may be possible that the javascript = and the resource API are running in the same domain. =A0 In this case, the = javascript code, though written as part of a shared library/distribution, i= s still bound to a configured AS deployment. =A0Is it really dynamic? If th= is is the case, wouldn't an OOB registration that updates the client_id= in the deployment be better suited?
=A0 =A0--> Are there any examples of javascript clients that need to con= nect to one or more AS servers on a truly dynamic basis?

* Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented?

Apparently OIDC and UMA had these profiles supported before, but I'm re= ally trying to understand why implicit clients should have dynamic registra= tion support. =A0Would appreciate any discussion on this. =A0At minimum, th= ere are probably some security considerations we need to think through and = document.

Thanks for your comments,

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.= com





_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a11c2c3962dff0504dd7c8db5-- From jricher@mitre.org Fri May 24 13:36:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C67F11E8123 for ; Fri, 24 May 2013 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ9YJ3AtpUYI for ; Fri, 24 May 2013 13:36:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6601111E811F for ; Fri, 24 May 2013 13:36:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98DCF1F0620; Fri, 24 May 2013 16:36:29 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 831321F060C; Fri, 24 May 2013 16:36:29 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Fri, 24 May 2013 16:36:29 -0400 From: "Richer, Justin P." To: Josh Mandel Thread-Topic: [OAUTH-WG] Implicit clients in Dynamic Registration Thread-Index: AQHOWLxf0kxswWglEk61nwg7s8o/MpkVDlAA Date: Fri, 24 May 2013 20:36:28 +0000 Message-ID: <464022C2-0E18-40FD-8997-0E2502078DA1@mitre.org> References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: multipart/alternative; boundary="_000_464022C20E1840FD89970E2502078DA1mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 20:36:35 -0000 --_000_464022C20E1840FD89970E2502078DA1mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Josh, and I believe that this kind of application should defin= itely be supported. One of my goals with the Dynamic Registration draft was= to make it so that it could be used for all the various flavors of OAuth t= hat people are using today. But that said, I'm not at all against giving gu= idance to how and where to use it with these various flavors. And regarding the DOS, one thing that the RESTful API here gives us is a me= ans for well-behaved clients to clean up after themselves, where possible. = Say the Blood Pressure Grapher is done with its session, it can call the Cl= ient Configuration Endpoint and DELETE itself, helping mitigate a flood of = one-time-use client_ids. Doesn't necessarily help the case where the client= s can't (or won't) clean up after themselves, or with a deliberate DOS, but= there's a security consideration about throttling the registration endpoin= t already. Perhaps we should have something about "if the client_id hasn't = been used in any grants in some amount of time, the AS should throw it away= ". But how long that is and at what level of client_id overpopulation the A= S starts to care is way outside of the spec. -- Justin On May 24, 2013, at 4:21 PM, Josh Mandel > wrote: I think this discussion mixes two separable questions: 1. Should dyn-reg support client-side browser-based apps (which need clien= t_ids for each AS they talk to, even if they only talk briefly and then thr= ow the credentials away)? 2. Which authorization flows are available to clients? I have examples of client-side browser-based apps that fetch blood pressure= values from the BlueButton+ API, and do some calculations / visualizations= . These apps need to run against any of a large collection of data holders= (all of whom implement the same API endpoints), and may learn about new da= ta holders in realtime from an end-user. If we believe this kind of app is a valid use case for dyn reg (Q. #1), the= n whether it uses Implicit or Code flow (Q. #2) has no bearing on the overa= ll set of concerns you raise. (Unintentional DOS, for example, is no less a= n issue with the code flow, for browser-based apps that need a throwaway cl= ient_id for brief interactions.) And from an app developer's perspective, I= mplicit flow is simpler and better captures the semantics of a public clien= t. Thoughts? -Josh On May 24, 2013 11:35 AM, "Phil Hunt" > wrote: I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration. By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance. A few issues to consider: * Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register? --> This could mean even the same browser running implicit flow repeat t= imes, would register repeatedly. --> If registration occurs per occurrence, what is the value? * What use cases typically occur for deployment against different AS and Re= source API instances? --> Eg. I can see a javascript component of a web site that uses a corre= sponding resource API. So it may be possible that the javascript and the r= esource API are running in the same domain. In this case, the javascript = code, though written as part of a shared library/distribution, is still bou= nd to a configured AS deployment. Is it really dynamic? If this is the cas= e, wouldn't an OOB registration that updates the client_id in the deploymen= t be better suited? --> Are there any examples of javascript clients that need to connect to= one or more AS servers on a truly dynamic basis? * Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented? Apparently OIDC and UMA had these profiles supported before, but I'm really= trying to understand why implicit clients should have dynamic registration= support. Would appreciate any discussion on this. At minimum, there are = probably some security considerations we need to think through and document= . Thanks for your comments, Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_464022C20E1840FD89970E2502078DA1mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I agree with Josh, and I believe that this kind of application should defin= itely be supported. One of my goals with the Dynamic Registration draft was= to make it so that it could be used for all the various flavors of OAuth t= hat people are using today. But that said, I'm not at all against giving guidance to how and where to use = it with these various flavors. 

And regarding the DOS, one thing that the RESTful API here gives us is= a means for well-behaved clients to clean up after themselves, where possi= ble. Say the Blood Pressure Grapher is done with its session, it can call t= he Client Configuration Endpoint and DELETE itself, helping mitigate a flood of one-time-use client_ids. Do= esn't necessarily help the case where the clients can't (or won't) clean up= after themselves, or with a deliberate DOS, but there's a security conside= ration about throttling the registration endpoint already. Perhaps we should have something about "if the clie= nt_id hasn't been used in any grants in some amount of time, the AS should = throw it away". But how long that is and at what level of client_id ov= erpopulation the AS starts to care is way outside of the spec. 

 -- Justin

On May 24, 2013, at 4:21 PM, Josh Mandel <jmandel@gmail.com>
 wrote:

I think this discussion mixes two separable questions:

1. Should dyn-reg support client-side browser-based apps (which need &nb= sp;client_ids for each AS they talk to, even if they only talk briefly and = then throw the credentials away)?

2. Which authorization flows are available to clients?

I have examples of client-side browser-based apps that fetch = blood pressure values from the BlueButton+ API, and do some calculation= s / visualizations.  These apps need to run against any of a large col= lection of data holders (all of whom implement the same API endpoints), and may learn about new data holders in realtime = from an end-user.

If we believe this kind of app is a valid use case for dyn re= g (Q. #1), then whether it uses Implicit or Code flow (Q. #2) has no bearin= g on the overall set of concerns you raise. (Unintentional DOS, for example= , is no less an issue with the code flow, for browser-based apps that need a throwaway client_id for brief int= eractions.) And from an app developer's perspective, Implicit flow is simpl= er and better captures the semantics of a public client.

Thoughts?

  -Josh

On May 24, 2013 11:35 AM, "Phil Hunt" = <phil.hunt@ora= cle.com> wrote:
I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration.

By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance.

A few issues to consider:
* Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register?
   --> This could mean even the same browser running implicit = flow repeat times, would register repeatedly.
   --> If registration occurs per occurrence, what is the valu= e?

* What use cases typically occur for deployment against different AS and Re= source API instances?
   --> Eg. I can see a javascript component of a web site that= uses a corresponding resource API.  So it may be possible that the ja= vascript and the resource API are running in the same domain.   In thi= s case, the javascript code, though written as part of a shared library/distribution, is still bound to a configured AS deploymen= t.  Is it really dynamic? If this is the case, wouldn't an OOB registr= ation that updates the client_id in the deployment be better suited?
   --> Are there any examples of javascript clients that need = to connect to one or more AS servers on a truly dynamic basis?

* Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented?

Apparently OIDC and UMA had these profiles supported before, but I'm really= trying to understand why implicit clients should have dynamic registration= support.  Would appreciate any discussion on this.  At minimum, = there are probably some security considerations we need to think through and document.

Thanks for your comments,

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





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

--_000_464022C20E1840FD89970E2502078DA1mitreorg_-- From internet-drafts@ietf.org Fri May 24 13:36:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277D521E808A; Fri, 24 May 2013 13:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnkIbBWRBatS; Fri, 24 May 2013 13:36:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6A821E808E; Fri, 24 May 2013 13:36:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 13:36:38 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-11.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, 24 May 2013 20:36:40 -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 2.0 Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-11.txt Pages : 34 Date : 2013-05-24 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth 2.0 Clients at an Authorization Server and methods for the dynamically registered client to manage its registration. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmandel@gmail.com Fri May 24 13:41:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633D011E8126 for ; Fri, 24 May 2013 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pwHNDRL8zEz for ; Fri, 24 May 2013 13:41:04 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8522B11E8121 for ; Fri, 24 May 2013 13:41:03 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wn6so5882068obc.8 for ; Fri, 24 May 2013 13:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jQCdvVpOnJ3ES0vGwM0sai6S0jOittYR17WV1NVzELE=; b=vHsQMnInj/HCfCc2ufSOUT5A4oAAQmf1IIcQXgPmN5q3fIPfJ2qJaeNuPpcwUKi+1V 1jEdQM05ou8ALR92Wif5PYMfJuFWmS5IU6ipZmEYJUJKXTM7z5COS7JyPn2eb8mBG8c5 VVTVKhvMYpbtqWSWBASrhxqXpgmBXdP93M+z9PafY153DfJgx7q4GgIuzTnGrovk3HNs OX9L91IKt6U3reCkO65Amw0aNXpP73c3Ar9fxS0cd6qsEnsiwq0ED0jx6aj1FG9bYL0S QvX7mvx2fe88MDlvk+uSyH3PBpMCPCeEGIew6KY/IsZ/c2zkWQES+2JFpXlv1iMvhD+k Nwsg== X-Received: by 10.182.134.231 with SMTP id pn7mr12742939obb.11.1369428062651; Fri, 24 May 2013 13:41:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.45.1 with HTTP; Fri, 24 May 2013 13:40:47 -0700 (PDT) In-Reply-To: <464022C2-0E18-40FD-8997-0E2502078DA1@mitre.org> References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> <464022C2-0E18-40FD-8997-0E2502078DA1@mitre.org> From: Josh Mandel Date: Fri, 24 May 2013 13:40:47 -0700 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=001a11c2c39638501f04dd7cd1e4 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 20:41:05 -0000 --001a11c2c39638501f04dd7cd1e4 Content-Type: text/plain; charset=ISO-8859-1 I expect this is a non-starter, but dyn-reg *could* allow the client ti include a "please expire me in xx min" flag in the registration request (avoiding need for explicit cleanup later). -J On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. wrote: > I agree with Josh, and I believe that this kind of application should > definitely be supported. One of my goals with the Dynamic Registration > draft was to make it so that it could be used for all the various flavors > of OAuth that people are using today. But that said, I'm not at all against > giving guidance to how and where to use it with these various flavors. > > And regarding the DOS, one thing that the RESTful API here gives us is a > means for well-behaved clients to clean up after themselves, where > possible. Say the Blood Pressure Grapher is done with its session, it can > call the Client Configuration Endpoint and DELETE itself, helping mitigate > a flood of one-time-use client_ids. Doesn't necessarily help the case where > the clients can't (or won't) clean up after themselves, or with a > deliberate DOS, but there's a security consideration about throttling the > registration endpoint already. Perhaps we should have something about "if > the client_id hasn't been used in any grants in some amount of time, the AS > should throw it away". But how long that is and at what level of client_id > overpopulation the AS starts to care is way outside of the spec. > > -- Justin > > On May 24, 2013, at 4:21 PM, Josh Mandel > wrote: > > I think this discussion mixes two separable questions: > > 1. Should dyn-reg support client-side browser-based apps (which need > client_ids for each AS they talk to, even if they only talk briefly and > then throw the credentials away)? > > 2. Which authorization flows are available to clients? > > I have examples of client-side browser-based apps that fetch blood > pressure values from the BlueButton+ API, and do some calculations / > visualizations. These apps need to run against any of a large collection > of data holders (all of whom implement the same API endpoints), and may > learn about new data holders in realtime from an end-user. > > If we believe this kind of app is a valid use case for dyn reg (Q. #1), > then whether it uses Implicit or Code flow (Q. #2) has no bearing on the > overall set of concerns you raise. (Unintentional DOS, for example, is no > less an issue with the code flow, for browser-based apps that need a > throwaway client_id for brief interactions.) And from an app developer's > perspective, Implicit flow is simpler and better captures the semantics of > a public client. > > Thoughts? > > -Josh > On May 24, 2013 11:35 AM, "Phil Hunt" wrote: > >> I wanted to bring out a quick discussion to ask the question if it makes >> sense to support implicit clients in dynamic registration. >> >> By definition, implicit clients are unauthenticated. Therefore the only >> purpose to register an implicit client is to obtain a client_id with a >> particular AS instance. >> >> A few issues to consider: >> * Implicit clients typically run in browsers (javascript). Do we really >> want each occurrence of a browser running a client to register? >> --> This could mean even the same browser running implicit flow repeat >> times, would register repeatedly. >> --> If registration occurs per occurrence, what is the value? >> >> * What use cases typically occur for deployment against different AS and >> Resource API instances? >> --> Eg. I can see a javascript component of a web site that uses a >> corresponding resource API. So it may be possible that the javascript and >> the resource API are running in the same domain. In this case, the >> javascript code, though written as part of a shared library/distribution, >> is still bound to a configured AS deployment. Is it really dynamic? If >> this is the case, wouldn't an OOB registration that updates the client_id >> in the deployment be better suited? >> --> Are there any examples of javascript clients that need to connect >> to one or more AS servers on a truly dynamic basis? >> >> * Is there a DOS attack possible (even unintentionally) because implicit >> clients will start to register frequently creating huge numbers of >> client_ids that cause spin-off provisioning issues depending on how AS >> registration, token, and policy systems are implemented? >> >> Apparently OIDC and UMA had these profiles supported before, but I'm >> really trying to understand why implicit clients should have dynamic >> registration support. Would appreciate any discussion on this. At >> minimum, there are probably some security considerations we need to think >> through and document. >> >> Thanks for your comments, >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11c2c39638501f04dd7cd1e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I expect this is a non-starter, but dyn-reg could= =A0allow=A0the client ti include a "please expire me in xx min" f= lag in the registration request (avoiding need for explicit cleanup later).=

=A0 -J

On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. <jricher@mitre.= org> wrote:
I agree with Josh, and I believe that this kind of application should defin= itely be supported. One of my goals with the Dynamic Registration draft was= to make it so that it could be used for all the various flavors of OAuth t= hat people are using today. But that said, I'm not at all against giving guidance to how and where to = use it with these various flavors.=A0

And regarding the DOS, one thing that the RESTful API here gives us is= a means for well-behaved clients to clean up after themselves, where possi= ble. Say the Blood Pressure Grapher is done with its session, it can call t= he Client Configuration Endpoint and DELETE itself, helping mitigate a flood of one-time-use client_ids. Do= esn't necessarily help the case where the clients can't (or won'= ;t) clean up after themselves, or with a deliberate DOS, but there's a = security consideration about throttling the registration endpoint already. Perhaps we should have something about "if the clie= nt_id hasn't been used in any grants in some amount of time, the AS sho= uld throw it away". But how long that is and at what level of client_i= d overpopulation the AS starts to care is way outside of the spec.=A0

=A0-- Justin

On May 24, 2013, at 4:21 PM, Josh Mandel <jmandel@gmail.com>
=A0wrote:

I think this discussion mixes two separable questions:

1. Should dyn-reg support client-side browser-based apps (which need =A0= client_ids for each AS they talk to, even if they only talk briefly and the= n throw the credentials away)?

2. Which authorization flows are available to clients?

I have examples of client-side browser-based apps that fetch blood press= ure values from the BlueButton+ API, and do some calculations / visualizati= ons. =A0These apps need to run against any of a large collection of data ho= lders (all of whom implement the same API endpoints), and may learn about new data holders in realtime = from an end-user.

If we believe this kind of app is a valid use case for dyn reg (Q. #1), = then whether it uses Implicit or Code flow (Q. #2) has no bearing on the ov= erall set of concerns you raise. (Unintentional DOS, for example, is no les= s an issue with the code flow, for browser-based apps that need a throwaway client_id for brief int= eractions.) And from an app developer's perspective, Implicit flow is s= impler and better captures the semantics of a public client.

Thoughts?

=A0 -Josh

On May 24, 2013 11:35 AM, "Phil Hunt" = <phil.hunt@ora= cle.com> wrote:
I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration.

By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance.

A few issues to consider:
* Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register?
=A0 =A0--> This could mean even the same browser running implicit flow r= epeat times, would register repeatedly.
=A0 =A0--> If registration occurs per occurrence, what is the value?

* What use cases typically occur for deployment against different AS and Re= source API instances?
=A0 =A0--> Eg. I can see a javascript component of a web site that uses = a corresponding resource API. =A0So it may be possible that the javascript = and the resource API are running in the same domain. =A0 In this case, the = javascript code, though written as part of a shared library/distribution, is still bound to a configured AS deploymen= t. =A0Is it really dynamic? If this is the case, wouldn't an OOB regist= ration that updates the client_id in the deployment be better suited?
=A0 =A0--> Are there any examples of javascript clients that need to con= nect to one or more AS servers on a truly dynamic basis?

* Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented?

Apparently OIDC and UMA had these profiles supported before, but I'm re= ally trying to understand why implicit clients should have dynamic registra= tion support. =A0Would appreciate any discussion on this. =A0At minimum, th= ere are probably some security considerations we need to think through and document.

Thanks for your comments,

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





_______________________________________________
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


--001a11c2c39638501f04dd7cd1e4-- From jricher@mitre.org Fri May 24 14:01:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0641321F90AC for ; Fri, 24 May 2013 14:01:35 -0700 (PDT) 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.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evWQ6m5Q+2D0 for ; Fri, 24 May 2013 14:01:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFBF21F8F43 for ; Fri, 24 May 2013 14:01:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF7DD1F02D2; Fri, 24 May 2013 17:01:29 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BFBCB1F0307; Fri, 24 May 2013 17:01:29 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Fri, 24 May 2013 17:01:29 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Initial Client Credential - Dynamic Registration Thread-Index: AQHOWLm7ydzwTxyadku1/UUzkgHs9JkVFVIA Date: Fri, 24 May 2013 21:01:29 +0000 Message-ID: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: multipart/alternative; boundary="_000_8F29B5A310D8401CBAE494253180FFA1mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 21:01:35 -0000 --_000_8F29B5A310D8401CBAE494253180FFA1mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I completely disagree with this assessment. The latest draft (which was jus= t posted) has new language describing what this token is and what it's for,= and I hope that will clear things up. But even so, let me try to address y= our concerns in-line. On May 24, 2013, at 4:02 PM, Phil Hunt > wrote: I have been struggling with the concept of an initial client credential cov= ered in the current draft (rev 10): 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. The Client Registration Endpoint is an OAuth Protected Resource. This token= is a means for authorizing calls to the endpoint. Can you use it for other= things? Sure, just like you can use OAuth tokens for other things (passing= data about authentication, for instance). But fundamentally, it's just ano= ther token that's scoped to one endpoint for a specific purpose. The use case is very important since it opens the door for a way for truste= d entities to sign assertions that could be accepted by a set of deployed a= uthorization servers. For potential software API developers (e.g. Oracle C= RM), the developer could potentially register with Oracle CRMs registration= service manually, and obtain a signed assertion for use in their client so= ftware. Upon initiating dynamic registration, the client software would pr= esent the assertion as its initial authorization in the HTTP Authorization = header as Justin describes above. While this has worked in practice so far, I am concerned about this asserti= on being presented in this way. The authentication header has special meaning to many servers. Depending on= implementation architecture, the authorization header will first be interc= epted by the authentication components in the server. Here's where I get w= orried. 1. The assertion being presented is not an Authn assertion. There is no "a= uthentication session" tied to the assertion That's fine. Not all OAuth tokens are authentication assertions today, and = this is just another OAuth token. 2. The assertion isn't an authentication, but rather signed client metadat= a. If you want to interpret the token as both authorization to call the regist= ration endpoint as well as client metadata, you can do that. But you're goi= ng to have to define how that metadata is passed, how it's signed, how it's= interpreted, etc. Which, you'll note, is exactly what you can do with an O= Auth token already. You can use an OAuth token as an opaque blob, or you ca= n define structure, signatures, etc., to pack information inside of it. If = the two always had to be together, then OAuth would be defined with JWTs on= ly and we'd have something that was much less useful. 3. The bearer assertion is easily copied. Thus the server should only trus= t this as metadata Depends on the kind of client, and with BB+ we've defined a matrix of clien= t types with different policy rules (since we can control policy in BB+ lan= d). Our discovery and registry setup lets us enforce these rules appropriat= ely as well. 4. It ends up performing the same role as software_id Not really. How does software_id (on its own) represent a that the holder i= s authorized to make this call? You'd have to put rules around software_id = saying that it needs to be processed in a particular way, and I think such = rules are far too restrictive for this draft. Another difference is that a = bearer token isn't generally self-asserted, and it's assumed the registrati= on server will have some means of validating this token, like it would with= any OAuth token. It's more like you can use the Initial Registration Token= to fulfill the same role that you're suggesting software_id be used for, w= hich, to me, is more of an argument against the more-limited software_id th= an it is against the existing technology. While I think it is ok for existing implementations to continue with this p= ractice, I would prefer to standardize passing of client software assertion= metadata outside of the authentication channel in HTTP. The token in question is fundamentally an authorization mechanism for calli= ng the registration endpoint. I agree there's value in passing client softw= are assertions around, and that we should solve that in an interoperable wa= y, but that's a completely separate question from registration. A further benefit is that the registration endpoint authentication system o= nly has to deal with locally issued credentials. The logic for handling fed= erated client meta data can be isolated to the registration server logic. You can still do that if your registration server is the one generating the= initial access token. Normally, the registration endpoint's going to be ti= ghtly tied to the authorization server, and whatever process is used to get= the initial registration token is going to also be tightly tied to the reg= istration server. My feeling is that if we keep "initial authorization credential" as being p= assed in the HTTP Authorization header, then strict rules about the content= s of the token and the processing rules must be defined so that HTTP server= security systems can be extended to support this. It's an OAuth token. You use whatever HTTP security systems that you alread= y have to process OAuth tokens on it. If you also want to use it to tell yo= u something about client metadata, you're going to have to define further p= rocessing, yes, because "an OAuth token" doesn't tell you anything about wh= at's inside of it or what the token means -- on purpose. But you'd have to = do the same thing with software_id. But nothing is saying that you need to = do that, or that it has to be an assertion at all. Maybe you just want to l= ock down your API to know developers, so you issue them hex blobs to call t= he API with. Those could expire 5 minutes from when you issued them, if you= wanted. Or they could be SAML blobs, or JWTs, or anything else that can pa= ss for an OAuth token. There's no reason any of this should be disallowed b= y the registration spec, because the registration spec doesn't care. All it= cares about is that it's an OAuth token and it's (somehow) validated by th= e registration endpoint in such a way that the HTTP call to the Registratio= n Endpoint is valid. This is absolutely bog-standard OAuth Protected Resour= ce here. By defining it as an OAuth token (and no further), we immediately = gain all of the flexibility and power of OAuth tokens. If we use software_id, and indicate that it can accept a "software registra= tion assertion", we can be more flexible and minimize the processing rules = we have to declare in the draft. That said, if there is a case to adopt str= ict rules here too, I am open. I still think that software_id is really only useful and interoperable in t= he presence of strict rules, which is why I'm not convinced it belongs in t= he draft as is and instead belongs in an extension that defines such rules.= This draft would be way beyond the two paragraphs that you had spoken of p= reviously, and it would be both useful and interoperable. But it's enough c= omplexity and enough of a very specific corner case that I am not at all co= mfortable putting that level of processing into the dynamic registration dr= aft. I am willing to put software_id into dynamic registration as a hook to= some future-to-be-defined specification that tells you how to validate it = and parse it and use it for validating client metadata and tie it to a deve= loper and all that fun stuff -- I don't personally see the utility in that,= but I don't think it'd really break anything if it went in and you thought= you could use it to bootstrap your process. -- Justin Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_8F29B5A310D8401CBAE494253180FFA1mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <9526EFD614A1BB4E9BD51D14CF4FFEA8@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I completely disagree with this assessment. The latest draft (which was jus= t posted) has new language describing what this token is and what it's for,= and I hope that will clear things up. But even so, let me try to address y= our concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential cov= ered in the current draft (rev 10): 
The Client Registration Endpoint MAY accept an initial a=
uthorization
   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.

The Client Registration Endpoint is an OAuth Protected Resource. This = token is a means for authorizing calls to the endpoint. Can you use it for = other things? Sure, just like you can use OAuth tokens for other things (pa= ssing data about authentication, for instance). But fundamentally, it's just another token that's scoped to= one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for t= rusted entities to sign assertions that could be accepted by a set of deplo= yed authorization servers.  For potential software API developers (e.g= . Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a sign= ed assertion for use in their client software.  Upon initiating dynami= c registration, the client software would present the assertion as its init= ial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this as= sertion being presented in this way.

The authentication header has special meaning to many servers. Dependi= ng on implementation architecture, the authorization header will first be i= ntercepted by the authentication components in the server.  Here's whe= re I get worried.

1.  The assertion being presented is not an Authn assertion. Ther= e is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today,= and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed clie= nt metadata.

If you want to interpret the token as both authorization to call the r= egistration endpoint as well as client metadata, you can do that. But you'r= e going to have to define how that metadata is passed, how it's signed, how= it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use = an OAuth token as an opaque blob, or you can define structure, signatures, = etc., to pack information inside of it. If the two always had to be togethe= r, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server should= only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix= of client types with different policy rules (since we can control policy i= n BB+ land). Our discovery and registry setup lets us enforce these rul= es appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the hol= der is authorized to make this call? You'd have to put rules around softwar= e_id saying that it needs to be processed in a particular way, and I think = such rules are far too restrictive for this draft. Another difference is that a bearer token isn't gener= ally self-asserted, and it's assumed the registration server will have some= means of validating this token, like it would with any OAuth token. It's m= ore like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used = for, which, to me, is more of an argument against the more-limited software= _id than it is against the existing technology.


While I think it is ok for existing implementations to continue wit= h this practice, I would prefer to standardize passing of client softwa= re assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for = calling the registration endpoint. I agree there's value in passing client = software assertions around, and that we should solve that in an interoperab= le way, but that's a completely separate question from registration.


A further benefit is that the registration endpoint authentication sys= tem only has to deal with locally issued credentials. The logic for handlin= g federated client meta data can be isolated to the registration server log= ic.

You can still do that if your registration server is the one generatin= g the initial access token. Normally, the registration endpoint's going to = be tightly tied to the authorization server, and whatever process is used t= o get the initial registration token is going to also be tightly tied to the registration server. 


My feeling is that if we keep "initial authorization credential&q= uot; as being passed in the HTTP Authorization header, then strict rules ab= out the contents of the token and the processing rules must be defined so t= hat HTTP server security systems can be extended to support this.

It's an OAuth token. You use whatever HTTP security systems that you a= lready have to process OAuth tokens on it. If you also want to use it to te= ll you something about client metadata, you're going to have to define furt= her processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or w= hat the token means -- on purpose. But you'd have to do the same thing with= software_id. But nothing is saying that you need to do that, or that it ha= s to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex = blobs to call the API with. Those could expire 5 minutes from when you issu= ed them, if you wanted. Or they could be SAML blobs, or JWTs, or anything e= lse that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spe= c, because the registration spec doesn't care. All it cares about is that i= t's an OAuth token and it's (somehow) validated by the registration endpoin= t in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAu= th Protected Resource here. By defining it as an OAuth token (and no furthe= r), we immediately gain all of the flexibility and power of OAuth tokens.&n= bsp;


If we use software_id, and indicate that it can accept a "softwar= e registration assertion", we can be more flexible and minimize the pr= ocessing rules we have to declare in the draft. That said, if there is a ca= se to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable= in the presence of strict rules, which is why I'm not convinced it belongs= in the draft as is and instead belongs in an extension that defines such r= ules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both= useful and interoperable. But it's enough complexity and enough of a very = specific corner case that I am not at all comfortable putting that level of= processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook= to some future-to-be-defined specification that tells you how to validate = it and parse it and use it for validating client metadata and tie it to a d= eveloper and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd real= ly break anything if it went in and you thought you could use it to bootstr= ap your process.

 -- Justin

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

--_000_8F29B5A310D8401CBAE494253180FFA1mitreorg_-- From jricher@mitre.org Fri May 24 14:10:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C715421F85DC for ; Fri, 24 May 2013 14:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA6-Eg9zkDED for ; Fri, 24 May 2013 14:10:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 647E621F8F1E for ; Fri, 24 May 2013 14:10:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E083D1F05F2 for ; Fri, 24 May 2013 17:10:03 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C83281F0307 for ; Fri, 24 May 2013 17:10:03 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Fri, 24 May 2013 17:10:03 -0400 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-11.txt Thread-Index: AQHOWL6E0lk8QEAnl0aYAwuiV/rpFJkVF60A Date: Fri, 24 May 2013 21:10:03 +0000 Message-ID: <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> In-Reply-To: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-11.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, 24 May 2013 21:10:09 -0000 New Dynamic Registration draft is published, incorporating much of the disc= ussion from the group this week.=20 Some normative changes that should have minimal impact: - "expires_at" is now "client_secret_expires_at" - "issued_at" is now "client_id_issued_at" - creation of an IANA registry for token_endpoint_auth_method - removal of two underdefined values from token_endpoint_auth_method (clie= nt_secret_jwt and private_key_jwt), these are now defined in an extension (= OpenID Connect Registration) And several editorial changes: - new "client lifecycle" section that describes how different kinds of cli= ents can use the dynamic registration protocol, how a client's credentials = get refreshed, and the relationship between the Client Identifier and the C= lient software - new "registration tokens and credentials" section describing the differe= nt kinds of tokens and credentials used in the registration process, what t= hey're for, and why they're all separate - clarified the definitions of several fields like policy_uri and tos_uri Thanks for all the great feedback, and please keep the constructive comment= ary coming! -- Justin On May 24, 2013, at 4:36 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-11.txt > Pages : 34 > Date : 2013-05-24 >=20 > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth 2.0 Clients at an Authorization Server and > methods for the dynamically registered client to manage its > registration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-11 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Fri May 24 14:14:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69EE21F8EEC for ; Fri, 24 May 2013 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg4gl8PJG7LB for ; Fri, 24 May 2013 14:14:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53AEB11E80A5 for ; Fri, 24 May 2013 14:14:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC7B91F0307; Fri, 24 May 2013 17:14:45 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C041C1F03E2; Fri, 24 May 2013 17:14:45 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Fri, 24 May 2013 17:14:45 -0400 From: "Richer, Justin P." To: Josh Mandel Thread-Topic: [OAUTH-WG] Implicit clients in Dynamic Registration Thread-Index: AQHOWLxf0kxswWglEk61nwg7s8o/MpkVDlAAgAABNYCAAAl8AA== Date: Fri, 24 May 2013 21:14:45 +0000 Message-ID: <12DD95B4-EBA7-4771-B73C-51013D658715@mitre.org> References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> <464022C2-0E18-40FD-8997-0E2502078DA1@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.103] Content-Type: multipart/alternative; boundary="_000_12DD95B4EBA74771B73C51013D658715mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 21:14:51 -0000 --_000_12DD95B4EBA74771B73C51013D658715mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can see what you're trying to do there, but I agree that it's a bit of a = non-starter. It assumes that clients even can be expired (which requires ti= me-based processing of a client, not something most AS's are set up to do t= oday, though it's far from impossible). And an in-browser client is likely = to be bound to the user session. Would the client be allowed to refresh tha= t value on an Update call in order to extend its lifetime, too? If you want to define an extension for it (or even try it out inside of BB+= ), I think that makes the most sense. -- Justin On May 24, 2013, at 4:40 PM, Josh Mandel > wrote: I expect this is a non-starter, but dyn-reg could allow the client ti inclu= de a "please expire me in xx min" flag in the registration request (avoidin= g need for explicit cleanup later). -J On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. > wrote: I agree with Josh, and I believe that this kind of application should defin= itely be supported. One of my goals with the Dynamic Registration draft was= to make it so that it could be used for all the various flavors of OAuth t= hat people are using today. But that said, I'm not at all against giving gu= idance to how and where to use it with these various flavors. And regarding the DOS, one thing that the RESTful API here gives us is a me= ans for well-behaved clients to clean up after themselves, where possible. = Say the Blood Pressure Grapher is done with its session, it can call the Cl= ient Configuration Endpoint and DELETE itself, helping mitigate a flood of = one-time-use client_ids. Doesn't necessarily help the case where the client= s can't (or won't) clean up after themselves, or with a deliberate DOS, but= there's a security consideration about throttling the registration endpoin= t already. Perhaps we should have something about "if the client_id hasn't = been used in any grants in some amount of time, the AS should throw it away= ". But how long that is and at what level of client_id overpopulation the A= S starts to care is way outside of the spec. -- Justin On May 24, 2013, at 4:21 PM, Josh Mandel > wrote: I think this discussion mixes two separable questions: 1. Should dyn-reg support client-side browser-based apps (which need clien= t_ids for each AS they talk to, even if they only talk briefly and then thr= ow the credentials away)? 2. Which authorization flows are available to clients? I have examples of client-side browser-based apps that fetch blood pressure= values from the BlueButton+ API, and do some calculations / visualizations= . These apps need to run against any of a large collection of data holders= (all of whom implement the same API endpoints), and may learn about new da= ta holders in realtime from an end-user. If we believe this kind of app is a valid use case for dyn reg (Q. #1), the= n whether it uses Implicit or Code flow (Q. #2) has no bearing on the overa= ll set of concerns you raise. (Unintentional DOS, for example, is no less a= n issue with the code flow, for browser-based apps that need a throwaway cl= ient_id for brief interactions.) And from an app developer's perspective, I= mplicit flow is simpler and better captures the semantics of a public clien= t. Thoughts? -Josh On May 24, 2013 11:35 AM, "Phil Hunt" > wrote: I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration. By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance. A few issues to consider: * Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register? --> This could mean even the same browser running implicit flow repeat t= imes, would register repeatedly. --> If registration occurs per occurrence, what is the value? * What use cases typically occur for deployment against different AS and Re= source API instances? --> Eg. I can see a javascript component of a web site that uses a corre= sponding resource API. So it may be possible that the javascript and the r= esource API are running in the same domain. In this case, the javascript = code, though written as part of a shared library/distribution, is still bou= nd to a configured AS deployment. Is it really dynamic? If this is the cas= e, wouldn't an OOB registration that updates the client_id in the deploymen= t be better suited? --> Are there any examples of javascript clients that need to connect to= one or more AS servers on a truly dynamic basis? * Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented? Apparently OIDC and UMA had these profiles supported before, but I'm really= trying to understand why implicit clients should have dynamic registration= support. Would appreciate any discussion on this. At minimum, there are = probably some security considerations we need to think through and document= . Thanks for your comments, Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_12DD95B4EBA74771B73C51013D658715mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I can see what you're trying to do there, but I agree that it's a bit of a = non-starter. It assumes that clients even can be expired (which requires ti= me-based processing of a client, not something most AS's are set up to do t= oday, though it's far from impossible). And an in-browser client is likely to be bound to the user session. Would = the client be allowed to refresh that value on an Update call in order to e= xtend its lifetime, too? 

If you want to define an extension for it (or even try it out inside o= f BB+), I think that makes the most sense.

 -- Justin

On May 24, 2013, at 4:40 PM, Josh Mandel <jmandel@gmail.com>
 wrote:

I expect this is a non-starter, but dyn-reg could&n= bsp;allow the client ti include a "please expire me in xx min&quo= t; flag in the registration request (avoiding need for explicit cleanup lat= er).

  -J

On Fri, May 24, 2013 at 1:36 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
I agree with Josh, and I believe that t= his kind of application should definitely be supported. One of my goals wit= h the Dynamic Registration draft was to make it so that it could be used fo= r all the various flavors of OAuth that people are using today. But that said, I'm not at all against giving = guidance to how and where to use it with these various flavors. 

And regarding the DOS, one thing that the RESTful API here gives us is= a means for well-behaved clients to clean up after themselves, where possi= ble. Say the Blood Pressure Grapher is done with its session, it can call t= he Client Configuration Endpoint and DELETE itself, helping mitigate a flood of one-time-use client_ids. Do= esn't necessarily help the case where the clients can't (or won't) clean up= after themselves, or with a deliberate DOS, but there's a security conside= ration about throttling the registration endpoint already. Perhaps we should have something about "if the clie= nt_id hasn't been used in any grants in some amount of time, the AS should = throw it away". But how long that is and at what level of client_id ov= erpopulation the AS starts to care is way outside of the spec. 

 -- Justin

On May 24, 2013, at 4:21 PM, Josh Mandel <jmandel@gmail.com>
 wrote:

I think this discussion mixes two separable questions:

1. Should dyn-reg support client-side browser-based apps (which need &nb= sp;client_ids for each AS they talk to, even if they only talk briefly and = then throw the credentials away)?

2. Which authorization flows are available to clients?

I have examples of client-side browser-based apps that fetch blood press= ure values from the BlueButton+ API, and do some calculations / visuali= zations.  These apps need to run against any of a large collection of = data holders (all of whom implement the same API endpoints), and may learn about new data holders in realtime from an e= nd-user.

If we believe this kind of app is a valid use case for dyn reg (Q. #1), = then whether it uses Implicit or Code flow (Q. #2) has no bearing on the ov= erall set of concerns you raise. (Unintentional DOS, for example, is no les= s an issue with the code flow, for browser-based apps that need a throwaway client_id for brief interactions.= ) And from an app developer's perspective, Implicit flow is simpler and bet= ter captures the semantics of a public client.

Thoughts?

  -Josh

On May 24, 2013 11:35 AM, "Phil Hunt" = <phil.hunt@ora= cle.com> wrote:
I wanted to bring out a quick discussion to ask the question if it makes se= nse to support implicit clients in dynamic registration.

By definition, implicit clients are unauthenticated. Therefore the only pur= pose to register an implicit client is to obtain a client_id with a particu= lar AS instance.

A few issues to consider:
* Implicit clients typically run in browsers (javascript). Do we really wan= t each occurrence of a browser running a client to register?
   --> This could mean even the same browser running implicit = flow repeat times, would register repeatedly.
   --> If registration occurs per occurrence, what is the valu= e?

* What use cases typically occur for deployment against different AS and Re= source API instances?
   --> Eg. I can see a javascript component of a web site that= uses a corresponding resource API.  So it may be possible that the ja= vascript and the resource API are running in the same domain.   In thi= s case, the javascript code, though written as part of a shared library/distribution, is still bound to a configured AS deploymen= t.  Is it really dynamic? If this is the case, wouldn't an OOB registr= ation that updates the client_id in the deployment be better suited?
   --> Are there any examples of javascript clients that need = to connect to one or more AS servers on a truly dynamic basis?

* Is there a DOS attack possible (even unintentionally) because implicit cl= ients will start to register frequently creating huge numbers of client_ids= that cause spin-off provisioning issues depending on how AS registration, = token, and policy systems are implemented?

Apparently OIDC and UMA had these profiles supported before, but I'm really= trying to understand why implicit clients should have dynamic registration= support.  Would appreciate any discussion on this.  At minimum, = there are probably some security considerations we need to think through and document.

Thanks for your comments,

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





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



--_000_12DD95B4EBA74771B73C51013D658715mitreorg_-- From ve7jtb@ve7jtb.com Fri May 24 14:39:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B121F95EE for ; Fri, 24 May 2013 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+wafZjIryal for ; Fri, 24 May 2013 14:39:12 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 293D721F8EF2 for ; Fri, 24 May 2013 14:39:11 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c13so13343653ieb.24 for ; Fri, 24 May 2013 14:39:11 -0700 (PDT) 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=81e3P6+5sU/8nL8tXg/NKP97gt2PHlzpomvXmsaFAto=; b=MWjGoGWbe974y8DBlFXK83D7XgDg8qiR7hQ1Ns2B1mh8q/6Gf9VROeD0QS93I7eIy1 g6fRTHTJcIGwcaGsdEorcOuayrd2rx595+H8r1JYy7gJ7eEg5via1C8/F162CN7a6p3l 5IH4dbMOYPPQqRFGiAO9LJqvzwA5PgfqbRmj9l8WzyGqU9Qqfx6MdneFiXVUkuqFMG3y m/OmjQ0o/wSj5id/QzJbfFdDKBHw7BoyDk3kLM/PibSvf31RAgji12/HVkVhCKbL8XWG 1m8uZ4OyTd/i6WK6EA84742kSrVImVHDnWPSAUl6rRRKnkI/p+uz2budGy1iTLsWYffS MrQg== X-Received: by 10.50.44.33 with SMTP id b1mr488500igm.97.1369431551580; Fri, 24 May 2013 14:39:11 -0700 (PDT) Received: from [192.168.1.36] (190-20-12-1.baf.movistar.cl. [190.20.12.1]) by mx.google.com with ESMTPSA id d4sm1207922igc.3.2013.05.24.14.39.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 14:39:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7B8FF291-9331-4203-88EB-4205CD8B767F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> Date: Fri, 24 May 2013 17:38:58 -0400 Message-Id: <96A405B0-058E-4E9E-B6F9-E4E80256BB1F@ve7jtb.com> References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmh4yVDI8mw/n6Xd9pllKANpCGmvlQ+/wO+n5mXQuTVR2VgTVlGtMS56Z/Gylj9yDGk0dw+ Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 21:39:13 -0000 --Apple-Mail=_7B8FF291-9331-4203-88EB-4205CD8B767F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phil, I think the horse is out of the barn on implicit flow. Many websites use implicit rather than code now, it is no worse, and = perhaps better than using code flow with a client that is not = confidential( though Dynamic registration can dix the public client code = flow problem for native apps etc) Implicit as you well know relies on registration of the redirect URI to = identify the client. There may be multiple JS apps in browsers all = using JS from the same redirect URI, but I don't think that should = preclude the backend website from using an API to register. =20 Turning off dynamic registration entirely for implicit flow is overkill. = A registration server is free to not allow dynamic registration of = implicit clients if that is it's policy. In general I have a hard time seeing implicit clients with a server = component using dynamic registration directly. I suppose there may be = HTML5 based clients that are loaded as browser extensions and use = implicit, without having a server based redirect. Those can be as long = lived as any native app. If clean up is an issue it is one for code = flow as well. John B. On 2013-05-24, at 2:35 PM, Phil Hunt wrote: > I wanted to bring out a quick discussion to ask the question if it = makes sense to support implicit clients in dynamic registration. >=20 > By definition, implicit clients are unauthenticated. Therefore the = only purpose to register an implicit client is to obtain a client_id = with a particular AS instance. >=20 > A few issues to consider: > * Implicit clients typically run in browsers (javascript). Do we = really want each occurrence of a browser running a client to register? > --> This could mean even the same browser running implicit flow = repeat times, would register repeatedly. > --> If registration occurs per occurrence, what is the value? >=20 > * What use cases typically occur for deployment against different AS = and Resource API instances? > --> Eg. I can see a javascript component of a web site that uses a = corresponding resource API. So it may be possible that the javascript = and the resource API are running in the same domain. In this case, the = javascript code, though written as part of a shared = library/distribution, is still bound to a configured AS deployment. Is = it really dynamic? If this is the case, wouldn't an OOB registration = that updates the client_id in the deployment be better suited? > --> Are there any examples of javascript clients that need to = connect to one or more AS servers on a truly dynamic basis? >=20 > * Is there a DOS attack possible (even unintentionally) because = implicit clients will start to register frequently creating huge numbers = of client_ids that cause spin-off provisioning issues depending on how = AS registration, token, and policy systems are implemented? >=20 > Apparently OIDC and UMA had these profiles supported before, but I'm = really trying to understand why implicit clients should have dynamic = registration support. Would appreciate any discussion on this. At = minimum, there are probably some security considerations we need to = think through and document. >=20 > Thanks for your comments, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7B8FF291-9331-4203-88EB-4205CD8B767F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI0MjEzODU5WjAjBgkqhkiG9w0BCQQxFgQUC75kvwD5 TIT6dcF/cLBNDAdVkvgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAiKxsIk4A48tUSxMd+GMoH2kBE+i/pZ+IOKif9gqn SlB8GHe1KWQlLun4ujV3w1X9u9iJYLR869GoygJk2OS/4IjhPLmEKh0AwevFxYw2buNshNXgd/GZ UpdifWl5rY8PjzOVIeotHajlmYYuF6KBT2CM7tu8IfFusPXnhW5l/K1FMuTnaNuSsczLDszhVaxl L186ixA5yQReKGItZ1+rliCel3cd6vYaId/vxzOMPsemQclHcigXuBoGFmDr9VGQqiVMWDvcepbJ LWQrN0P81i783WA2lsnetZmWh+IA0WK5PhaAAR5MWSL8S1wC44dcvQlXahEyZuMUB74EIqOTJgAA AAAAAA== --Apple-Mail=_7B8FF291-9331-4203-88EB-4205CD8B767F-- From ve7jtb@ve7jtb.com Fri May 24 14:55:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9D11E8128 for ; Fri, 24 May 2013 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeSB31giI0wb for ; Fri, 24 May 2013 14:55:04 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AB18921F9671 for ; Fri, 24 May 2013 14:55:03 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so13532920iec.20 for ; Fri, 24 May 2013 14:54:59 -0700 (PDT) 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=+0DaezbWJUmKn3cUwPdTlETzr7NAff+hQ1kR9doSEtA=; b=Lm3gxEIywV3CLqJBK3qmZmZafAJz204lE3hrHR4IgJrZAxMhz85DmXJ0QMfPj6XmXy GuAZkdubTVUEdzrlg46k5QKTRNM1rA3Z3WvHN4iULShSC3O+o8E/UlL9u0mnE9VGLHqM PHQm7Ux397GbVzG1NsisDYzZhMCI1T5bCSXefuZadrhXmHDATvlnb04kkENdZqOqrdNR gvK8Hf7g1zX6hyHeBaJ+2l/1Ufb9miPyNe+h0Qk+KW576xbLNj5jVDsWeHIlHaNjodVo dp/C66y2+bCBcEU8cLntQ+r1h519RtDwiDDRS+RugHzI8P43cCxKq94vn+F534aUjma9 27lQ== X-Received: by 10.50.57.76 with SMTP id g12mr517058igq.81.1369432499688; Fri, 24 May 2013 14:54:59 -0700 (PDT) Received: from [192.168.1.36] (190-20-12-1.baf.movistar.cl. [190.20.12.1]) by mx.google.com with ESMTPSA id l14sm1223379igf.9.2013.05.24.14.54.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 14:54:56 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_84365DE2-B3B6-4B76-8CF7-6ED775C15736"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> Date: Fri, 24 May 2013 17:54:47 -0400 Message-Id: References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkFsrpZ0Ae+FLcGFfpjBmnAkJdXgphY7+BJ96o+Ze8NpJKHnmqh/QayjsVEMnPYKzusYFAX Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 21:55:05 -0000 --Apple-Mail=_84365DE2-B3B6-4B76-8CF7-6ED775C15736 Content-Type: multipart/alternative; boundary="Apple-Mail=_DF8EA53A-55A2-49D5-84D2-FF5FD33318FF" --Apple-Mail=_DF8EA53A-55A2-49D5-84D2-FF5FD33318FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Justin. If you want tight authentication on the AS that issues the tokens we can = use OAuth for that with short lived tokens granted based on a SAML SSO , = PIV card or whatever floats your boat for authentication. How the tokens are issued to the OAuth client doing the registration = (not the OAuth client being registered) is up to the AS running the = registration endpoint. They are OAuth tokens and you can cram an = assertion in them if you like. =20 Dynamic registration for OAuth should be built with OAuth! =20 John B. On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: > I completely disagree with this assessment. The latest draft (which = was just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line. >=20 > On May 24, 2013, at 4:02 PM, Phil Hunt > wrote: >=20 >> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >> 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. >>=20 >=20 > The Client Registration Endpoint is an OAuth Protected Resource. This = token is a means for authorizing calls to the endpoint. Can you use it = for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But = fundamentally, it's just another token that's scoped to one endpoint for = a specific purpose. >=20 >> The use case is very important since it opens the door for a way for = trusted entities to sign assertions that could be accepted by a set of = deployed authorization servers. For potential software API developers = (e.g. Oracle CRM), the developer could potentially register with Oracle = CRMs registration service manually, and obtain a signed assertion for = use in their client software. Upon initiating dynamic registration, the = client software would present the assertion as its initial authorization = in the HTTP Authorization header as Justin describes above. >>=20 >> While this has worked in practice so far, I am concerned about this = assertion being presented in this way. >>=20 >> The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. = Here's where I get worried. >>=20 >> 1. The assertion being presented is not an Authn assertion. There is = no "authentication session" tied to the assertion >=20 > That's fine. Not all OAuth tokens are authentication assertions today, = and this is just another OAuth token.=20 >=20 >> 2. The assertion isn't an authentication, but rather signed client = metadata. >=20 > If you want to interpret the token as both authorization to call the = registration endpoint as well as client metadata, you can do that. But = you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what = you can do with an OAuth token already. You can use an OAuth token as an = opaque blob, or you can define structure, signatures, etc., to pack = information inside of it. If the two always had to be together, then = OAuth would be defined with JWTs only and we'd have something that was = much less useful. >=20 >> 3. The bearer assertion is easily copied. Thus the server should = only trust this as metadata >=20 > Depends on the kind of client, and with BB+ we've defined a matrix of = client types with different policy rules (since we can control policy in = BB+ land). Our discovery and registry setup lets us enforce these rules = appropriately as well. >=20 >> 4. It ends up performing the same role as software_id >=20 > Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another = difference is that a bearer token isn't generally self-asserted, and = it's assumed the registration server will have some means of validating = this token, like it would with any OAuth token. It's more like you can = use the Initial Registration Token to fulfill the same role that you're = suggesting software_id be used for, which, to me, is more of an argument = against the more-limited software_id than it is against the existing = technology. >=20 >>=20 >> While I think it is ok for existing implementations to continue with = this practice, I would prefer to standardize passing of client software = assertion metadata outside of the authentication channel in HTTP. >=20 > The token in question is fundamentally an authorization mechanism for = calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration. >=20 >>=20 >> A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic. >=20 > You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 >=20 >>=20 >> My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this. >=20 > It's an OAuth token. You use whatever HTTP security systems that you = already have to process OAuth tokens on it. If you also want to use it = to tell you something about client metadata, you're going to have to = define further processing, yes, because "an OAuth token" doesn't tell = you anything about what's inside of it or what the token means -- on = purpose. But you'd have to do the same thing with software_id. But = nothing is saying that you need to do that, or that it has to be an = assertion at all. Maybe you just want to lock down your API to know = developers, so you issue them hex blobs to call the API with. Those = could expire 5 minutes from when you issued them, if you wanted. Or they = could be SAML blobs, or JWTs, or anything else that can pass for an = OAuth token. There's no reason any of this should be disallowed by the = registration spec, because the registration spec doesn't care. All it = cares about is that it's an OAuth token and it's (somehow) validated by = the registration endpoint in such a way that the HTTP call to the = Registration Endpoint is valid. This is absolutely bog-standard OAuth = Protected Resource here. By defining it as an OAuth token (and no = further), we immediately gain all of the flexibility and power of OAuth = tokens.=20 >=20 >>=20 >> If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open. >=20 > I still think that software_id is really only useful and interoperable = in the presence of strict rules, which is why I'm not convinced it = belongs in the draft as is and instead belongs in an extension that = defines such rules. This draft would be way beyond the two paragraphs = that you had spoken of previously, and it would be both useful and = interoperable. But it's enough complexity and enough of a very specific = corner case that I am not at all comfortable putting that level of = processing into the dynamic registration draft. I am willing to put = software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. >=20 > -- Justin >=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DF8EA53A-55A2-49D5-84D2-FF5FD33318FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree with Justin.

If you want tight authentication = on the AS that issues the tokens we can use OAuth for that with short = lived tokens granted based on a SAML SSO , PIV card or whatever floats = your boat for authentication.
How the tokens are issued to the = OAuth client doing the registration (not the OAuth client being = registered) is up to the AS running the registration endpoint.   = They are OAuth tokens and you can cram an assertion in them if you like. =  

Dynamic registration for OAuth should be = built with OAuth!  

John = B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> = wrote:

I completely disagree with this assessment. The latest draft (which was = just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential = covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped = to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers.  For potential software API = developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a = signed assertion for use in their client software.  Upon initiating = dynamic registration, the client software would present the assertion as = its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this = assertion being presented in this way.

The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. =  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed = client metadata.

If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can = use an OAuth token as an opaque blob, or you can define structure, = signatures, etc., to pack information inside of it. If the two always = had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server = should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't = generally self-asserted, and it's assumed the registration server will = have some means of validating this token, like it would with any OAuth = token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be = used for, which, to me, is more of an argument against the more-limited = software_id than it is against the existing technology.


While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP.

The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from registration.


A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic.

You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 


My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this.

It's an OAuth token. You use whatever HTTP security systems that = you already have to process OAuth tokens on it. If you also want to use = it to tell you something about client metadata, you're going to have to = define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or = what the token means -- on purpose. But you'd have to do the same thing = with software_id. But nothing is saying that you need to do that, or = that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them = hex blobs to call the API with. Those could expire 5 minutes from when = you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or = anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration = spec, because the registration spec doesn't care. All it cares about is = that it's an OAuth token and it's (somehow) validated by the = registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard = OAuth Protected Resource here. By defining it as an OAuth token (and no = further), we immediately gain all of the flexibility and power of OAuth = tokens. 


If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be = both useful and interoperable. But it's enough complexity and enough of = a very specific corner case that I am not at all comfortable putting = that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a = hook to some future-to-be-defined specification that tells you how to = validate it and parse it and use it for validating client metadata and = tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd = really break anything if it went in and you thought you could use it to = bootstrap your process.

 -- Justin

_______________________________________________
OAuth mailing 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=_DF8EA53A-55A2-49D5-84D2-FF5FD33318FF-- --Apple-Mail=_84365DE2-B3B6-4B76-8CF7-6ED775C15736 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI0MjE1NDQ3WjAjBgkqhkiG9w0BCQQxFgQUcqQvP1ha 5AC5sQcjsT03wgHkj/gwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAHFm7CI5il9hbZqR9aleV6Yfy4WTE7EhPQ7Eo5/Vd GOX0I17O9zh62mPg3biB8LGrxSvElCKLAsayFG8uY00N3B9s9lSaqMaSc3YkcB2UrmQ5hmhAQIAE 0Wsvjo3ZILvS75lFaG5bTf+NsmX28GzUpz/LzFEQLG9yTuSXN8zKT2FixaYHP2H0JvEcukTA6a5j vX70dhBl5WnSze3R2UKgKKEH5+xbFRQWkfIugjScKUmOj0AbL8VPa8+iFZ+w8SWbhx9O0Rogw/gC +JkUnpvcWKQxcniOfAikIAwVWoBETm51HEubRB9KnxgzZPsnYbVZjpf4wJJ4xs0pNbWjkXDaYwAA AAAAAA== --Apple-Mail=_84365DE2-B3B6-4B76-8CF7-6ED775C15736-- From phil.hunt@oracle.com Fri May 24 15:16:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF6D21F8A74 for ; Fri, 24 May 2013 15:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmxY0j5HAHBA for ; Fri, 24 May 2013 15:16:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C021F8CF4 for ; Fri, 24 May 2013 15:16:19 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4OMGGNM008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 May 2013 22:16:17 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OMGGbW000832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2013 22:16:17 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OMGGOD000828; Fri, 24 May 2013 22:16:16 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2013 15:16:16 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A830612C-014A-4E2C-A83E-9275B2A5C469" From: Phil Hunt In-Reply-To: Date: Fri, 24 May 2013 15:16:14 -0700 Message-Id: <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 22:16:25 -0000 --Apple-Mail=_A830612C-014A-4E2C-A83E-9275B2A5C469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-24, at 2:54 PM, John Bradley wrote: > I agree with Justin. >=20 > If you want tight authentication on the AS that issues the tokens we = can use OAuth for that with short lived tokens granted based on a SAML = SSO , PIV card or whatever floats your boat for authentication. [PH] I don't want tight authn. This is *registration*. Yet we are = pretending we are authenticating when we aren't. > How the tokens are issued to the OAuth client doing the registration = (not the OAuth client being registered) is up to the AS running the = registration endpoint. They are OAuth tokens and you can cram an = assertion in them if you like. =20 [PH] This is nothing to do with my point here. >=20 > Dynamic registration for OAuth should be built with OAuth! =20 [PH] Well I was going to bring that up but didn't want to freak people = out. The idea you refer to was why not use oauth to issue an access = token to registration server. But that just makes people's head = explode. >=20 > John B. > On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: >=20 >> I completely disagree with this assessment. The latest draft (which = was just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line. >>=20 >> On May 24, 2013, at 4:02 PM, Phil Hunt >> wrote: >>=20 >>> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >>> 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. >>>=20 >>=20 >> The Client Registration Endpoint is an OAuth Protected Resource. This = token is a means for authorizing calls to the endpoint. Can you use it = for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But = fundamentally, it's just another token that's scoped to one endpoint for = a specific purpose. >>=20 >>> The use case is very important since it opens the door for a way for = trusted entities to sign assertions that could be accepted by a set of = deployed authorization servers. For potential software API developers = (e.g. Oracle CRM), the developer could potentially register with Oracle = CRMs registration service manually, and obtain a signed assertion for = use in their client software. Upon initiating dynamic registration, the = client software would present the assertion as its initial authorization = in the HTTP Authorization header as Justin describes above. >>>=20 >>> While this has worked in practice so far, I am concerned about this = assertion being presented in this way. >>>=20 >>> The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. = Here's where I get worried. >>>=20 >>> 1. The assertion being presented is not an Authn assertion. There = is no "authentication session" tied to the assertion >>=20 >> That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token.=20 >>=20 >>> 2. The assertion isn't an authentication, but rather signed client = metadata. >>=20 >> If you want to interpret the token as both authorization to call the = registration endpoint as well as client metadata, you can do that. But = you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what = you can do with an OAuth token already. You can use an OAuth token as an = opaque blob, or you can define structure, signatures, etc., to pack = information inside of it. If the two always had to be together, then = OAuth would be defined with JWTs only and we'd have something that was = much less useful. >>=20 >>> 3. The bearer assertion is easily copied. Thus the server should = only trust this as metadata >>=20 >> Depends on the kind of client, and with BB+ we've defined a matrix of = client types with different policy rules (since we can control policy in = BB+ land). Our discovery and registry setup lets us enforce these rules = appropriately as well. >>=20 >>> 4. It ends up performing the same role as software_id >>=20 >> Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another = difference is that a bearer token isn't generally self-asserted, and = it's assumed the registration server will have some means of validating = this token, like it would with any OAuth token. It's more like you can = use the Initial Registration Token to fulfill the same role that you're = suggesting software_id be used for, which, to me, is more of an argument = against the more-limited software_id than it is against the existing = technology. [PH] At minimum, as a UUID it is self asserted and only identifies a = common unique value shared between instances of a particular piece of = software. But there is nothing saying it can't be a JWT signed assertion serving = the function of passing on signed client metadata. The *big* difference is that the processing of the token occurs within = the registration endpoint. The ONLY endpoint that should accept this. When you stick it in the HTTP Auth header it will likely get processed = by the platform security system which then has to have special handling = code to intercept this custom, undefined, unprofiled token. Of course, you could just bypass platform security on everything=85. >>=20 >>>=20 >>> While I think it is ok for existing implementations to continue with = this practice, I would prefer to standardize passing of client software = assertion metadata outside of the authentication channel in HTTP. >>=20 >> The token in question is fundamentally an authorization mechanism for = calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration. [PH] What you are passing in Blue Button is a software assertion. It's = not an authorization or an authentication. Authorization would have to = be issued locally. Authentication, could be federated, but there are no = authn statements are there. So it is a bearer software assertion. The = only reason it is better than UUID is that we can evaluate trust of a = third party with regards to the statements contained. =20 >>=20 >>>=20 >>> A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic. >>=20 >> You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 [PH] I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local? =20 >>=20 >>>=20 >>> My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this. >>=20 >> It's an OAuth token. [PH[ NO IT IS NOT. The token is issued by a third party provider. = Besides when someone says "OAuth Token" I take that to mean an ACCESS = token. If it is anything else it is just a JWT or SAML token. >> You use whatever HTTP security systems that you already have to = process OAuth tokens on it. If you also want to use it to tell you = something about client metadata, you're going to have to define further = processing, yes, because "an OAuth token" doesn't tell you anything = about what's inside of it or what the token means -- on purpose. But = you'd have to do the same thing with software_id. But nothing is saying = that you need to do that, or that it has to be an assertion at all. = Maybe you just want to lock down your API to know developers, so you = issue them hex blobs to call the API with. Those could expire 5 minutes = from when you issued them, if you wanted. Or they could be SAML blobs, = or JWTs, or anything else that can pass for an OAuth token. There's no = reason any of this should be disallowed by the registration spec, = because the registration spec doesn't care. All it cares about is that = it's an OAuth token and it's (somehow) validated by the registration = endpoint in such a way that the HTTP call to the Registration Endpoint = is valid. This is absolutely bog-standard OAuth Protected Resource here. = By defining it as an OAuth token (and no further), we immediately gain = all of the flexibility and power of OAuth tokens.=20 [PH} Sure what you suggest can and will work. But it is 10x more complex = architecturally. =20 >>=20 >>>=20 >>> If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open. >>=20 >> I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the = two paragraphs that you had spoken of previously, and it would be both = useful and interoperable. But it's enough complexity and enough of a = very specific corner case that I am not at all comfortable putting that = level of processing into the dynamic registration draft. I am willing to = put software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. [PH] =20 1. What rules do you need around a UUID? It is JUST a unique = identifier. 2. If an assertion, how is it *any* different from intial client = assertion other than the component of the server that must process it? As I said, if you make it part of authentication, then complexity = increases and therefore we would have to tightly profile the assertion = so that token authentication system will accept these federated tokens. If you leave it as part of software_id, then we can be more informal (to = a point). I can't help this, it is just the way servers are made. The horse has = left the barn as John says. >>=20 >> -- Justin >>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A830612C-014A-4E2C-A83E-9275B2A5C469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

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





On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with = Justin.

If you want tight authentication on the AS = that issues the tokens we can use OAuth for that with short lived tokens = granted based on a SAML SSO , PIV card or whatever floats your boat for = authentication.

[PH] I don't want = tight authn. This is *registration*. Yet we are pretending we are = authenticating when we aren't.

How the tokens are = issued to the OAuth client doing the registration (not the OAuth client = being registered) is up to the AS running the registration endpoint. =   They are OAuth tokens and you can cram an assertion in them if = you like.  

[PH] This is = nothing to do with my point here.

Dynamic = registration for OAuth should be built with OAuth! =  
[PH]  Well I was going to bring that = up but didn't want to freak people out. The idea you refer to was why = not use oauth to issue an access token to registration server.  But = that just makes people's head explode.


John = B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> = wrote:

I completely disagree with this assessment. The latest draft (which was = just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential = covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped = to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers.  For potential software API = developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a = signed assertion for use in their client software.  Upon initiating = dynamic registration, the client software would present the assertion as = its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this = assertion being presented in this way.

The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. =  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed = client metadata.

If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can = use an OAuth token as an opaque blob, or you can define structure, = signatures, etc., to pack information inside of it. If the two always = had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server = should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't = generally self-asserted, and it's assumed the registration server will = have some means of validating this token, like it would with any OAuth = token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be = used for, which, to me, is more of an argument against the more-limited = software_id than it is against the existing = technology.

[PH] At minimum, as a UUID it is self asserted and = only identifies a common unique value shared between instances of a = particular piece of software.

But there is = nothing saying it can't be a JWT signed assertion serving the function = of passing on signed client metadata.

The *big* = difference is that the processing of the token occurs within the = registration endpoint. The ONLY endpoint that should accept = this.

When you stick it in the HTTP Auth header = it will likely get processed by the platform security system which then = has to have special handling code to intercept this custom, undefined, = unprofiled token.

Of course, you could just = bypass platform security on everything=85.


While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP.

The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration.

[PH] What you are passing in Blue Button is a = software assertion.  It's not an authorization or an = authentication.  Authorization would have to be issued locally. =  Authentication, could be federated, but there are no authn = statements are there.  So it is a bearer software assertion. =  The only reason it is better than UUID is that we can evaluate = trust of a third party with regards to the statements contained. =  


A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic.

You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 

[PH]  I think the whole point of having an = "initial authentication assertion" is that it is federated -- generated = by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this.

It's an OAuth = token.
=

[PH[ NO IT IS NOT.  The token is issued by a third = party provider.  Besides when someone says "OAuth Token" I take = that to mean an ACCESS token.  If it is anything else it is just a = JWT or SAML token.

You use = whatever HTTP security systems that you already have to process OAuth = tokens on it. If you also want to use it to tell you something about = client metadata, you're going to have to define further processing, yes, = because "an OAuth token" doesn't tell you anything about what's inside of it or = what the token means -- on purpose. But you'd have to do the same thing = with software_id. But nothing is saying that you need to do that, or = that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them = hex blobs to call the API with. Those could expire 5 minutes from when = you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or = anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration = spec, because the registration spec doesn't care. All it cares about is = that it's an OAuth token and it's (somehow) validated by the = registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard = OAuth Protected Resource here. By defining it as an OAuth token (and no = further), we immediately gain all of the flexibility and power of OAuth = tokens. 

[PH} Sure what you suggest can and will work. But = it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be = both useful and interoperable. But it's enough complexity and enough of = a very specific corner case that I am not at all comfortable putting = that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a = hook to some future-to-be-defined specification that tells you how to = validate it and parse it and use it for validating client metadata and = tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd = really break anything if it went in and you thought you could use it to = bootstrap your = process.

[PH]  
1. What rules do you need around = a UUID?  It is JUST a unique identifier.
2. If an = assertion, how is it *any* different from intial client assertion other = than the component of the server that must process = it?

As I said, if you make it part of = authentication, then complexity increases and therefore we would have to = tightly profile the assertion so that token authentication system will = accept these federated tokens.

If you leave it = as part of software_id, then we can be more informal (to a = point).

I can't help this, it is just the way = servers are made.  The horse has left the barn as John = says.

 -- Justin

_______________________________________________
OAuth mailing 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=_A830612C-014A-4E2C-A83E-9275B2A5C469-- From sakimura@gmail.com Fri May 24 16:26:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83911E80D2 for ; Fri, 24 May 2013 16:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-PsIQwhl1ha for ; Fri, 24 May 2013 16:26:30 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1C21F9048 for ; Fri, 24 May 2013 16:26:29 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ea20so4918227lab.26 for ; Fri, 24 May 2013 16:26:28 -0700 (PDT) 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=VHEt/ogYREnTgS1kr2X4O6MpSCBKtR2AUroFrQEnlPU=; b=rdh34IzB/XTjuPmNWNGlpDhsDV4iiNzoJ5qNEo6UnRtQmenHXGq9KZdanT86nOMrWH GvJaUi1E1s8kuhFb2krZHwvjnIuIC7sES4Dex3QuLwQj+CtuZ2csG4zqRvE+vmkaB1yR JxpTe6X5//enb+US1/b4g9eYpAV58XsGpzr+0P4khwju/myI9SyJ7oGTLbySNEpG+/X/ tf2Ayxd9d3W+FsbcmC/qZV/c53mX6ua4uezm09tlcdS1yWjS+uc5pUvqOV19iRlr+MPz 3zpitxRhB7ncif4KB0Oeuz8ZlKrwIs6gs46OCnJeOlXQjuv6C5gAdjV4myUHyhNvRm+b AK5w== X-Received: by 10.152.45.33 with SMTP id j1mr9977831lam.29.1369437988243; Fri, 24 May 2013 16:26:28 -0700 (PDT) References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> Date: Sat, 25 May 2013 08:26:22 +0900 Message-ID: <-6944393266323949592@unknownmsgid> To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c27c3ad4cf4904dd7f20d5 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2013 23:26:32 -0000 --001a11c27c3ad4cf4904dd7f20d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =3Dnat via iPhone May 25, 2013 7:16=E3=80=81Phil Hunt wrote: On 2013-05-24, at 2:54 PM, John Bradley wrote: I agree with Justin. If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication. [PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't. It is not authentication. It is an access authorization to this API. How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint. They are OAuth tokens and you can cram an assertion in them if you like. [PH] This is nothing to do with my point here. Dynamic registration for OAuth should be built with OAuth! [PH] Well I was going to bring that up but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server. But that just makes people's head explode. John B. On 2013-05-24, at 5:01 PM, "Richer, Justin P." wrote: I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line. On May 24, 2013, at 4:02 PM, Phil Hunt wrote: I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 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. The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose. The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers. For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software. Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above. While this has worked in practice so far, I am concerned about this assertion being presented in this way. The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server. Here's where I get worried. 1. The assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 2. The assertion isn't an authentication, but rather signed client metadata. If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful. 3. The bearer assertion is easily copied. Thus the server should only trust this as metadata Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well. 4. It ends up performing the same role as software_id Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology. [PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software. But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata. The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this. When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token. Of course, you could just bypass platform security on everything=E2=80=A6. *While I think it is ok for existing implementations to continue with this practice*, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP. The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration. [PH] What you are passing in Blue Button is a software assertion. It's not an authorization or an authentication. Authorization would have to be issued locally. Authentication, could be federated, but there are no authn statements are there. So it is a bearer software assertion. The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained. A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic= . You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. [PH] I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local? My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this. It's an OAuth token. [PH[ NO IT IS NOT. The token is issued by a third party provider. Besides when someone says "OAuth Token" I take that to mean an ACCESS token. If it is anything else it is just a JWT or SAML token. You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. [PH} Sure what you suggest can and will work. But it is 10x more complex architecturally. If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open. I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process. [PH] 1. What rules do you need around a UUID? It is JUST a unique identifier. 2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it? As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens. If you leave it as part of software_id, then we can be more informal (to a point). I can't help this, it is just the way servers are made. The horse has left the barn as John says. -- Justin Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a11c27c3ad4cf4904dd7f20d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=3Dnat via iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com> =C2=A0wrote:=C2=A0


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on= the AS that issues the tokens we can use OAuth for that with short lived t= okens granted based on a SAML SSO , PIV card or whatever floats your boat f= or authentication.

[PH] I don't want tight authn. This i= s *registration*. Yet we are pretending we are authenticating when we aren&= #39;t.

It is not authentication.=C2=A0 It is an access authorization to this API.=C2=A0

<= blockquote type=3D"cite">

How the tokens are issued to the OAuth = client doing the registration (not the OAuth client being registered) is up= to the AS running the registration endpoint. =C2=A0 They are OAuth tokens = and you can cram an assertion in them if you like. =C2=A0

[PH] This is nothing to do with my point = here.

Dynamic registration for OAuth should be built with OAuth! = =C2=A0
[PH] =C2=A0Well I was going to bring that up but didn= 9;t want to freak people out. The idea you refer to was why not use oauth t= o issue an access token to registration server. =C2=A0But that just makes p= eople's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Riche= r, Justin P." <jricher@mitre.o= rg> wrote:

I completely disagree with this assessment. The latest draft (which was jus= t posted) has new language describing what this token is and what it's = for, and I hope that will clear things up. But even so, let me try to addre= ss your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
=C2=A0wrote:

I have been struggling with the concept of an initial client credential cov= ered in the current draft (rev 10): 
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.

The Client Registration Endpoint is an OAuth Protected Resource. This = token is a means for authorizing calls to the endpoint. Can you use it for = other things? Sure, just like you can use OAuth tokens for other things (pa= ssing data about authentication, for instance). But fundamentally, it's just another token that's s= coped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for t= rusted entities to sign assertions that could be accepted by a set of deplo= yed authorization servers. =C2=A0For potential software API developers (e.g= . Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a sign= ed assertion for use in their client software. =C2=A0Upon initiating dynami= c registration, the client software would present the assertion as its init= ial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this as= sertion being presented in this way.

The authentication header has special meaning to many servers. Dependi= ng on implementation architecture, the authorization header will first be i= ntercepted by the authentication components in the server. =C2=A0Here's= where I get worried.

1. =C2=A0The assertion being presented is not an Authn assertion. Ther= e is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions to= day, and this is just another OAuth token.=C2=A0

2. =C2=A0The assertion isn't an authentication, but rather signed = client metadata.

If you want to interpret the token as both authorization to call the r= egistration endpoint as well as client metadata, you can do that. But you&#= 39;re going to have to define how that metadata is passed, how it's sig= ned, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use = an OAuth token as an opaque blob, or you can define structure, signatures, = etc., to pack information inside of it. If the two always had to be togethe= r, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3. =C2=A0The bearer assertion is easily copied. Thus the server should= only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix= of client types with different policy rules (since we can control policy i= n BB+ land). Our discovery and registry setup lets us enforce these rules a= ppropriately as well.

4. =C2=A0It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the hol= der is authorized to make this call? You'd have to put rules around sof= tware_id saying that it needs to be processed in a particular way, and I th= ink such rules are far too restrictive for this draft.=C2=A0Another difference is that a bearer token isn't g= enerally self-asserted, and it's assumed the registration server will h= ave some means of validating this token, like it would with any OAuth token= . It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be u= sed for, which, to me, is more of an argument against the more-limited soft= ware_id than it is against the existing technology.

[PH] At minimum,= as a UUID it is self asserted and only identifies a common unique value sh= ared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed asserti= on serving the function of passing on signed client metadata.
The *big* difference is that the processing of the token occurs= within the registration endpoint. The ONLY endpoint that should accept thi= s.

When you stick it in the HTTP Auth header it will likel= y get processed by the platform security system which then has to have spec= ial handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on e= verything=E2=80=A6.


While I think it is ok for existing implementations to continue wit= h this practice, I would prefer to standardize passing of client softwa= re assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for = calling the registration endpoint. I agree there's value in passing cli= ent software assertions around, and that we should solve that in an interop= erable way, but that's a completely separate question from registration.
<= /div>

[PH] What you are passing in B= lue Button is a software assertion. =C2=A0It's not an authorization or = an authentication. =C2=A0Authorization would have to be issued locally. =C2= =A0Authentication, could be federated, but there are no authn statements ar= e there. =C2=A0So it is a bearer software assertion. =C2=A0The only reason = it is better than UUID is that we can evaluate trust of a third party with = regards to the statements contained. =C2=A0


A further benefit is that the registration endpoint authentication sys= tem only has to deal with locally issued credentials. The logic for handlin= g federated client meta data can be isolated to the registration server log= ic.

You can still do that if your registration server is the one generatin= g the initial access token. Normally, the registration endpoint's going= to be tightly tied to the authorization server, and whatever process is us= ed to get the initial registration token is going to also be tightly tied to the registration server.=C2=A0

= [PH] =C2=A0I think the whole point of having an "initial authenticatio= n assertion" is that it is federated -- generated by third party. Why = would I bother if it is local? =C2=A0


My feeling is that if we keep "initial authorization credential&q= uot; as being passed in the HTTP Authorization header, then strict rules ab= out the contents of the token and the processing rules must be defined so t= hat HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT. =C2=A0The token is = issued by a third party provider. =C2=A0Besides when someone says "OAu= th Token" I take that to mean an ACCESS token. =C2=A0If it is anything= else it is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to pr= ocess OAuth tokens on it. If you also want to use it to tell you something = about client metadata, you're going to have to define further processin= g, yes, because "an OAuth token" doesn't tell you anything about what's inside of= it or what the token means -- on purpose. But you'd have to do the sam= e thing with software_id. But nothing is saying that you need to do that, o= r that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex = blobs to call the API with. Those could expire 5 minutes from when you issu= ed them, if you wanted. Or they could be SAML blobs, or JWTs, or anything e= lse that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration= spec, because the registration spec doesn't care. All it cares about i= s that it's an OAuth token and it's (somehow) validated by the regi= stration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAu= th Protected Resource here. By defining it as an OAuth token (and no furthe= r), we immediately gain all of the flexibility and power of OAuth tokens.= =C2=A0

[PH} Sure what you suggest can and will work. But it is 10x more complex = architecturally. =C2=A0


If we use software_id, and indicate that it can accept a "softwar= e registration assertion", we can be more flexible and minimize the pr= ocessing rules we have to declare in the draft. That said, if there is a ca= se to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable= in the presence of strict rules, which is why I'm not convinced it bel= ongs in the draft as is and instead belongs in an extension that defines su= ch rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both= useful and interoperable. But it's enough complexity and enough of a v= ery specific corner case that I am not at all comfortable putting that leve= l of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook= to some future-to-be-defined specification that tells you how to validate = it and parse it and use it for validating client metadata and tie it to a d= eveloper and all that fun stuff -- I don't personally see the utility in that, but I don't think i= t'd really break anything if it went in and you thought you could use i= t to bootstrap your process.

[PH] =C2=A0
1. What rules= do you need around a UUID? =C2=A0It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion= other than the component of the server that must process it?

As I said, if you make it part of authentication, then = complexity increases and therefore we would have to tightly profile the ass= ertion so that token authentication system will accept these federated toke= ns.

If you leave it as part of software_id, then we can be = more informal (to a point).

I can't help this,= it is just the way servers are made. =C2=A0The horse has left the barn as = John says.

=C2=A0-- Justin

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

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


______________________________= _________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--001a11c27c3ad4cf4904dd7f20d5-- From ve7jtb@ve7jtb.com Fri May 24 17:07:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAC611E812E for ; Fri, 24 May 2013 17:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i552jSq7J2sO for ; Fri, 24 May 2013 17:07:03 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9E621F9540 for ; Fri, 24 May 2013 17:06:50 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so14172167iea.3 for ; Fri, 24 May 2013 17:06:49 -0700 (PDT) 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=aOiJ/uLHx7c+3AZgdru4wB4L1e5QwF4Y9YQPi99HghE=; b=VCfr3Pe8Oott0GpPaCpCqZux3y74brRSM3qCgttqhHaFzqKNruXF5tfzSD5v+WMlXp fzYam3L1KE1ac+hjzEnYM7vwODiwYRLWG5RoQutGoJUwXoOprW7gbGVJCQ952WEZWrUo uX0/EDs0fUi7QBEztsgsK77NtfeNTN3tbNzJjB1WaMm4tkk1HmjJLG1lMZp9l9mNOq1c lZBH/s0db7lwxhSsYyqTaNG7Sap+IZmWq3NLCZuU500cdzaDIr+7Ax3j01mjZ+YDGYEN ellqML68rytp+GXQp33/o9z4VpU+MoMZ+wcyNvq7dptshyQZbfigZY/3nu70o7VqNrFV Gurg== X-Received: by 10.43.68.134 with SMTP id xy6mr13652138icb.48.1369440409713; Fri, 24 May 2013 17:06:49 -0700 (PDT) Received: from [192.168.1.36] (190-20-12-1.baf.movistar.cl. [190.20.12.1]) by mx.google.com with ESMTPSA id p10sm1781548igj.5.2013.05.24.17.06.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 17:06:48 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BA1C9EFE-9D60-48F6-B9CF-FB0C998637FD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <-6944393266323949592@unknownmsgid> Date: Fri, 24 May 2013 20:06:39 -0400 Message-Id: <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> To: Nat Sakimura X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnGM1sNv+6to6ywd8XWwNkdlIZp2SUqQylHAJ9dd7IW9jvIA8xPK2WkhDM2iabXF/CyEM3q Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2013 00:07:05 -0000 --Apple-Mail=_BA1C9EFE-9D60-48F6-B9CF-FB0C998637FD Content-Type: multipart/alternative; boundary="Apple-Mail=_20C1CB9B-0297-41B6-A90A-7EADC9C55E46" --Apple-Mail=_20C1CB9B-0297-41B6-A90A-7EADC9C55E46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phil, The OAuth token used authorize access to the registration endpoint( if = one is required) would be issued by the registration server via some = method eg cut and paste from a developer portal, email or perhaps via = OAuth to a Developer API management application. That is declared = out of scope because the token is optional and there are lots of ways = developers can get them. I see it as a OAuth access token with some scopes attached to it like = any other access token. You seem to be thinking it is something else. = I don't understand what third party would be issuing these tokens. You = seem to have a use case in mind but I don't think I understand it. John B. On 2013-05-24, at 7:26 PM, Nat Sakimura wrote: >=20 >=20 > =3Dnat via iPhone >=20 > May 25, 2013 7:16=E3=80=81Phil Hunt wrote:=20 >>=20 >>=20 >> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>=20 >>> I agree with Justin. >>>=20 >>> If you want tight authentication on the AS that issues the tokens we = can use OAuth for that with short lived tokens granted based on a SAML = SSO , PIV card or whatever floats your boat for authentication. >>=20 >> [PH] I don't want tight authn. This is *registration*. Yet we are = pretending we are authenticating when we aren't. >=20 > It is not authentication.=20 > It is an access authorization to this API.=20 >=20 >>=20 >>> How the tokens are issued to the OAuth client doing the registration = (not the OAuth client being registered) is up to the AS running the = registration endpoint. They are OAuth tokens and you can cram an = assertion in them if you like. =20 >>=20 >> [PH] This is nothing to do with my point here. >>>=20 >>> Dynamic registration for OAuth should be built with OAuth! =20 >> [PH] Well I was going to bring that up but didn't want to freak = people out. The idea you refer to was why not use oauth to issue an = access token to registration server. But that just makes people's head = explode. >>=20 >>>=20 >>> John B. >>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: >>>=20 >>>> I completely disagree with this assessment. The latest draft (which = was just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line. >>>>=20 >>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>> wrote: >>>>=20 >>>>> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >>>>> 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. >>>>>=20 >>>>=20 >>>> The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But = fundamentally, it's just another token that's scoped to one endpoint for = a specific purpose. >>>>=20 >>>>> The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers. For potential software API = developers (e.g. Oracle CRM), the developer could potentially register = with Oracle CRMs registration service manually, and obtain a signed = assertion for use in their client software. Upon initiating dynamic = registration, the client software would present the assertion as its = initial authorization in the HTTP Authorization header as Justin = describes above. >>>>>=20 >>>>> While this has worked in practice so far, I am concerned about = this assertion being presented in this way. >>>>>=20 >>>>> The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. = Here's where I get worried. >>>>>=20 >>>>> 1. The assertion being presented is not an Authn assertion. There = is no "authentication session" tied to the assertion >>>>=20 >>>> That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token.=20 >>>>=20 >>>>> 2. The assertion isn't an authentication, but rather signed = client metadata. >>>>=20 >>>> If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what = you can do with an OAuth token already. You can use an OAuth token as an = opaque blob, or you can define structure, signatures, etc., to pack = information inside of it. If the two always had to be together, then = OAuth would be defined with JWTs only and we'd have something that was = much less useful. >>>>=20 >>>>> 3. The bearer assertion is easily copied. Thus the server should = only trust this as metadata >>>>=20 >>>> Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well. >>>>=20 >>>>> 4. It ends up performing the same role as software_id >>>>=20 >>>> Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another = difference is that a bearer token isn't generally self-asserted, and = it's assumed the registration server will have some means of validating = this token, like it would with any OAuth token. It's more like you can = use the Initial Registration Token to fulfill the same role that you're = suggesting software_id be used for, which, to me, is more of an argument = against the more-limited software_id than it is against the existing = technology. >>=20 >> [PH] At minimum, as a UUID it is self asserted and only identifies a = common unique value shared between instances of a particular piece of = software. >>=20 >> But there is nothing saying it can't be a JWT signed assertion = serving the function of passing on signed client metadata. >>=20 >> The *big* difference is that the processing of the token occurs = within the registration endpoint. The ONLY endpoint that should accept = this. >>=20 >> When you stick it in the HTTP Auth header it will likely get = processed by the platform security system which then has to have special = handling code to intercept this custom, undefined, unprofiled token. >>=20 >> Of course, you could just bypass platform security on everything=E2=80=A6= . >>>>=20 >>>>>=20 >>>>> While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP. >>>>=20 >>>> The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration. >>=20 >> [PH] What you are passing in Blue Button is a software assertion. = It's not an authorization or an authentication. Authorization would = have to be issued locally. Authentication, could be federated, but = there are no authn statements are there. So it is a bearer software = assertion. The only reason it is better than UUID is that we can = evaluate trust of a third party with regards to the statements = contained. =20 >>>>=20 >>>>>=20 >>>>> A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic. >>>>=20 >>>> You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 >>=20 >> [PH] I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local? =20 >>>>=20 >>>>>=20 >>>>> My feeling is that if we keep "initial authorization credential" = as being passed in the HTTP Authorization header, then strict rules = about the contents of the token and the processing rules must be defined = so that HTTP server security systems can be extended to support this. >>>>=20 >>>> It's an OAuth token. >>=20 >> [PH[ NO IT IS NOT. The token is issued by a third party provider. = Besides when someone says "OAuth Token" I take that to mean an ACCESS = token. If it is anything else it is just a JWT or SAML token. >>=20 >>>> You use whatever HTTP security systems that you already have to = process OAuth tokens on it. If you also want to use it to tell you = something about client metadata, you're going to have to define further = processing, yes, because "an OAuth token" doesn't tell you anything = about what's inside of it or what the token means -- on purpose. But = you'd have to do the same thing with software_id. But nothing is saying = that you need to do that, or that it has to be an assertion at all. = Maybe you just want to lock down your API to know developers, so you = issue them hex blobs to call the API with. Those could expire 5 minutes = from when you issued them, if you wanted. Or they could be SAML blobs, = or JWTs, or anything else that can pass for an OAuth token. There's no = reason any of this should be disallowed by the registration spec, = because the registration spec doesn't care. All it cares about is that = it's an OAuth token and it's (somehow) validated by the registration = endpoint in such a way that the HTTP call to the Registration Endpoint = is valid. This is absolutely bog-standard OAuth Protected Resource here. = By defining it as an OAuth token (and no further), we immediately gain = all of the flexibility and power of OAuth tokens.=20 >>=20 >> [PH} Sure what you suggest can and will work. But it is 10x more = complex architecturally. =20 >>>>=20 >>>>>=20 >>>>> If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open. >>>>=20 >>>> I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the = two paragraphs that you had spoken of previously, and it would be both = useful and interoperable. But it's enough complexity and enough of a = very specific corner case that I am not at all comfortable putting that = level of processing into the dynamic registration draft. I am willing to = put software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. >>=20 >> [PH] =20 >> 1. What rules do you need around a UUID? It is JUST a unique = identifier. >> 2. If an assertion, how is it *any* different from intial client = assertion other than the component of the server that must process it? >>=20 >> As I said, if you make it part of authentication, then complexity = increases and therefore we would have to tightly profile the assertion = so that token authentication system will accept these federated tokens. >>=20 >> If you leave it as part of software_id, then we can be more informal = (to a point). >>=20 >> I can't help this, it is just the way servers are made. The horse = has left the barn as John says. >>>>=20 >>>> -- Justin >>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_20C1CB9B-0297-41B6-A90A-7EADC9C55E46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 sakimura@gmail.com> = wrote:


=3Dnat via = iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com> =  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication = on the AS that issues the tokens we can use OAuth for that with short = lived tokens granted based on a SAML SSO , PIV card or whatever floats = your boat for authentication.

[PH] I don't want tight authn. This is = *registration*. Yet we are pretending we are authenticating when we = aren't.

It is not = authentication. 
It is an access authorization to this = API. 


How the tokens are issued to the = OAuth client doing the registration (not the OAuth client being = registered) is up to the AS running the registration endpoint.   = They are OAuth tokens and you can cram an assertion in them if you like. =  

[PH] This is nothing to do with my = point here.

Dynamic registration = for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but = didn't want to freak people out. The idea you refer to was why not use = oauth to issue an access token to registration server.  But that = just makes people's head explode.


John = B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was = just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential = covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped = to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers.  For potential software API = developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a = signed assertion for use in their client software.  Upon initiating = dynamic registration, the client software would present the assertion as = its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this = assertion being presented in this way.

The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. =  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed = client metadata.

If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can = use an OAuth token as an opaque blob, or you can define structure, = signatures, etc., to pack information inside of it. If the two always = had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server = should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't = generally self-asserted, and it's assumed the registration server will = have some means of validating this token, like it would with any OAuth = token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be = used for, which, to me, is more of an argument against the more-limited = software_id than it is against the existing = technology.

[PH] At = minimum, as a UUID it is self asserted and only identifies a common = unique value shared between instances of a particular piece of = software.

But there is nothing saying it can't be a JWT signed = assertion serving the function of passing on signed client = metadata.

The *big* difference is that the = processing of the token occurs within the registration endpoint. The = ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will = likely get processed by the platform security system which then has to = have special handling code to intercept this custom, undefined, = unprofiled token.

Of course, you could just bypass platform security = on everything=E2=80=A6.


While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP.

The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration.

[PH] What you are passing in Blue Button is a software assertion. =  It's not an authorization or an authentication. =  Authorization would have to be issued locally. =  Authentication, could be federated, but there are no authn = statements are there.  So it is a bearer software assertion. =  The only reason it is better than UUID is that we can evaluate = trust of a third party with regards to the statements contained. =  


A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic.

You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 

[P= H]  I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this.

It's an OAuth = token.

[PH[ NO = IT IS NOT.  The token is issued by a third party provider. =  Besides when someone says "OAuth Token" I take that to mean an = ACCESS token.  If it is anything else it is just a JWT or SAML = token.

You use whatever HTTP security = systems that you already have to process OAuth tokens on it. If you also = want to use it to tell you something about client metadata, you're going = to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or = what the token means -- on purpose. But you'd have to do the same thing = with software_id. But nothing is saying that you need to do that, or = that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them = hex blobs to call the API with. Those could expire 5 minutes from when = you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or = anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration = spec, because the registration spec doesn't care. All it cares about is = that it's an OAuth token and it's (somehow) validated by the = registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard = OAuth Protected Resource here. By defining it as an OAuth token (and no = further), we immediately gain all of the flexibility and power of OAuth = tokens. 

[PH} Sure what you = suggest can and will work. But it is 10x more complex architecturally. =  


If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be = both useful and interoperable. But it's enough complexity and enough of = a very specific corner case that I am not at all comfortable putting = that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a = hook to some future-to-be-defined specification that tells you how to = validate it and parse it and use it for validating client metadata and = tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd = really break anything if it went in and you thought you could use it to = bootstrap your process.

[PH]  
1. What = rules do you need around a UUID?  It is JUST a unique = identifier.
2. If an assertion, how is it *any* different from = intial client assertion other than the component of the server that must = process it?

As I said, if you make it part of authentication, = then complexity increases and therefore we would have to tightly profile = the assertion so that token authentication system will accept these = federated tokens.

If you leave it as part of software_id, then we can = be more informal (to a point).

I can't help = this, it is just the way servers are made.  The horse has left the = barn as John says.

 -- Justin

_______________________________________________
OAuth mailing 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=_20C1CB9B-0297-41B6-A90A-7EADC9C55E46-- --Apple-Mail=_BA1C9EFE-9D60-48F6-B9CF-FB0C998637FD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI1MDAwNjM5WjAjBgkqhkiG9w0BCQQxFgQU9So+clXF /a3bsMcdH3v8pd9GzfowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAeenjVHkkXOpuYNLaW8iZ/ewzEQRI1kSZDZ3QExuc ChXluJx17i5YV87u83zGO+/izL9VzEdkiNVh2MvUSsfSqudOP+kLJGns39qAzCHhsAvIRsHYK39D Y1cg/4aOE0LHxoizCf/hYrk3CvCr7m3mtTJCP74999tZUOR5q/UIND7ninJM5bTf9T2zmS/8NmiY 9YUFEQ6/3NHT+2F1aRGamr27Bz8U8wxm3STpfaZuNLnfnH+kNc06gyAVK9fKeZ/vxzj5fQR+m5aE 39ofL/GssuqvR97vGrbgtOsSJ8lnhh/LPqsoT5XmtYCn+stuBhSXCLPeOOAPwGSiqe+EHHRgDgAA AAAAAA== --Apple-Mail=_BA1C9EFE-9D60-48F6-B9CF-FB0C998637FD-- From phil.hunt@oracle.com Fri May 24 17:20:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6721F9347 for ; Fri, 24 May 2013 17:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL1xvLeO2Y1L for ; Fri, 24 May 2013 17:20:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3311E80F9 for ; Fri, 24 May 2013 17:20:33 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4P0KVtn006545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 May 2013 00:20:32 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4P0KV0s006838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 May 2013 00:20:31 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4P0KUBS019101; Sat, 25 May 2013 00:20:30 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2013 17:20:30 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_03FD76C5-CB44-4C21-8490-526CADA6D921" From: Phil Hunt In-Reply-To: <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> Date: Fri, 24 May 2013 17:20:29 -0700 Message-Id: <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2013 00:20:39 -0000 --Apple-Mail=_03FD76C5-CB44-4C21-8490-526CADA6D921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The use cases I have heard of from Justin and Morteza at IIW are based = on federated scenarios. These are not just locally asserted tokens. Your assertion that the tokens are local and my assertion they are = federated suggests there are things that must be sorted out/understood. I'm merely implying that if you don't want to profile this, then don't = use HTTP Auth to pass the information. The reason HTTP Auth pushes the = inter-op issues is that many deployment architectures have multi-layers = of components processing security in a platform. Thus inter-op has to = be well defined. When the logic is concentrated into just OAuth registration components, = we can have looser definition IMHO. Though others will argue the = assertion still needs to be tightly defined. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-24, at 5:06 PM, John Bradley wrote: > Phil, >=20 > The OAuth token used authorize access to the registration endpoint( if = one is required) would be issued by the registration server via some = method eg cut and paste from a developer portal, email or perhaps via = OAuth to a Developer API management application. That is declared = out of scope because the token is optional and there are lots of ways = developers can get them. >=20 > I see it as a OAuth access token with some scopes attached to it like = any other access token. You seem to be thinking it is something else. = I don't understand what third party would be issuing these tokens. You = seem to have a use case in mind but I don't think I understand it. >=20 > John B. >=20 > On 2013-05-24, at 7:26 PM, Nat Sakimura wrote: >=20 >>=20 >>=20 >> =3Dnat via iPhone >>=20 >> May 25, 2013 7:16=E3=80=81Phil Hunt wrote:=20 >>>=20 >>>=20 >>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>=20 >>>> I agree with Justin. >>>>=20 >>>> If you want tight authentication on the AS that issues the tokens = we can use OAuth for that with short lived tokens granted based on a = SAML SSO , PIV card or whatever floats your boat for authentication. >>>=20 >>> [PH] I don't want tight authn. This is *registration*. Yet we are = pretending we are authenticating when we aren't. >>=20 >> It is not authentication.=20 >> It is an access authorization to this API.=20 >>=20 >>>=20 >>>> How the tokens are issued to the OAuth client doing the = registration (not the OAuth client being registered) is up to the AS = running the registration endpoint. They are OAuth tokens and you can = cram an assertion in them if you like. =20 >>>=20 >>> [PH] This is nothing to do with my point here. >>>>=20 >>>> Dynamic registration for OAuth should be built with OAuth! =20 >>> [PH] Well I was going to bring that up but didn't want to freak = people out. The idea you refer to was why not use oauth to issue an = access token to registration server. But that just makes people's head = explode. >>>=20 >>>>=20 >>>> John B. >>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: >>>>=20 >>>>> I completely disagree with this assessment. The latest draft = (which was just posted) has new language describing what this token is = and what it's for, and I hope that will clear things up. But even so, = let me try to address your concerns in-line. >>>>>=20 >>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>> wrote: >>>>>=20 >>>>>> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >>>>>> 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. >>>>>>=20 >>>>>=20 >>>>> The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But = fundamentally, it's just another token that's scoped to one endpoint for = a specific purpose. >>>>>=20 >>>>>> The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers. For potential software API = developers (e.g. Oracle CRM), the developer could potentially register = with Oracle CRMs registration service manually, and obtain a signed = assertion for use in their client software. Upon initiating dynamic = registration, the client software would present the assertion as its = initial authorization in the HTTP Authorization header as Justin = describes above. >>>>>>=20 >>>>>> While this has worked in practice so far, I am concerned about = this assertion being presented in this way. >>>>>>=20 >>>>>> The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. = Here's where I get worried. >>>>>>=20 >>>>>> 1. The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion >>>>>=20 >>>>> That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token.=20 >>>>>=20 >>>>>> 2. The assertion isn't an authentication, but rather signed = client metadata. >>>>>=20 >>>>> If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what = you can do with an OAuth token already. You can use an OAuth token as an = opaque blob, or you can define structure, signatures, etc., to pack = information inside of it. If the two always had to be together, then = OAuth would be defined with JWTs only and we'd have something that was = much less useful. >>>>>=20 >>>>>> 3. The bearer assertion is easily copied. Thus the server should = only trust this as metadata >>>>>=20 >>>>> Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well. >>>>>=20 >>>>>> 4. It ends up performing the same role as software_id >>>>>=20 >>>>> Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another = difference is that a bearer token isn't generally self-asserted, and = it's assumed the registration server will have some means of validating = this token, like it would with any OAuth token. It's more like you can = use the Initial Registration Token to fulfill the same role that you're = suggesting software_id be used for, which, to me, is more of an argument = against the more-limited software_id than it is against the existing = technology. >>>=20 >>> [PH] At minimum, as a UUID it is self asserted and only identifies a = common unique value shared between instances of a particular piece of = software. >>>=20 >>> But there is nothing saying it can't be a JWT signed assertion = serving the function of passing on signed client metadata. >>>=20 >>> The *big* difference is that the processing of the token occurs = within the registration endpoint. The ONLY endpoint that should accept = this. >>>=20 >>> When you stick it in the HTTP Auth header it will likely get = processed by the platform security system which then has to have special = handling code to intercept this custom, undefined, unprofiled token. >>>=20 >>> Of course, you could just bypass platform security on everything=E2=80= =A6. >>>>>=20 >>>>>>=20 >>>>>> While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP. >>>>>=20 >>>>> The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration. >>>=20 >>> [PH] What you are passing in Blue Button is a software assertion. = It's not an authorization or an authentication. Authorization would = have to be issued locally. Authentication, could be federated, but = there are no authn statements are there. So it is a bearer software = assertion. The only reason it is better than UUID is that we can = evaluate trust of a third party with regards to the statements = contained. =20 >>>>>=20 >>>>>>=20 >>>>>> A further benefit is that the registration endpoint = authentication system only has to deal with locally issued credentials. = The logic for handling federated client meta data can be isolated to the = registration server logic. >>>>>=20 >>>>> You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 >>>=20 >>> [PH] I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local? =20 >>>>>=20 >>>>>>=20 >>>>>> My feeling is that if we keep "initial authorization credential" = as being passed in the HTTP Authorization header, then strict rules = about the contents of the token and the processing rules must be defined = so that HTTP server security systems can be extended to support this. >>>>>=20 >>>>> It's an OAuth token. >>>=20 >>> [PH[ NO IT IS NOT. The token is issued by a third party provider. = Besides when someone says "OAuth Token" I take that to mean an ACCESS = token. If it is anything else it is just a JWT or SAML token. >>>=20 >>>>> You use whatever HTTP security systems that you already have to = process OAuth tokens on it. If you also want to use it to tell you = something about client metadata, you're going to have to define further = processing, yes, because "an OAuth token" doesn't tell you anything = about what's inside of it or what the token means -- on purpose. But = you'd have to do the same thing with software_id. But nothing is saying = that you need to do that, or that it has to be an assertion at all. = Maybe you just want to lock down your API to know developers, so you = issue them hex blobs to call the API with. Those could expire 5 minutes = from when you issued them, if you wanted. Or they could be SAML blobs, = or JWTs, or anything else that can pass for an OAuth token. There's no = reason any of this should be disallowed by the registration spec, = because the registration spec doesn't care. All it cares about is that = it's an OAuth token and it's (somehow) validated by the registration = endpoint in such a way that the HTTP call to the Registration Endpoint = is valid. This is absolutely bog-standard OAuth Protected Resource here. = By defining it as an OAuth token (and no further), we immediately gain = all of the flexibility and power of OAuth tokens.=20 >>>=20 >>> [PH} Sure what you suggest can and will work. But it is 10x more = complex architecturally. =20 >>>>>=20 >>>>>>=20 >>>>>> If we use software_id, and indicate that it can accept a = "software registration assertion", we can be more flexible and minimize = the processing rules we have to declare in the draft. That said, if = there is a case to adopt strict rules here too, I am open. >>>>>=20 >>>>> I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the = two paragraphs that you had spoken of previously, and it would be both = useful and interoperable. But it's enough complexity and enough of a = very specific corner case that I am not at all comfortable putting that = level of processing into the dynamic registration draft. I am willing to = put software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. >>>=20 >>> [PH] =20 >>> 1. What rules do you need around a UUID? It is JUST a unique = identifier. >>> 2. If an assertion, how is it *any* different from intial client = assertion other than the component of the server that must process it? >>>=20 >>> As I said, if you make it part of authentication, then complexity = increases and therefore we would have to tightly profile the assertion = so that token authentication system will accept these federated tokens. >>>=20 >>> If you leave it as part of software_id, then we can be more informal = (to a point). >>>=20 >>> I can't help this, it is just the way servers are made. The horse = has left the barn as John says. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_03FD76C5-CB44-4C21-8490-526CADA6D921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = use cases I have heard of from Justin and Morteza at IIW are based on = federated scenarios. These are not just locally asserted = tokens.

Your assertion that the tokens are local and = my assertion they are federated suggests there are things that must be = sorted out/understood.

I'm merely implying that = if you don't want to profile this, then don't use HTTP Auth to pass the = information.  The reason HTTP Auth pushes the inter-op issues is = that many deployment architectures have multi-layers of components = processing security in a platform.  Thus inter-op has to be well = defined.

When the logic is concentrated into = just OAuth registration components, we can have looser definition IMHO. =  Though others will argue the assertion still needs to be tightly = defined.

Phil

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





On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The = OAuth token used authorize access to the registration endpoint( if one = is required) would be issued by the registration server via some method = eg cut and paste from a developer portal, email or perhaps via OAuth to = a Developer API management application.     That is declared = out of scope because the token is optional and there are lots of ways = developers can get them.

I see it as a OAuth = access token with some scopes attached to it like any other access = token.   You seem to be thinking it is something else.   I = don't understand what third party would be issuing these tokens. =  You seem to have a use case in mind but I don't think I understand = it.

John B.

On = 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com> = wrote:



=3Dnat via = iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com> =  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication = on the AS that issues the tokens we can use OAuth for that with short = lived tokens granted based on a SAML SSO , PIV card or whatever floats = your boat for authentication.

[PH] I don't want tight authn. This is = *registration*. Yet we are pretending we are authenticating when we = aren't.

It is not = authentication. 
It is an access authorization to this = API. 


How the tokens are issued to the = OAuth client doing the registration (not the OAuth client being = registered) is up to the AS running the registration endpoint.   = They are OAuth tokens and you can cram an assertion in them if you like. =  

[PH] This is nothing to do with my = point here.

Dynamic registration = for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but = didn't want to freak people out. The idea you refer to was why not use = oauth to issue an access token to registration server.  But that = just makes people's head explode.


John = B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was = just posted) has new language describing what this token is and what = it's for, and I hope that will clear things up. But even so, let me try = to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential = covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped = to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way = for trusted entities to sign assertions that could be accepted by a set = of deployed authorization servers.  For potential software API = developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a = signed assertion for use in their client software.  Upon initiating = dynamic registration, the client software would present the assertion as = its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this = assertion being presented in this way.

The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. =  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed = client metadata.

If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can = use an OAuth token as an opaque blob, or you can define structure, = signatures, etc., to pack information inside of it. If the two always = had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server = should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix = of client types with different policy rules (since we can control policy = in BB+ land). Our discovery and registry setup lets us enforce these = rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the = holder is authorized to make this call? You'd have to put rules around = software_id saying that it needs to be processed in a particular way, = and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't = generally self-asserted, and it's assumed the registration server will = have some means of validating this token, like it would with any OAuth = token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be = used for, which, to me, is more of an argument against the more-limited = software_id than it is against the existing = technology.

[PH] At = minimum, as a UUID it is self asserted and only identifies a common = unique value shared between instances of a particular piece of = software.

But there is nothing saying it can't be a JWT signed = assertion serving the function of passing on signed client = metadata.

The *big* difference is that the = processing of the token occurs within the registration endpoint. The = ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will = likely get processed by the platform security system which then has to = have special handling code to intercept this custom, undefined, = unprofiled token.

Of course, you could just bypass platform security = on everything=E2=80=A6.


While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP.

The token in question is fundamentally an authorization mechanism = for calling the registration endpoint. I agree there's value in passing = client software assertions around, and that we should solve that in an = interoperable way, but that's a completely separate question from = registration.

[PH] What you are passing in Blue Button is a software assertion. =  It's not an authorization or an authentication. =  Authorization would have to be issued locally. =  Authentication, could be federated, but there are no authn = statements are there.  So it is a bearer software assertion. =  The only reason it is better than UUID is that we can evaluate = trust of a third party with regards to the statements contained. =  


A further benefit is that the registration endpoint authentication = system only has to deal with locally issued credentials. The logic for = handling federated client meta data can be isolated to the registration = server logic.

You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 

[P= H]  I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as = being passed in the HTTP Authorization header, then strict rules about = the contents of the token and the processing rules must be defined so = that HTTP server security systems can be extended to support this.

It's an OAuth = token.

[PH[ NO = IT IS NOT.  The token is issued by a third party provider. =  Besides when someone says "OAuth Token" I take that to mean an = ACCESS token.  If it is anything else it is just a JWT or SAML = token.

You use whatever HTTP security = systems that you already have to process OAuth tokens on it. If you also = want to use it to tell you something about client metadata, you're going = to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or = what the token means -- on purpose. But you'd have to do the same thing = with software_id. But nothing is saying that you need to do that, or = that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them = hex blobs to call the API with. Those could expire 5 minutes from when = you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or = anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration = spec, because the registration spec doesn't care. All it cares about is = that it's an OAuth token and it's (somehow) validated by the = registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard = OAuth Protected Resource here. By defining it as an OAuth token (and no = further), we immediately gain all of the flexibility and power of OAuth = tokens. 

[PH} Sure what you = suggest can and will work. But it is 10x more complex architecturally. =  


If we use software_id, and indicate that it can accept a "software = registration assertion", we can be more flexible and minimize the = processing rules we have to declare in the draft. That said, if there is = a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be = both useful and interoperable. But it's enough complexity and enough of = a very specific corner case that I am not at all comfortable putting = that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a = hook to some future-to-be-defined specification that tells you how to = validate it and parse it and use it for validating client metadata and = tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd = really break anything if it went in and you thought you could use it to = bootstrap your process.

[PH]  
1. What = rules do you need around a UUID?  It is JUST a unique = identifier.
2. If an assertion, how is it *any* different from = intial client assertion other than the component of the server that must = process it?

As I said, if you make it part of authentication, = then complexity increases and therefore we would have to tightly profile = the assertion so that token authentication system will accept these = federated tokens.

If you leave it as part of software_id, then we can = be more informal (to a point).

I can't help = this, it is just the way servers are made.  The horse has left the = barn as John says.

 -- Justin

_______________________________________________
OAuth mailing 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=_03FD76C5-CB44-4C21-8490-526CADA6D921-- From phil.hunt@oracle.com Fri May 24 18:16:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0E21F8F43 for ; Fri, 24 May 2013 18:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pr65yNmsDBE for ; Fri, 24 May 2013 18:16:38 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0387621F8FB3 for ; Fri, 24 May 2013 18:16:37 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4P1GY9s002677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 May 2013 01:16:35 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4P1GXUw000471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 May 2013 01:16:34 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4P1GX2i000464; Sat, 25 May 2013 01:16:33 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 May 2013 18:16:33 -0700 References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <95184DBE-3D90-4998-BD50-9491135EF013@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Fri, 24 May 2013 18:16:34 -0700 To: "Richer, Justin P." X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-11.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, 25 May 2013 01:16:43 -0000 Justin, Thanks. I think this resolved all of my syntax issues.=20 The lifecycle text is very helpful.=20 I still want to continue discussion on initial access and reg access. We can= address in other threads.=20 Thx Phil On 2013-05-24, at 14:10, "Richer, Justin P." wrote: > New Dynamic Registration draft is published, incorporating much of the dis= cussion from the group this week.=20 >=20 > Some normative changes that should have minimal impact: > - "expires_at" is now "client_secret_expires_at" > - "issued_at" is now "client_id_issued_at" > - creation of an IANA registry for token_endpoint_auth_method > - removal of two underdefined values from token_endpoint_auth_method (clie= nt_secret_jwt and private_key_jwt), these are now defined in an extension (O= penID Connect Registration) >=20 > And several editorial changes: >=20 > - new "client lifecycle" section that describes how different kinds of cli= ents can use the dynamic registration protocol, how a client's credentials g= et refreshed, and the relationship between the Client Identifier and the Cli= ent software > - new "registration tokens and credentials" section describing the differe= nt kinds of tokens and credentials used in the registration process, what th= ey're for, and why they're all separate > - clarified the definitions of several fields like policy_uri and tos_uri >=20 > Thanks for all the great feedback, and please keep the constructive commen= tary coming! > -- Justin >=20 > On May 24, 2013, at 4:36 PM, > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >>=20 >> Title : OAuth 2.0 Dynamic Client Registration Protocol >> Author(s) : Justin Richer >> John Bradley >> Michael B. Jones >> Maciej Machulak >> Filename : draft-ietf-oauth-dyn-reg-11.txt >> Pages : 34 >> Date : 2013-05-24 >>=20 >> Abstract: >> This specification defines an endpoint and protocol for dynamic >> registration of OAuth 2.0 Clients at an Authorization Server and >> methods for the dynamically registered client to manage its >> registration. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-11 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 vincetsang@gmail.com Mon May 27 09:47:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ECB21F96E8 for ; Mon, 27 May 2013 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeGt0CbTDyym for ; Mon, 27 May 2013 09:47:28 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A781B21F96E5 for ; Mon, 27 May 2013 09:47:27 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id m15so4710090wgh.20 for ; Mon, 27 May 2013 09:47:26 -0700 (PDT) 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=peSCNTjEvlKmrkRNvbwfP7ANOX2+Xb0rYENoxY/VCGg=; b=DBJnLegq/YG4my70JtyX31zwTyxhohCfmNSUX8/uAMu8Y+NhH3edol3U8Cp2RHut1U pdPnkN2GDufdcvMpF8y7UIBykUXOOaUzue1ifuSbFRf+14NvvUmcvh81poYG61KubiV0 34vllR2+eL8YYnusESVOK6GhaACxIABEDK/qtplzRecWhGE+KrNmlRPQPSeypJ+QbBgU CYieAIh8MJNeLkEew3CrGclTnmGMMA1Dwe5SfEnKQFe0EeYCfMOPM6tRQcG3vhuMwYrz uHWBvgaLobd91RyeR03NORRpaLjBmxJP7GBWtaURyx7KCEbw5AOkQ6092SZkNSP3+pBu bfDg== MIME-Version: 1.0 X-Received: by 10.194.175.132 with SMTP id ca4mr9536962wjc.11.1369673246686; Mon, 27 May 2013 09:47:26 -0700 (PDT) Received: by 10.216.80.198 with HTTP; Mon, 27 May 2013 09:47:26 -0700 (PDT) Date: Tue, 28 May 2013 00:47:26 +0800 Message-ID: From: Vincent Tsang To: oauth@ietf.org Content-Type: multipart/alternative; boundary=089e013d1d8e53c41304ddb5e7f7 Subject: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 27 May 2013 16:47:28 -0000 --089e013d1d8e53c41304ddb5e7f7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'm looking for the most suitable solution to grant the access token for accessing our cloud service API for clients which is a windows application with no internet browsing capability itself (though it can be installed on a PC with access to internet). After some research, it seems the device profile (http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00) is the flow addressing the closest use case to ours (but still not exact). Could someone please advise whether it is a good idea for us to follow this draft (is it still active?) for the OAuth flow for our use case, or else does someone know which should be the best flow that we should follow instead? Thanks in advance! Vincent --089e013d1d8e53c41304ddb5e7f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm looking for the m= ost suitable solution to grant the access token for accessing our cloud ser= vice API for clients which is a windows application with no internet browsi= ng capability itself (though it can be installed on a PC with access to int= ernet). After some research, it seems the device profile (http://tools.ietf.o= rg/html/draft-recordon-oauth-v2-device-00) =A0is the flow addressing th= e closest use case to ours (but still not exact).=A0

Could someone please advise whether it is a= good idea for us to follow this draft (is it still active?) for the OAuth = flow for our use case, or else does someone know which should be the best f= low that we should follow instead?

Thanks in advance!

Vincent
--089e013d1d8e53c41304ddb5e7f7-- From hannes.tschofenig@gmx.net Mon May 27 10:37:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C090221F8CF4 for ; Mon, 27 May 2013 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAj3obWi5wBk for ; Mon, 27 May 2013 10:37:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 14C3B21F8201 for ; Mon, 27 May 2013 10:37:24 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LtTty-1UHgxC3eDs-010pnD for ; Mon, 27 May 2013 19:37:22 +0200 Received: (qmail invoked by alias); 27 May 2013 17:37:22 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp028) with SMTP; 27 May 2013 19:37:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wiCVfWSEwoBzI0+Il73rcOXOff/1SU2Q3r3JmSV /o2rXSwUEUHevv Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 27 May 2013 20:37:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vincent Tsang X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 27 May 2013 17:37:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Vincent, from a pure standardization point of view that draft is long expired.=20 This document was initially created because the device profile was one = of the least mature parts of the OAuth 2.0 protocol. We were hoping to = gain a bit more deployment experience before continuing the work but it = seems that we dropped the ball a bit. More important work items came = along. I had tried to resurrect it but that again was probably a year = ago.=20 The challenge was to find out what various industry players are doing so = that we can standardize the best current practice.=20 Would you be interested to work on this document again?=20 Ciao Hannes PS: Does your environment have a similar problem as described in the = abstract of the mentioned document, namely:=20 " ...=20 devices which do not have an easy data-entry method (e.g. game consoles or media hubs), but where the end-user has separate access to a user-agent on another computer or device (e.g. home computer, a laptop, or a smart phone). " On May 27, 2013, at 7:47 PM, Vincent Tsang wrote: > Hi all, >=20 > I'm looking for the most suitable solution to grant the access token = for accessing our cloud service API for clients which is a windows = application with no internet browsing capability itself (though it can = be installed on a PC with access to internet). After some research, it = seems the device profile = (http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00) is the = flow addressing the closest use case to ours (but still not exact).=20 >=20 > Could someone please advise whether it is a good idea for us to follow = this draft (is it still active?) for the OAuth flow for our use case, or = else does someone know which should be the best flow that we should = follow instead? >=20 > Thanks in advance! >=20 > Vincent > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRo5nQAAoJEGhJURNOOiAtSIoH/21CCCtlWnjRubbJNkyUjYy7 49r9MoFYy6Yo9wFMktQ6oUrk3nj9R/+ynn4WJz3wYBlBFqTgOhipq0ui3MYsp+db LKnSjQ5NzkPasShAdHj8zXogbbaN7Gcmnje32mCPMnehTSaWEVqaMcW63cD+1m1v qzk7mJxsB95sr9SBPo+cZjMn7vj29/fPHKAu7TzX4n9WfHDUlMhIGcTVdtcELDr6 DIq54R50A/8ba/shO0pN1P8y3rG7kd/V2bOaSKCVnnsoo5yAMaIcmPttlSoZ4DXi CbQ/36uTBUEjHnuyYYm91KkU4fI7fvj1vTP9aTn0aX9vvMNyc3lPrPw56c7jZ6U=3D =3DdQeY -----END PGP SIGNATURE----- From phil.hunt@oracle.com Mon May 27 11:46:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F76221F8DB7 for ; Mon, 27 May 2013 11:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg+lRYJJ8W9F for ; Mon, 27 May 2013 11:46:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DE3DE21F967B for ; Mon, 27 May 2013 11:46:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4RIkjnl008352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 May 2013 18:46:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4RIkilA027805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2013 18:46:44 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4RIkhhF005662; Mon, 27 May 2013 18:46:43 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 May 2013 11:46:38 -0700 MIME-Version: 1.0 Message-ID: <526A2B4E-BC21-4F5D-8D97-36DE703C90F2@oracle.com> Date: Mon, 27 May 2013 11:46:41 -0700 (PDT) From: Phil Hunt To: John Bradley References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> <96A405B0-058E-4E9E-B6F9-E4E80256BB1F@ve7jtb.com> In-Reply-To: <96A405B0-058E-4E9E-B6F9-E4E80256BB1F@ve7jtb.com> X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 27 May 2013 18:46:59 -0000 John/Josh, I am afraid it is still not clear to me what is the value of implicit = client dynamic registration. If you allow dynamic registration of a = client, each client, then each client can specify random redirect_uri's. = This would seem to be a major issue. The whole point behind implicit = flow is NO client authentication. So what technical or operational = benefit of registering an execution instance? Maybe, the horse has left the barn. But I don't see that as a reason to = standardize an unsafe or pointless practice. I'm not saying it is = pointless. I'm just not clear on what the benefit is.=20 I am curious about Josh's use case. How is the client code developed, = distributed, and deployed? Are there already inherent mechanisms where = OOB deployment registration is easy to achieve? IOW Each client use = can easily obtain an OOB client_id. Josh expresses he needs to = register, but the question I am asking is why? It seems that in his = case, the code being downloaded must be coming from a common trusted = source. If so, what benefit is gained with dynamic registration for = these clients. They should just use a static client_id -- even something = akin to the initial client assertion Justin talks about. =46rom an operational aspect, issuing per execution context client_ids = (and potential per client_id registration access tokens), etc per client = seems to be wasteful for both the implicit client code and especially = the AS/Resource SPs. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-24, at 2:38 PM, John Bradley wrote: > Phil, >=20 > I think the horse is out of the barn on implicit flow. >=20 > Many websites use implicit rather than code now, it is no worse, and = perhaps better than using code flow with a client that is not = confidential( though Dynamic registration can dix the public client code = flow problem for native apps etc) >=20 > Implicit as you well know relies on registration of the redirect URI = to identify the client. There may be multiple JS apps in browsers all = using JS from the same redirect URI, but I don't think that should = preclude the backend website from using an API to register. =20 >=20 > Turning off dynamic registration entirely for implicit flow is = overkill. A registration server is free to not allow dynamic = registration of implicit clients if that is it's policy. >=20 > In general I have a hard time seeing implicit clients with a server = component using dynamic registration directly. I suppose there may be = HTML5 based clients that are loaded as browser extensions and use = implicit, without having a server based redirect. Those can be as long = lived as any native app. If clean up is an issue it is one for code = flow as well. >=20 > John B. >=20 > On 2013-05-24, at 2:35 PM, Phil Hunt wrote: >=20 >> I wanted to bring out a quick discussion to ask the question if it = makes sense to support implicit clients in dynamic registration. >>=20 >> By definition, implicit clients are unauthenticated. Therefore the = only purpose to register an implicit client is to obtain a client_id = with a particular AS instance. >>=20 >> A few issues to consider: >> * Implicit clients typically run in browsers (javascript). Do we = really want each occurrence of a browser running a client to register? >> --> This could mean even the same browser running implicit flow = repeat times, would register repeatedly. >> --> If registration occurs per occurrence, what is the value? >>=20 >> * What use cases typically occur for deployment against different AS = and Resource API instances? >> --> Eg. I can see a javascript component of a web site that uses a = corresponding resource API. So it may be possible that the javascript = and the resource API are running in the same domain. In this case, the = javascript code, though written as part of a shared = library/distribution, is still bound to a configured AS deployment. Is = it really dynamic? If this is the case, wouldn't an OOB registration = that updates the client_id in the deployment be better suited? >> --> Are there any examples of javascript clients that need to = connect to one or more AS servers on a truly dynamic basis? >>=20 >> * Is there a DOS attack possible (even unintentionally) because = implicit clients will start to register frequently creating huge numbers = of client_ids that cause spin-off provisioning issues depending on how = AS registration, token, and policy systems are implemented? >>=20 >> Apparently OIDC and UMA had these profiles supported before, but I'm = really trying to understand why implicit clients should have dynamic = registration support. Would appreciate any discussion on this. At = minimum, there are probably some security considerations we need to = think through and document. >>=20 >> Thanks for your comments, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From torsten@lodderstedt.net Mon May 27 12:03:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08221F96B1 for ; Mon, 27 May 2013 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13BAkmH023ul for ; Mon, 27 May 2013 12:03:44 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE9B621F96AB for ; Mon, 27 May 2013 12:03:39 -0700 (PDT) Received: from [79.253.11.148] (helo=[192.168.71.68]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Uh2hm-0001W9-67; Mon, 27 May 2013 21:03:38 +0200 Message-ID: <51A3AE0B.1020802@lodderstedt.net> Date: Mon, 27 May 2013 21:03:39 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Richer, Justin P." References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> In-Reply-To: <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 27 May 2013 19:03:49 -0000 Hi Justin, the drafts looks very good. Just some questions/comments from my side: section 1.4 How is the client supposed to identify/distinguish authorization servers? Based on the Client Registration Endpoint URI? Authorization server identification is necessary in order to map client_ids to authorization servers for clients, which are connected to multiple authorization servers. section 1.4.1 f Why does the client secret expire while the access token ist still valid? Secret and token are stored at the same locations so an attacker may obtain both at once. "token_endpoint_auth_method" What is the use case for dynamic registration of public clients? In my opinion, public clients exist because OAuth 2.0 core does not provided a mechanism to provision secrets to the different instances of an installed/native app. Dynamic registration closes this gap, so any installed app may retrieve a distinct secret. "client_secret_post vs client_secret_basic" BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? "jwks_uri" What is this data used for? the OAuth JWT Bearer Token Profiles? best regards, Torsten. Am 24.05.2013 23:10, schrieb Richer, Justin P.: > New Dynamic Registration draft is published, incorporating much of the discussion from the group this week. > > Some normative changes that should have minimal impact: > - "expires_at" is now "client_secret_expires_at" > - "issued_at" is now "client_id_issued_at" > - creation of an IANA registry for token_endpoint_auth_method > - removal of two underdefined values from token_endpoint_auth_method (client_secret_jwt and private_key_jwt), these are now defined in an extension (OpenID Connect Registration) > > And several editorial changes: > > - new "client lifecycle" section that describes how different kinds of clients can use the dynamic registration protocol, how a client's credentials get refreshed, and the relationship between the Client Identifier and the Client software > - new "registration tokens and credentials" section describing the different kinds of tokens and credentials used in the registration process, what they're for, and why they're all separate > - clarified the definitions of several fields like policy_uri and tos_uri > > Thanks for all the great feedback, and please keep the constructive commentary coming! > -- Justin > > On May 24, 2013, at 4:36 PM, > 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 2.0 Dynamic Client Registration Protocol >> Author(s) : Justin Richer >> John Bradley >> Michael B. Jones >> Maciej Machulak >> Filename : draft-ietf-oauth-dyn-reg-11.txt >> Pages : 34 >> Date : 2013-05-24 >> >> Abstract: >> This specification defines an endpoint and protocol for dynamic >> registration of OAuth 2.0 Clients at an Authorization Server and >> methods for the dynamically registered client to manage its >> registration. >> >> >> 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-11 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11 >> >> >> 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 internet-drafts@ietf.org Tue May 28 07:17:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12F21F9732; Tue, 28 May 2013 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geYSoTKttwQh; Tue, 28 May 2013 07:17:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2121F9744; Tue, 28 May 2013 07:17:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130528141701.26409.58718.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 07:17:01 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-08.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, 28 May 2013 14:17:02 -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-08.txt Pages : 25 Date : 2013-05-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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Tue May 28 07:29:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E500F21F9524 for ; Tue, 28 May 2013 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ6u6LMu4nI6 for ; Tue, 28 May 2013 07:29:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7853921F94E1 for ; Tue, 28 May 2013 07:29:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DD6681F0732; Tue, 28 May 2013 10:29:33 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D1A601F06FB; Tue, 28 May 2013 10:29:33 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 28 May 2013 10:29:33 -0400 Message-ID: <51A4BF27.50800@mitre.org> Date: Tue, 28 May 2013 10:28:55 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> In-Reply-To: <51A3AE0B.1020802@lodderstedt.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 28 May 2013 14:29:44 -0000 Torsten, thanks for the review. Comments inline. On 05/27/2013 03:03 PM, Torsten Lodderstedt wrote: > Hi Justin, > > the drafts looks very good. > > Just some questions/comments from my side: > > section 1.4 > > How is the client supposed to identify/distinguish authorization > servers? Based on the Client Registration Endpoint URI? Authorization > server identification is necessary in order to map client_ids to > authorization servers for clients, which are connected to multiple > authorization servers. That's a great question -- but I think it's entirely dependent on how discovery and configuration is set up for a client, which is ultimately orthogonal to registration. The way that I've implemented it in our client is based on the OpenID Connect discovery process, which bases everything in the server's configuration off of an "issuer" URL. It would be easy enough to point out here that discovery and differentiation of different servers is out of scope. > > section 1.4.1 f > > Why does the client secret expire while the access token ist still > valid? Secret and token are stored at the same > locations so an attacker may obtain both at once. Secrets are used at the token endpoint, so the attack surface is slightly different. Since you can only use the registration access token at the registration endpoint, you can use it to rotate your other credentials. > > "token_endpoint_auth_method" > What is the use case for dynamic registration of public clients? In my > opinion, public clients exist because OAuth 2.0 core does not provided > a mechanism to provision secrets to the different instances of an > installed/native app. Dynamic registration closes this gap, so any > installed app may retrieve a distinct secret. This gap-closing is true for some classes of client that used to have to be public, like many native apps. But there are still clients that have no use for a client secret, like in-browser clients that use the implicit flow. Now if these clients are also talking to multiple auth servers, they'll each need a client_id at the auth server (because there's no practical way to publish a "public" client ID to *all* auth servers). A discussion in the security considerations about the limitations and usefulness of this use case is probably worthwhile, so I'll make a note to do that. > > "client_secret_post vs client_secret_basic" > BASIC and POST are essentially the same just different ways to send > the client secret. If an authorization server supports both, both > should work for any client. So are both methods treated differently? I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. > > "jwks_uri" > What is this data used for? the OAuth JWT Bearer Token Profiles? That's one, but it's really for any higher-level protocol that uses signing and encryption. There are several out there that are using JOSE on top of OAuth to do things, so we felt it was worthwhile to have one standard place to have the client say "here's my public key". -- Justin > > best regards, > Torsten. > > Am 24.05.2013 23:10, schrieb Richer, Justin P.: >> New Dynamic Registration draft is published, incorporating much of >> the discussion from the group this week. >> >> Some normative changes that should have minimal impact: >> - "expires_at" is now "client_secret_expires_at" >> - "issued_at" is now "client_id_issued_at" >> - creation of an IANA registry for token_endpoint_auth_method >> - removal of two underdefined values from >> token_endpoint_auth_method (client_secret_jwt and private_key_jwt), >> these are now defined in an extension (OpenID Connect Registration) >> >> And several editorial changes: >> >> - new "client lifecycle" section that describes how different kinds >> of clients can use the dynamic registration protocol, how a client's >> credentials get refreshed, and the relationship between the Client >> Identifier and the Client software >> - new "registration tokens and credentials" section describing the >> different kinds of tokens and credentials used in the registration >> process, what they're for, and why they're all separate >> - clarified the definitions of several fields like policy_uri and >> tos_uri >> >> Thanks for all the great feedback, and please keep the constructive >> commentary coming! >> -- Justin >> >> On May 24, 2013, at 4:36 PM, >> 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 2.0 Dynamic Client Registration Protocol >>> Author(s) : Justin Richer >>> John Bradley >>> Michael B. Jones >>> Maciej Machulak >>> Filename : draft-ietf-oauth-dyn-reg-11.txt >>> Pages : 34 >>> Date : 2013-05-24 >>> >>> Abstract: >>> This specification defines an endpoint and protocol for dynamic >>> registration of OAuth 2.0 Clients at an Authorization Server and >>> methods for the dynamically registered client to manage its >>> registration. >>> >>> >>> 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-11 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11 >>> >>> >>> 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 jricher@mitre.org Tue May 28 07:54:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADDA21F97AA for ; Tue, 28 May 2013 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AtHCroqiQYV for ; Tue, 28 May 2013 07:54:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B9FC121F97B7 for ; Tue, 28 May 2013 07:54:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BF6C92260022; Tue, 28 May 2013 10:54:22 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 99E331F0505; Tue, 28 May 2013 10:54:22 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 28 May 2013 10:54:22 -0400 Message-ID: <51A4C4F8.2090704@mitre.org> Date: Tue, 28 May 2013 10:53:44 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> In-Reply-To: <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> Content-Type: multipart/alternative; boundary="------------000002000401070504050609" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 14:54:32 -0000 --------------000002000401070504050609 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint. There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token. You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token. -- Justin On 05/24/2013 08:20 PM, Phil Hunt wrote: > The use cases I have heard of from Justin and Morteza at IIW are based > on federated scenarios. These are not just locally asserted tokens. > > Your assertion that the tokens are local and my assertion they are > federated suggests there are things that must be sorted out/understood. > > I'm merely implying that if you don't want to profile this, then don't > use HTTP Auth to pass the information. The reason HTTP Auth pushes > the inter-op issues is that many deployment architectures have > multi-layers of components processing security in a platform. Thus > inter-op has to be well defined. > > When the logic is concentrated into just OAuth registration > components, we can have looser definition IMHO. Though others will > argue the assertion still needs to be tightly defined. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-24, at 5:06 PM, John Bradley wrote: > >> Phil, >> >> The OAuth token used authorize access to the registration endpoint( >> if one is required) would be issued by the registration server via >> some method eg cut and paste from a developer portal, email or >> perhaps via OAuth to a Developer API management application. That is >> declared out of scope because the token is optional and there are >> lots of ways developers can get them. >> >> I see it as a OAuth access token with some scopes attached to it like >> any other access token. You seem to be thinking it is something >> else. I don't understand what third party would be issuing these >> tokens. You seem to have a use case in mind but I don't think I >> understand it. >> >> John B. >> >> On 2013-05-24, at 7:26 PM, Nat Sakimura > > wrote: >> >>> >>> >>> =nat via iPhone >>> >>> May 25, 2013 7:16?Phil Hunt >> > wrote: >>>> >>>> >>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>> >>>>> I agree with Justin. >>>>> >>>>> If you want tight authentication on the AS that issues the tokens >>>>> we can use OAuth for that with short lived tokens granted based on >>>>> a SAML SSO , PIV card or whatever floats your boat for authentication. >>>> >>>> [PH] I don't want tight authn. This is *registration*. Yet we are >>>> pretending we are authenticating when we aren't. >>> >>> It is not authentication. >>> It is an access authorization to this API. >>> >>>> >>>>> How the tokens are issued to the OAuth client doing the >>>>> registration (not the OAuth client being registered) is up to the >>>>> AS running the registration endpoint. They are OAuth tokens and >>>>> you can cram an assertion in them if you like. >>>> >>>> [PH] This is nothing to do with my point here. >>>>> >>>>> Dynamic registration for OAuth should be built with OAuth! >>>> [PH] Well I was going to bring that up but didn't want to freak >>>> people out. The idea you refer to was why not use oauth to issue an >>>> access token to registration server. But that just makes people's >>>> head explode. >>>> >>>>> >>>>> John B. >>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." >>>> > wrote: >>>>> >>>>>> I completely disagree with this assessment. The latest draft >>>>>> (which was just posted) has new language describing what this >>>>>> token is and what it's for, and I hope that will clear things up. >>>>>> But even so, let me try to address your concerns in-line. >>>>>> >>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>> > >>>>>> wrote: >>>>>> >>>>>>> I have been struggling with the concept of an initial client >>>>>>> credential covered in the current draft (rev 10): >>>>>>> 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. >>>>>>> >>>>>> >>>>>> The Client Registration Endpoint is an OAuth Protected Resource. >>>>>> This token is a means for authorizing calls to the endpoint. Can >>>>>> you use it for other things? Sure, just like you can use OAuth >>>>>> tokens for other things (passing data about authentication, for >>>>>> instance). But fundamentally, it's just another token that's >>>>>> scoped to one endpoint for a specific purpose. >>>>>> >>>>>>> The use case is very important since it opens the door for a way >>>>>>> for trusted entities to sign assertions that could be accepted >>>>>>> by a set of deployed authorization servers. For potential >>>>>>> software API developers (e.g. Oracle CRM), the developer could >>>>>>> potentially register with Oracle CRMs registration service >>>>>>> manually, and obtain a signed assertion for use in their client >>>>>>> software. Upon initiating dynamic registration, the client >>>>>>> software would present the assertion as its initial >>>>>>> authorization in the HTTP Authorization header as Justin >>>>>>> describes above. >>>>>>> >>>>>>> While this has worked in practice so far, I am concerned about >>>>>>> this assertion being presented in this way. >>>>>>> >>>>>>> The authentication header has special meaning to many servers. >>>>>>> Depending on implementation architecture, the authorization >>>>>>> header will first be intercepted by the authentication >>>>>>> components in the server. Here's where I get worried. >>>>>>> >>>>>>> 1. The assertion being presented is not an Authn assertion. >>>>>>> There is no "authentication session" tied to the assertion >>>>>> >>>>>> That's fine. Not all OAuth tokens are authentication assertions >>>>>> today, and this is just another OAuth token. >>>>>> >>>>>>> 2. The assertion isn't an authentication, but rather signed >>>>>>> client metadata. >>>>>> >>>>>> If you want to interpret the token as both authorization to call >>>>>> the registration endpoint as well as client metadata, you can do >>>>>> that. But you're going to have to define how that metadata is >>>>>> passed, how it's signed, how it's interpreted, etc. Which, you'll >>>>>> note, is exactly what you can do with an OAuth token already. You >>>>>> can use an OAuth token as an opaque blob, or you can define >>>>>> structure, signatures, etc., to pack information inside of it. If >>>>>> the two always had to be together, then OAuth would be defined >>>>>> with JWTs only and we'd have something that was much less useful. >>>>>> >>>>>>> 3. The bearer assertion is easily copied. Thus the server >>>>>>> should only trust this as metadata >>>>>> >>>>>> Depends on the kind of client, and with BB+ we've defined a >>>>>> matrix of client types with different policy rules (since we can >>>>>> control policy in BB+ land). Our discovery and registry setup >>>>>> lets us enforce these rules appropriately as well. >>>>>> >>>>>>> 4. It ends up performing the same role as software_id >>>>>> >>>>>> Not really. How does software_id (on its own) represent a that >>>>>> the holder is authorized to make this call? You'd have to put >>>>>> rules around software_id saying that it needs to be processed in >>>>>> a particular way, and I think such rules are far too restrictive >>>>>> for this draft. Another difference is that a bearer token isn't >>>>>> generally self-asserted, and it's assumed the registration server >>>>>> will have some means of validating this token, like it would with >>>>>> any OAuth token. It's more like you can use the Initial >>>>>> Registration Token to fulfill the same role that you're >>>>>> suggesting software_id be used for, which, to me, is more of an >>>>>> argument against the more-limited software_id than it is against >>>>>> the existing technology. >>>> >>>> [PH] At minimum, as a UUID it is self asserted and only identifies >>>> a common unique value shared between instances of a particular >>>> piece of software. >>>> >>>> But there is nothing saying it can't be a JWT signed assertion >>>> serving the function of passing on signed client metadata. >>>> >>>> The *big* difference is that the processing of the token occurs >>>> within the registration endpoint. The ONLY endpoint that should >>>> accept this. >>>> >>>> When you stick it in the HTTP Auth header it will likely get >>>> processed by the platform security system which then has to have >>>> special handling code to intercept this custom, undefined, >>>> unprofiled token. >>>> >>>> Of course, you could just bypass platform security on everything.... >>>>>> >>>>>>> >>>>>>> _While I think it is ok for existing implementations to continue >>>>>>> with this practice_, I would prefer to standardize passing of >>>>>>> client software assertion metadata outside of the authentication >>>>>>> channel in HTTP. >>>>>> >>>>>> The token in question is fundamentally an authorization mechanism >>>>>> for calling the registration endpoint. I agree there's value in >>>>>> passing client software assertions around, and that we should >>>>>> solve that in an interoperable way, but that's a completely >>>>>> separate question from registration. >>>> >>>> [PH] What you are passing in Blue Button is a software assertion. >>>> It's not an authorization or an authentication. Authorization >>>> would have to be issued locally. Authentication, could be >>>> federated, but there are no authn statements are there. So it is a >>>> bearer software assertion. The only reason it is better than UUID >>>> is that we can evaluate trust of a third party with regards to the >>>> statements contained. >>>>>> >>>>>>> >>>>>>> A further benefit is that the registration endpoint >>>>>>> authentication system only has to deal with locally issued >>>>>>> credentials. The logic for handling federated client meta data >>>>>>> can be isolated to the registration server logic. >>>>>> >>>>>> You can still do that if your registration server is the one >>>>>> generating the initial access token. Normally, the registration >>>>>> endpoint's going to be tightly tied to the authorization server, >>>>>> and whatever process is used to get the initial registration >>>>>> token is going to also be tightly tied to the registration server. >>>> >>>> [PH] I think the whole point of having an "initial authentication >>>> assertion" is that it is federated -- generated by third party. Why >>>> would I bother if it is local? >>>>>> >>>>>>> >>>>>>> My feeling is that if we keep "initial authorization credential" >>>>>>> as being passed in the HTTP Authorization header, then strict >>>>>>> rules about the contents of the token and the processing rules >>>>>>> must be defined so that HTTP server security systems can be >>>>>>> extended to support this. >>>>>> >>>>>> It's an OAuth token. >>>> >>>> [PH[ NO IT IS NOT. The token is issued by a third party provider. >>>> Besides when someone says "OAuth Token" I take that to mean an >>>> ACCESS token. If it is anything else it is just a JWT or SAML token. >>>> >>>>>> You use whatever HTTP security systems that you already have to >>>>>> process OAuth tokens on it. If you also want to use it to tell >>>>>> you something about client metadata, you're going to have to >>>>>> define further processing, yes, because "an OAuth token" doesn't >>>>>> tell you anything about what's inside of it or what the token >>>>>> means -- on purpose. But you'd have to do the same thing with >>>>>> software_id. But nothing is saying that you need to do that, or >>>>>> that it has to be an assertion at all. Maybe you just want to >>>>>> lock down your API to know developers, so you issue them hex >>>>>> blobs to call the API with. Those could expire 5 minutes from >>>>>> when you issued them, if you wanted. Or they could be SAML blobs, >>>>>> or JWTs, or anything else that can pass for an OAuth token. >>>>>> There's no reason any of this should be disallowed by the >>>>>> registration spec, because the registration spec doesn't care. >>>>>> All it cares about is that it's an OAuth token and it's (somehow) >>>>>> validated by the registration endpoint in such a way that the >>>>>> HTTP call to the Registration Endpoint is valid. This is >>>>>> absolutely bog-standard OAuth Protected Resource here. By >>>>>> defining it as an OAuth token (and no further), we immediately >>>>>> gain all of the flexibility and power of OAuth tokens. >>>> >>>> [PH} Sure what you suggest can and will work. But it is 10x more >>>> complex architecturally. >>>>>> >>>>>>> >>>>>>> If we use software_id, and indicate that it can accept a >>>>>>> "software registration assertion", we can be more flexible and >>>>>>> minimize the processing rules we have to declare in the draft. >>>>>>> That said, if there is a case to adopt strict rules here too, I >>>>>>> am open. >>>>>> >>>>>> I still think that software_id is really only useful and >>>>>> interoperable in the presence of strict rules, which is why I'm >>>>>> not convinced it belongs in the draft as is and instead belongs >>>>>> in an extension that defines such rules. This draft would be way >>>>>> beyond the two paragraphs that you had spoken of previously, and >>>>>> it would be both useful and interoperable. But it's enough >>>>>> complexity and enough of a very specific corner case that I am >>>>>> not at all comfortable putting that level of processing into the >>>>>> dynamic registration draft. I am willing to put software_id into >>>>>> dynamic registration as a hook to some future-to-be-defined >>>>>> specification that tells you how to validate it and parse it and >>>>>> use it for validating client metadata and tie it to a developer >>>>>> and all that fun stuff -- I don't personally see the utility in >>>>>> that, but I don't think it'd really break anything if it went in >>>>>> and you thought you could use it to bootstrap your process. >>>> >>>> [PH] >>>> 1. What rules do you need around a UUID? It is JUST a unique >>>> identifier. >>>> 2. If an assertion, how is it *any* different from intial client >>>> assertion other than the component of the server that must process it? >>>> >>>> As I said, if you make it part of authentication, then complexity >>>> increases and therefore we would have to tightly profile the >>>> assertion so that token authentication system will accept these >>>> federated tokens. >>>> >>>> If you leave it as part of software_id, then we can be more >>>> informal (to a point). >>>> >>>> I can't help this, it is just the way servers are made. The horse >>>> has left the barn as John says. >>>>>> >>>>>> -- Justin >>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000002000401070504050609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still needs to be tightly defined.


On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application.     That is declared out of scope because the token is optional and there are lots of ways developers can get them.

I see it as a OAuth access token with some scopes attached to it like any other access token.   You seem to be thinking it is something else.   I don't understand what third party would be issuing these tokens.  You seem to have a use case in mind but I don't think I understand it.

John B.

On 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com> wrote:



=nat via iPhone

May 25, 2013 7:16、Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   They are OAuth tokens and you can cram an assertion in them if you like.  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server.  But that just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers.  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this assertion being presented in this way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed client metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on everything….


While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion.  It's not an authorization or an authentication.  Authorization would have to be issued locally.  Authentication, could be federated, but there are no authn statements are there.  So it is a bearer software assertion.  The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained.  


A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. 

[PH]  I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT.  The token is issued by a third party provider.  Besides when someone says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else it is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a point).

I can't help this, it is just the way servers are made.  The horse has left the barn as John says.

 -- Justin

_______________________________________________
OAuth mailing 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

--------------000002000401070504050609-- From Michael.Jones@microsoft.com Tue May 28 08:12:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23D21F977A for ; Tue, 28 May 2013 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peHsKPnqaGc8 for ; Tue, 28 May 2013 08:12:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7ED21F9433 for ; Tue, 28 May 2013 08:12:11 -0700 (PDT) Received: from BY2FFO11FD020.protection.gbl (10.1.15.202) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.698.0; Tue, 28 May 2013 15:12:09 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Tue, 28 May 2013 15:12:08 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 28 May 2013 15:12:07 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -11 drafts and JWT -08 released Thread-Index: Ac5btZuYMcqTY79JTVWqRkdQbRaJ/wAAAq7A Date: Tue, 28 May 2013 15:12:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677B7D07@TK5EX14MBXC285.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943677B7D07TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454002)(189002)(199002)(47736001)(31966008)(74502001)(50986001)(51856001)(76176001)(16406001)(59766001)(74366001)(69226001)(74876001)(16297215003)(65816001)(79102001)(53806001)(54316002)(47976001)(56776001)(80022001)(4396001)(47446002)(55846006)(20776003)(6806003)(44976003)(33656001)(54356001)(63696002)(74662001)(77982001)(81342001)(49866001)(15202345002)(16236675002)(512954002)(81542001)(71186001)(74706001)(56816002)(66066001)(76482001)(46102001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB006; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0860FE717F Subject: [OAUTH-WG] FW: JOSE -11 drafts and JWT -08 released X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 15:12:17 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943677B7D07TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Tuesday, May 28, 2013 8:11 AM To: jose@ietf.org Subject: JOSE -11 drafts and JWT -08 released The -11 drafts of the JSON Object Signing and Encryption (JOSE) specifications have been released that incorpora= te the changes agreed to at the interim working group meeting last month. = Most of the changes were to the JWS and JWE JSON Serialization representati= ons, enabling more flexible treatment of header parameter values. Other ch= anges included removing the Encrypted Key value from the JWE integrity calc= ulation, saying more about key identification, adding key identification pa= rameters to some of the examples, clarifying the use of "kid" values in JWK= Sets, enabling X.509 key representations in JWKs, recommending protecting = JWKs containing non-public information by encrypting them with JWE, adding = "alg" values for RSASSA-PSS, registering additional MIME types, and a numbe= r of clarifications. A corresponding -08 JSON Web Token (JWT) spec was als= o released that updated the encrypted JWT example value to track the JWE ch= ange. Hopefully this will be the last breaking change to the encryption ca= lculations. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-11= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-1= 1.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-11.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-1= 1.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-08.ht= ml -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D103= 1. --_000_4E1F6AAD24975D4BA5B1680429673943677B7D07TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Tuesday, May 28, 2013 8:11 AM
To: jose@ietf.org
Subject: JOSE -11 drafts and JWT -08 released

 

The -11 drafts of the JSON Object Signing and Encryption (JOSE) specifications have been rele= ased that incorporate the changes agreed to at the interim working group me= eting last month.  Most of the changes were to the JWS and JWE JSON Se= rialization representations, enabling more flexible treatment of header parameter values.  Other changes in= cluded removing the Encrypted Key value from the JWE integrity calculation,= saying more about key identification, adding key identification parameters= to some of the examples, clarifying the use of “kid<= /span>” values in JWK Sets, enabling X.509 key representations in JWK= s, recommending protecting JWKs containing non-public information by encryp= ting them with JWE, adding “alg” values for RSASSA-PSS, registering additional MIME types, and a number of = clarifications.  A corresponding -08 JSON Web Token (JWT) spec was als= o released that updated the encrypted JWT example value to track the JWE ch= ange.  Hopefully this will be the last breaking change to the encryption calculations.

 

The specifications are available at:

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

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

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

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

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

 

HTML formatted versions are available at:=

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

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

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

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

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

 

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

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1031.

 

--_000_4E1F6AAD24975D4BA5B1680429673943677B7D07TK5EX14MBXC285r_-- From ve7jtb@ve7jtb.com Tue May 28 08:17:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C842721F979F for ; Tue, 28 May 2013 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTs8BAY6pSwA for ; Tue, 28 May 2013 08:17:37 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7BD21F97A1 for ; Tue, 28 May 2013 08:17:34 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e14so3203825iej.29 for ; Tue, 28 May 2013 08:17:34 -0700 (PDT) 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=Xhv1/oEhNg+SRWcq0WNtyKqO/q/YenAGxQgiScviqms=; b=ZAwscYNkvOWHLo4LIXrJiATFq2GE37NrD0afMeGz9vLGMgTPhy8JsTnsE3mWqZT53c LfPLqjhAJq1iC0x/H0QCVwZad6lTPqEzcYR57bzxra5eSLysOQBnfpPjCGcL+D2+Xcyx LpedDVUpixuQG/u3+O0sMB1v4EIzLK1QcY/0l4Fa/KXYDLQT7weIb/G69983McKdWwko 2vZl0ElcVA9Qz4DUiyEAnGLZbdK20U7vxoj/nliNCuWEdYrusH/h87AEsSQwlHYJzR1f 6hq6S/i6IAOgibzTVEPxHZY0Ce76l+hVavDTkWbPHJYNN7Z42Tpjbs6Pljmj7u2+pCGe Vw0w== X-Received: by 10.50.171.161 with SMTP id av1mr7108866igc.104.1369754253846; Tue, 28 May 2013 08:17:33 -0700 (PDT) Received: from [192.168.1.36] (190-20-51-3.baf.movistar.cl. [190.20.51.3]) by mx.google.com with ESMTPSA id xf4sm18354936igb.8.2013.05.28.08.17.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 08:17:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0E617804-B888-45F0-9E22-204D634C01A9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51A4C4F8.2090704@mitre.org> Date: Tue, 28 May 2013 11:17:19 -0400 Message-Id: References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> <51A4C4F8.2090704@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQksU1y6vHF1x8wq+xGQLd3oRj/yVkqR/LKI4MWkGdjXfCwmELlBW0rXyuvQzk0t87SeTSGE Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 15:17:41 -0000 --Apple-Mail=_0E617804-B888-45F0-9E22-204D634C01A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_A55CFAD9-02A4-43BF-8120-BB991F9E0034" --Apple-Mail=_A55CFAD9-02A4-43BF-8120-BB991F9E0034 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK that makes a bit more sense. What BB+ is doing with federated tokens = is supported by Dynamic Registration but not part of it. I think the federated OAuth tokens for access to the Registration = Endpoint is out of scope for this spec. =20 I agree that federated access tokens for OAuth are something that = generally needs profiling, but is a larger and more general issue. Nothing in Dynamic Registration requires that the access tokens be = anything other than access tokens issued by the AS providing the = Registration endpoint. John B. On 2013-05-28, at 10:53 AM, Justin Richer wrote: > In BB+, our OAuth tokens are federated because we're doing federated = OAuth using signed/structured tokens and introspection endpoints that = the AS and PR know what to do with. We're fundamentally using the = initial access token as an authorization for calling the endpoint and = triggering special privileges, and in order to process that = authorization we've specified how to parse the token as an assertion and = do discovery and binding to various components of that assertion. But as = far as the protocol is concerned, it's an authorization to the endpoint. >=20 > There is absolutely no reason that I can think of to limit it to just = this kind of complicated scenario. You can use whatever means you want = to get the initial registration token into the client software, and = the registration endpoint can use whatever means you want to validate = the token.=20 >=20 > You're absolutely right that if you use the token to push information = around, you're going to need to specify a lot more in order to make it = interoperable. This is precisely the reason that I want to keep things = opaque at the dyn reg spec level, just like OAuth keeps things opaque at = its own level. If you also want to do something fancy with that token, = like carry an assertion, you can do it precisely because it is an = otherwise opaque OAuth token.=20 >=20 > -- Justin=20 >=20 > On 05/24/2013 08:20 PM, Phil Hunt wrote: >> The use cases I have heard of from Justin and Morteza at IIW are = based on federated scenarios. These are not just locally asserted = tokens. >>=20 >> Your assertion that the tokens are local and my assertion they are = federated suggests there are things that must be sorted out/understood. >>=20 >> I'm merely implying that if you don't want to profile this, then = don't use HTTP Auth to pass the information. The reason HTTP Auth = pushes the inter-op issues is that many deployment architectures have = multi-layers of components processing security in a platform. Thus = inter-op has to be well defined. >>=20 >> When the logic is concentrated into just OAuth registration = components, we can have looser definition IMHO. Though others will = argue the assertion still needs to be tightly defined. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-24, at 5:06 PM, John Bradley wrote: >>=20 >>> Phil, >>>=20 >>> The OAuth token used authorize access to the registration endpoint( = if one is required) would be issued by the registration server via some = method eg cut and paste from a developer portal, email or perhaps via = OAuth to a Developer API management application. That is declared = out of scope because the token is optional and there are lots of ways = developers can get them. >>>=20 >>> I see it as a OAuth access token with some scopes attached to it = like any other access token. You seem to be thinking it is something = else. I don't understand what third party would be issuing these = tokens. You seem to have a use case in mind but I don't think I = understand it. >>>=20 >>> John B. >>>=20 >>> On 2013-05-24, at 7:26 PM, Nat Sakimura wrote: >>>=20 >>>>=20 >>>>=20 >>>> =3Dnat via iPhone >>>>=20 >>>> May 25, 2013 7:16=E3=80=81Phil Hunt wrote:=20= >>>>>=20 >>>>>=20 >>>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>>>=20 >>>>>> I agree with Justin. >>>>>>=20 >>>>>> If you want tight authentication on the AS that issues the tokens = we can use OAuth for that with short lived tokens granted based on a = SAML SSO , PIV card or whatever floats your boat for authentication. >>>>>=20 >>>>> [PH] I don't want tight authn. This is *registration*. Yet we are = pretending we are authenticating when we aren't. >>>>=20 >>>> It is not authentication.=20 >>>> It is an access authorization to this API.=20 >>>>=20 >>>>>=20 >>>>>> How the tokens are issued to the OAuth client doing the = registration (not the OAuth client being registered) is up to the AS = running the registration endpoint. They are OAuth tokens and you can = cram an assertion in them if you like. =20 >>>>>=20 >>>>> [PH] This is nothing to do with my point here. >>>>>>=20 >>>>>> Dynamic registration for OAuth should be built with OAuth! =20 >>>>> [PH] Well I was going to bring that up but didn't want to freak = people out. The idea you refer to was why not use oauth to issue an = access token to registration server. But that just makes people's head = explode. >>>>>=20 >>>>>>=20 >>>>>> John B. >>>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: >>>>>>=20 >>>>>>> I completely disagree with this assessment. The latest draft = (which was just posted) has new language describing what this token is = and what it's for, and I hope that will clear things up. But even so, = let me try to address your concerns in-line. >>>>>>>=20 >>>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >>>>>>>> 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. >>>>>>>>=20 >>>>>>>=20 >>>>>>> The Client Registration Endpoint is an OAuth Protected Resource. = This token is a means for authorizing calls to the endpoint. Can you use = it for other things? Sure, just like you can use OAuth tokens for other = things (passing data about authentication, for instance). But = fundamentally, it's just another token that's scoped to one endpoint for = a specific purpose. >>>>>>>=20 >>>>>>>> The use case is very important since it opens the door for a = way for trusted entities to sign assertions that could be accepted by a = set of deployed authorization servers. For = potential software API developers (e.g. Oracle = CRM), the developer could potentially register with Oracle CRMs = registration service manually, and obtain a signed assertion = for use in their client = software. Upon initiating dynamic registration, the client software = would present the assertion as its initial authorization in the HTTP = Authorization header as Justin describes above. >>>>>>>>=20 >>>>>>>> While this has worked in practice so far, I am concerned about = this assertion being presented in this way. >>>>>>>>=20 >>>>>>>> The authentication header has special meaning to many servers. = Depending on implementation architecture, the authorization header will = first be intercepted by the authentication components in the server. = Here's where I get worried. >>>>>>>>=20 >>>>>>>> 1. The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion >>>>>>>=20 >>>>>>> That's fine. Not all OAuth tokens are authentication assertions = today, and this is just another OAuth token.=20 >>>>>>>=20 >>>>>>>> 2. The assertion isn't an authentication, but rather signed = client metadata. >>>>>>>=20 >>>>>>> If you want to interpret the token as both authorization to call = the registration endpoint as well as client metadata, you can do that. = But you're going to have to define how that metadata is passed, how it's = signed, how it's interpreted, etc. Which, you'll note, is exactly what = you can do with an OAuth token already. You can use an OAuth token as an = opaque blob, or you can define structure, signatures, etc., to pack = information inside of it. If the two always had to be together, then = OAuth would be defined with JWTs only and we'd have something that was = much less useful. >>>>>>>=20 >>>>>>>> 3. The bearer assertion is easily copied. Thus the server = should only trust this as metadata >>>>>>>=20 >>>>>>> Depends on the kind of client, and with BB+ we've defined a = matrix of client types with different policy rules (since we can control = policy in BB+ land). Our discovery and registry setup lets us enforce = these rules appropriately as well. >>>>>>>=20 >>>>>>>> 4. It ends up performing the same role as software_id >>>>>>>=20 >>>>>>> Not really. How does software_id (on its own) represent a that = the holder is authorized to make this call? You'd have to put rules = around software_id saying that it needs to be processed in a particular = way, and I think such rules are far too restrictive for this draft. = Another difference is that a bearer token isn't generally self-asserted, = and it's assumed the registration server will have some means of = validating this token, like it would with any OAuth token. It's more = like you can use the Initial Registration Token to fulfill the same role = that you're suggesting software_id be used for, which, to me, is more of = an argument against the more-limited software_id than it is against the = existing technology. >>>>>=20 >>>>> [PH] At minimum, as a UUID it is self asserted and only identifies = a common unique value shared between instances of a particular piece of = software. >>>>>=20 >>>>> But there is nothing saying it can't be a JWT signed assertion = serving the function of passing on signed client metadata. >>>>>=20 >>>>> The *big* difference is that the processing of the token occurs = within the registration endpoint. The ONLY endpoint that should accept = this. >>>>>=20 >>>>> When you stick it in the HTTP Auth header it will likely get = processed by the platform security system which then has to have special = handling code to intercept this custom, undefined, unprofiled token. >>>>>=20 >>>>> Of course, you could just bypass platform security on = everything=E2=80=A6. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> While I think it is ok for existing implementations to continue = with this practice, I would prefer to standardize passing of client = software assertion metadata outside of the authentication channel in = HTTP. >>>>>>>=20 >>>>>>> The token in question is fundamentally an authorization = mechanism for calling the registration endpoint. I agree there's value = in passing client software assertions around, and that we should solve = that in an interoperable way, but that's a completely separate question = from registration. >>>>>=20 >>>>> [PH] What you are passing in Blue Button is a software assertion. = It's not an authorization or an authentication. Authorization would = have to be issued locally. Authentication, could be federated, but = there are no authn statements are there. So it is a bearer software = assertion. The only reason it is better than UUID is that we can = evaluate trust of a third party with regards to the statements = contained. =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> A further benefit is that the registration endpoint = authentication system only has to deal with locally issued credentials. = The logic for handling federated client meta data can be isolated to the = registration server logic. >>>>>>>=20 >>>>>>> You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 >>>>>=20 >>>>> [PH] I think the whole point of having an "initial authentication = assertion" is that it is federated -- generated by third party. Why = would I bother if it is local? =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> My feeling is that if we keep "initial authorization = credential" as being passed in the HTTP Authorization header, then = strict rules about the contents of the token and the processing rules = must be defined so that HTTP server security systems can be extended to = support this. >>>>>>>=20 >>>>>>> It's an OAuth token. >>>>>=20 >>>>> [PH[ NO IT IS NOT. The token is issued by a third party provider. = Besides when someone says "OAuth Token" I take that to mean an ACCESS = token. If it is anything else it is just a JWT or SAML token. >>>>>=20 >>>>>>> You use whatever HTTP security systems that you already have to = process OAuth tokens on it. If you also want to use it to tell you = something about client metadata, you're going to have to define further = processing, yes, because "an OAuth token" doesn't tell you anything = about what's inside of it or what the token means -- on purpose. But = you'd have to do the same thing with software_id. But nothing is saying = that you need to do that, or that it has to be an assertion at all. = Maybe you just want to lock down your API to know developers, so you = issue them hex blobs to call the API with. Those could expire 5 minutes = from when you issued them, if you wanted. Or they could be SAML blobs, = or JWTs, or anything else that can pass for an OAuth token. There's no = reason any of this should be disallowed by the registration spec, = because the registration spec doesn't care. All it cares about is that = it's an OAuth token and it's (somehow) validated by the registration = endpoint in such a way that the HTTP call to the Registration Endpoint = is valid. This is absolutely bog-standard OAuth Protected Resource here. = By defining it as an OAuth token (and no further), we immediately gain = all of the flexibility and power of OAuth tokens.=20 >>>>>=20 >>>>> [PH} Sure what you suggest can and will work. But it is 10x more = complex architecturally. =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If we use software_id, and indicate that it can accept a = "software registration assertion", we can be more flexible and minimize = the processing rules we have to declare in the draft. That said, if = there is a case to adopt strict rules here too, I am open. >>>>>>>=20 >>>>>>> I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the = two paragraphs that you had spoken of previously, and it would be both = useful and interoperable. But it's enough complexity and enough of a = very specific corner case that I am not at all comfortable putting that = level of processing into the dynamic registration draft. I am willing to = put software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. >>>>>=20 >>>>> [PH] =20 >>>>> 1. What rules do you need around a UUID? It is JUST a unique = identifier. >>>>> 2. If an assertion, how is it *any* different from intial client = assertion other than the component of the server that must process it? >>>>>=20 >>>>> As I said, if you make it part of authentication, then complexity = increases and therefore we would have to tightly profile the assertion = so that token authentication system will accept these federated tokens. >>>>>=20 >>>>> If you leave it as part of software_id, then we can be more = informal (to a point). >>>>>=20 >>>>> I can't help this, it is just the way servers are made. The horse = has left the barn as John says. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A55CFAD9-02A4-43BF-8120-BB991F9E0034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK = that makes a bit more sense.  What BB+ is doing with federated = tokens is supported by Dynamic Registration but not part of it.
I = think the federated OAuth tokens for access to the Registration Endpoint = is out of scope for this spec.   

I = agree that federated access tokens for OAuth are something that = generally needs profiling, but is a larger and more general = issue.

Nothing in Dynamic Registration requires = that the access tokens be anything other than access tokens issued by = the AS providing the Registration = endpoint.

John = B.

On 2013-05-28, at 10:53 AM, Justin = Richer <jricher@mitre.org> = wrote:

=20 =20
In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The = reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well = defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though = others will argue the assertion still needs to be tightly = defined.


On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application.   =   That is declared out of scope because the token is optional and there are lots of ways developers can get them.

I see it as a OAuth access token with some scopes attached to it like any other access token.   You = seem to be thinking it is something else.   I don't understand what third party would be issuing these tokens.  You seem to have a use case in mind but I = don't think I understand it.

John B.

On 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com> wrote:



=3Dnat via iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this = API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   They = are OAuth tokens and you can cram an assertion in them if you like. =  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth! =  
[PH]  Well I was going to bring that up = but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server. =  But that just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

= I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers.  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon = initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes = above.

While this has worked in practice so far, I am concerned about this assertion being presented in this way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's where I get = worried.

1.  The = assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth = token. 

2.  The = assertion isn't an authentication, but rather signed client metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The = bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as = well.

4.  It ends = up performing the same role as = software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another = difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on everything=E2=80=A6.


While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion.  It's not an authorization or an authentication.  Authorization would have to be issued locally.  Authentication, could be federated, but there are no authn statements are there.  So it is a bearer software assertion.  The only reason it is = better than UUID is that we can evaluate trust of a third party with regards to the statements contained.  

=

A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 

[PH]  I think the whole point of having = an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local? =  

=

My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT.  The token is issued = by a third party provider.  Besides when = someone says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else = it is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  
=

If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a = point).

I can't help this, it is just the way servers are made.  The horse has left = the barn as John says.

 -- Justin

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

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


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




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


= --Apple-Mail=_A55CFAD9-02A4-43BF-8120-BB991F9E0034-- --Apple-Mail=_0E617804-B888-45F0-9E22-204D634C01A9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI4MTUxNzIwWjAjBgkqhkiG9w0BCQQxFgQUJK559H1q PpysgBFpzNXPP34Fga4wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAEMsYdQVQuQ5gnqNDimMSeyEm5l01joLdTi0MuA3x iAscyrAWcjx5vXrLyrHCu7zDL+s8dsRQ3V7NCAjKI1q2lHm+fXa2UyXknacvG+N7aYa3oCft/84E gCaDwo0vYt8dNJ40Y7O4wA1bgZxostPjIfhuh7ctUr3RY1zd8p8FsWKX8W9IszV8u6957ZD9NFiR fuweZoOCOEgkwG+gkykMmRMK3/5Do4hRuf3tVtA8PgpPNsY5nIa4I/5ro7r6ztzWfzBqkuSL7jHx LLmAvW5JbR2JLUNr8rxyFoPo9ashFkAHUXpkNdiTSsV4M+Owb45KTuC/89GM9wm4+/9jI7RIyQAA AAAAAA== --Apple-Mail=_0E617804-B888-45F0-9E22-204D634C01A9-- From jricher@mitre.org Tue May 28 08:43:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8046B21F9738 for ; Tue, 28 May 2013 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkWv8i7n-WX0 for ; Tue, 28 May 2013 08:43:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 684AF21F9750 for ; Tue, 28 May 2013 08:43:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B9EF11F076F; Tue, 28 May 2013 11:43:39 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 619A81F075B; Tue, 28 May 2013 11:43:38 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 28 May 2013 11:43:37 -0400 Message-ID: <51A4D083.2050605@mitre.org> Date: Tue, 28 May 2013 11:42:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> <96A405B0-058E-4E9E-B6F9-E4E80256BB1F@ve7jtb.com> <526A2B4E-BC21-4F5D-8D97-36DE703C90F2@oracle.com> In-Reply-To: <526A2B4E-BC21-4F5D-8D97-36DE703C90F2@oracle.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 15:43:47 -0000 The main problem comes with establishing the client_id across multiple auth servers, not across multiple copies of the code. One of the key things that the DynReg spec does is establish a client_id for a client at an AS, and indeed the trigger condition for using it is generally "I'm a client and I don't have a client_id for an AS that I want to talk to". Between yours and Torsten's comments, though, I think a discussion under the security considerations is a good idea. -- Justin On 05/27/2013 02:46 PM, Phil Hunt wrote: > John/Josh, > > I am afraid it is still not clear to me what is the value of implicit client dynamic registration. If you allow dynamic registration of a client, each client, then each client can specify random redirect_uri's. This would seem to be a major issue. The whole point behind implicit flow is NO client authentication. So what technical or operational benefit of registering an execution instance? > > Maybe, the horse has left the barn. But I don't see that as a reason to standardize an unsafe or pointless practice. I'm not saying it is pointless. I'm just not clear on what the benefit is. > > I am curious about Josh's use case. How is the client code developed, distributed, and deployed? Are there already inherent mechanisms where OOB deployment registration is easy to achieve? IOW Each client use can easily obtain an OOB client_id. Josh expresses he needs to register, but the question I am asking is why? It seems that in his case, the code being downloaded must be coming from a common trusted source. If so, what benefit is gained with dynamic registration for these clients. They should just use a static client_id -- even something akin to the initial client assertion Justin talks about. > > From an operational aspect, issuing per execution context client_ids (and potential per client_id registration access tokens), etc per client seems to be wasteful for both the implicit client code and especially the AS/Resource SPs. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-24, at 2:38 PM, John Bradley wrote: > >> Phil, >> >> I think the horse is out of the barn on implicit flow. >> >> Many websites use implicit rather than code now, it is no worse, and perhaps better than using code flow with a client that is not confidential( though Dynamic registration can dix the public client code flow problem for native apps etc) >> >> Implicit as you well know relies on registration of the redirect URI to identify the client. There may be multiple JS apps in browsers all using JS from the same redirect URI, but I don't think that should preclude the backend website from using an API to register. >> >> Turning off dynamic registration entirely for implicit flow is overkill. A registration server is free to not allow dynamic registration of implicit clients if that is it's policy. >> >> In general I have a hard time seeing implicit clients with a server component using dynamic registration directly. I suppose there may be HTML5 based clients that are loaded as browser extensions and use implicit, without having a server based redirect. Those can be as long lived as any native app. If clean up is an issue it is one for code flow as well. >> >> John B. >> >> On 2013-05-24, at 2:35 PM, Phil Hunt wrote: >> >>> I wanted to bring out a quick discussion to ask the question if it makes sense to support implicit clients in dynamic registration. >>> >>> By definition, implicit clients are unauthenticated. Therefore the only purpose to register an implicit client is to obtain a client_id with a particular AS instance. >>> >>> A few issues to consider: >>> * Implicit clients typically run in browsers (javascript). Do we really want each occurrence of a browser running a client to register? >>> --> This could mean even the same browser running implicit flow repeat times, would register repeatedly. >>> --> If registration occurs per occurrence, what is the value? >>> >>> * What use cases typically occur for deployment against different AS and Resource API instances? >>> --> Eg. I can see a javascript component of a web site that uses a corresponding resource API. So it may be possible that the javascript and the resource API are running in the same domain. In this case, the javascript code, though written as part of a shared library/distribution, is still bound to a configured AS deployment. Is it really dynamic? If this is the case, wouldn't an OOB registration that updates the client_id in the deployment be better suited? >>> --> Are there any examples of javascript clients that need to connect to one or more AS servers on a truly dynamic basis? >>> >>> * Is there a DOS attack possible (even unintentionally) because implicit clients will start to register frequently creating huge numbers of client_ids that cause spin-off provisioning issues depending on how AS registration, token, and policy systems are implemented? >>> >>> Apparently OIDC and UMA had these profiles supported before, but I'm really trying to understand why implicit clients should have dynamic registration support. Would appreciate any discussion on this. At minimum, there are probably some security considerations we need to think through and document. >>> >>> Thanks for your comments, >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Tue May 28 09:33:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3636721F9803 for ; Tue, 28 May 2013 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLD2bpjrN17c for ; Tue, 28 May 2013 09:33:46 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2D29521F96D8 for ; Tue, 28 May 2013 09:33:46 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so3743161bkc.18 for ; Tue, 28 May 2013 09:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qWuczdjwJ2V8OgBAl7gxokYrgIL3Uz6bcpwAPvSuvIQ=; b=CaCUCvCuV3byO0k5Rhf3OLYzA3wZ+YRulOmYZeKfYLlG8ILA2iIa7T96HZXt5+sPgd ZKmq8f/RXfT60vYO25P1pdYhgQhtjZzGL3BGRr8O+89nAfifAEN3/W5s03KeL+eoODBi 4k2rzLEXpuZ1QNsH8vMR6j+SUpMP+84/rhWoxUryq5FN6GYhU2fppb6kW73NNPjGLb9O cBzCgCa5vvpcNILFRnecED1Nm8Cpwm0306Hy1j0wDd6GejK5HW9gAAIvxw034QHYUacC ZqCkuflsyVr4KnmmcwNOOy1UZv4euwBFUPThq2FEI2HlBG1Kk5hyVCZOt1dNpvCJxffa D7Eg== MIME-Version: 1.0 X-Received: by 10.204.26.8 with SMTP id b8mr13651690bkc.83.1369758825230; Tue, 28 May 2013 09:33:45 -0700 (PDT) Received: by 10.204.228.8 with HTTP; Tue, 28 May 2013 09:33:45 -0700 (PDT) In-Reply-To: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> Date: Tue, 28 May 2013 09:33:45 -0700 Message-ID: From: Dick Hardt To: O Auth WG Content-Type: multipart/alternative; boundary=047d7bb70dde34f70804ddc9d4ab Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 16:33:47 -0000 --047d7bb70dde34f70804ddc9d4ab Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Following up on this topic ... On Wed, May 1, 2013 at 2:12 PM, Dick Hardt wrote: > "iss" and "aud" would be optional parameters in a JWE. These parameters > are in the payload, but since it is encrypted, the payload must be > decrypted before they can be read. Some times knowing these parameters is > required to be able to decrypt the payload =85 > > These would be additions to 9.3.1 in the JWT specification. > > Why "iss" is needed: > > Bob and Charlie each gave Alice a KID and a symmetric key to use to verif= y > and decrypt tokens from them. > > The App and Alice share keys so Alice knows it is the App. > > The User authorizes Bob to give the App a token (which authorizes the App > to do something) > > The App gives the token to Alice. > > Since Alice indirectly received the token, the only way for Alice to kno= w > who sent the token, is to look at the KID as the "iss" claim is encrypted= . > If the "kid" values are GUIDs, then Alice can just look up the "kid" and > retrieve the associated symmetric key, and then decrypt and verify the > token and THEN see who sent it. If there is a collision in KID values (Bo= n > and Charlie gave the same KID for different keys), then Alice will not kn= ow > which symmetric key to use. > > Why "aud" is needed: > > Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and > symmetric key to Gwen. > > Ellen and Gwen trust each other and know how to talk to each other. Gwen > does not know Dave. Ellen does not know Frank > > The App and Gwen share keys so Gwen knows it is the App. > > The User authorizes Dave to give the App a token > > Dave gives the token to Gwen (Dave does not have a relationship with Elle= n) > > Gwen now has a token that Ellen can decrypt and verify, but has no method > for knowing that Ellen can do that. The "aud" property would allow Gwen t= o > give the token to Ellen to decrypt and verify. --=20 -- Dick --047d7bb70dde34f70804ddc9d4ab Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Following up on this topic ...=A0


On Wed, May 1, 2013 at 2:12 PM, Di= ck Hardt <dick.hardt@gmail.com> wrote:
"iss" and "aud" would be= optional parameters in a JWE. These parameters are in the payload, but sin= ce it is encrypted, the payload must be decrypted before they can be read. = Some times knowing these parameters is required to be able to decrypt the p= ayload =85

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify = and decrypt tokens from them.

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App t= o do something)

The App gives the token to Alice.

Since Alice indirectly received the token, =A0the only way for Alice to kno= w who sent the token, is to look at the KID as the "iss" claim is= encrypted. If the "kid" values are GUIDs, then Alice can just lo= ok up the "kid" and retrieve the associated symmetric key, and th= en decrypt and verify the token and THEN see who sent it. If there is a col= lision in KID values (Bon and Charlie gave the same KID for different keys)= , then Alice will not know which symmetric key to use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symm= etric key to Gwen.

Ellen and Gwen trust each other and know how to talk to each other. Gwen do= es not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)=

Gwen now has a token that Ellen can decrypt and verify, but has no method f= or knowing that Ellen can do that. The "aud" property would allow= Gwen to give the token to Ellen to decrypt and verify.



--
-- Dick
--047d7bb70dde34f70804ddc9d4ab-- From phil.hunt@oracle.com Tue May 28 09:36:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173721F9858 for ; Tue, 28 May 2013 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5rJreY-xBAX for ; Tue, 28 May 2013 09:36:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9821F9853 for ; Tue, 28 May 2013 09:36:26 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4SGaM2u022331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 May 2013 16:36:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4SGaNJW016904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2013 16:36:24 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4SGaMWP018546; Tue, 28 May 2013 16:36:23 GMT Received: from [25.66.37.95] (/24.114.41.85) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 May 2013 09:36:22 -0700 References: <3076EB9E-4218-4D9E-9ECD-F91F45DE6E79@oracle.com> <96A405B0-058E-4E9E-B6F9-E4E80256BB1F@ve7jtb.com> <526A2B4E-BC21-4F5D-8D97-36DE703C90F2@oracle.com> <51A4D083.2050605@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <51A4D083.2050605@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1CC9F1CF-D84A-41D6-8EA3-98AF3C9FA464@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 28 May 2013 09:36:20 -0700 To: Justin Richer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Implicit clients in Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 16:36:31 -0000 It is my strong opinion that giving each execution a client_id makes things m= uch worse.=20 Again now we cant tell who the risky players are since each client is anonym= ized through registration process.=20 This is just not securable by any means. IMHO.=20 Phil On 2013-05-28, at 8:42, Justin Richer wrote: > The main problem comes with establishing the client_id across multiple aut= h servers, not across multiple copies of the code. One of the key things tha= t the DynReg spec does is establish a client_id for a client at an AS, and i= ndeed the trigger condition for using it is generally "I'm a client and I do= n't have a client_id for an AS that I want to talk to". >=20 > Between yours and Torsten's comments, though, I think a discussion under t= he security considerations is a good idea. >=20 > -- Justin >=20 > On 05/27/2013 02:46 PM, Phil Hunt wrote: >> John/Josh, >>=20 >> I am afraid it is still not clear to me what is the value of implicit cli= ent dynamic registration. If you allow dynamic registration of a client, eac= h client, then each client can specify random redirect_uri's. This would se= em to be a major issue. The whole point behind implicit flow is NO client au= thentication. So what technical or operational benefit of registering an ex= ecution instance? >>=20 >> Maybe, the horse has left the barn. But I don't see that as a reason to s= tandardize an unsafe or pointless practice. I'm not saying it is pointless. I= 'm just not clear on what the benefit is. >>=20 >> I am curious about Josh's use case. How is the client code developed, di= stributed, and deployed? Are there already inherent mechanisms where OOB de= ployment registration is easy to achieve? IOW Each client use can easily o= btain an OOB client_id. Josh expresses he needs to register, but the quest= ion I am asking is why? It seems that in his case, the code being downloade= d must be coming from a common trusted source. If so, what benefit is gained= with dynamic registration for these clients. They should just use a static c= lient_id -- even something akin to the initial client assertion Justin talks= about. >>=20 >> =46rom an operational aspect, issuing per execution context client_ids (a= nd potential per client_id registration access tokens), etc per client seems= to be wasteful for both the implicit client code and especially the AS/Reso= urce SPs. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-24, at 2:38 PM, John Bradley wrote: >>=20 >>> Phil, >>>=20 >>> I think the horse is out of the barn on implicit flow. >>>=20 >>> Many websites use implicit rather than code now, it is no worse, and per= haps better than using code flow with a client that is not confidential( tho= ugh Dynamic registration can dix the public client code flow problem for nat= ive apps etc) >>>=20 >>> Implicit as you well know relies on registration of the redirect URI to i= dentify the client. There may be multiple JS apps in browsers all using JS= from the same redirect URI, but I don't think that should preclude the back= end website from using an API to register. >>>=20 >>> Turning off dynamic registration entirely for implicit flow is overkill.= A registration server is free to not allow dynamic registration of implic= it clients if that is it's policy. >>>=20 >>> In general I have a hard time seeing implicit clients with a server comp= onent using dynamic registration directly. I suppose there may be HTML5 ba= sed clients that are loaded as browser extensions and use implicit, without h= aving a server based redirect. Those can be as long lived as any native ap= p. If clean up is an issue it is one for code flow as well. >>>=20 >>> John B. >>>=20 >>> On 2013-05-24, at 2:35 PM, Phil Hunt wrote: >>>=20 >>>> I wanted to bring out a quick discussion to ask the question if it make= s sense to support implicit clients in dynamic registration. >>>>=20 >>>> By definition, implicit clients are unauthenticated. Therefore the only= purpose to register an implicit client is to obtain a client_id with a part= icular AS instance. >>>>=20 >>>> A few issues to consider: >>>> * Implicit clients typically run in browsers (javascript). Do we really= want each occurrence of a browser running a client to register? >>>> --> This could mean even the same browser running implicit flow repeat= times, would register repeatedly. >>>> --> If registration occurs per occurrence, what is the value? >>>>=20 >>>> * What use cases typically occur for deployment against different AS an= d Resource API instances? >>>> --> Eg. I can see a javascript component of a web site that uses a cor= responding resource API. So it may be possible that the javascript and the r= esource API are running in the same domain. In this case, the javascript c= ode, though written as part of a shared library/distribution, is still bound= to a configured AS deployment. Is it really dynamic? If this is the case, w= ouldn't an OOB registration that updates the client_id in the deployment be b= etter suited? >>>> --> Are there any examples of javascript clients that need to connect t= o one or more AS servers on a truly dynamic basis? >>>>=20 >>>> * Is there a DOS attack possible (even unintentionally) because implici= t clients will start to register frequently creating huge numbers of client_= ids that cause spin-off provisioning issues depending on how AS registration= , token, and policy systems are implemented? >>>>=20 >>>> Apparently OIDC and UMA had these profiles supported before, but I'm re= ally trying to understand why implicit clients should have dynamic registrat= ion support. Would appreciate any discussion on this. At minimum, there ar= e probably some security considerations we need to think through and documen= t. >>>>=20 >>>> Thanks for your comments, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From phil.hunt@oracle.com Tue May 28 10:00:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3231B11E80D1 for ; Tue, 28 May 2013 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyxDUqKBMZ6Y for ; Tue, 28 May 2013 10:00:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 772BF11E80BA for ; Tue, 28 May 2013 10:00:22 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4SH0Da5014989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 May 2013 17:00:14 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4SH0C7x016230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2013 17:00:13 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4SH0BGV021015; Tue, 28 May 2013 17:00:11 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 May 2013 10:00:10 -0700 References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> <51A4C4F8.2090704@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <51A4C4F8.2090704@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-6026DF01-BE59-4D5A-9A61-16054C8E2AB4 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 28 May 2013 10:00:10 -0700 To: Justin Richer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 17:00:37 -0000 X-List-Received-Date: Tue, 28 May 2013 17:00:37 -0000 --Apple-Mail-6026DF01-BE59-4D5A-9A61-16054C8E2AB4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Http auth is not the place to be passing non-standard assertions where tight= er interop is needed.=20 Using a parameter is better suited for this.=20 Phil On 2013-05-28, at 7:53, Justin Richer wrote: > In BB+, our OAuth tokens are federated because we're doing federated OAuth= using signed/structured tokens and introspection endpoints that the AS and P= R know what to do with. We're fundamentally using the initial access token a= s an authorization for calling the endpoint and triggering special privilege= s, and in order to process that authorization we've specified how to parse t= he token as an assertion and do discovery and binding to various components o= f that assertion. But as far as the protocol is concerned, it's an authoriza= tion to the endpoint. >=20 > There is absolutely no reason that I can think of to limit it to just this= kind of complicated scenario. You can use whatever means you want to get th= e initial registration token into the client software, and the registration e= ndpoint can use whatever means you want to validate the token.=20 >=20 > You're absolutely right that if you use the token to push information arou= nd, you're going to need to specify a lot more in order to make it interoper= able. This is precisely the reason that I want to keep things opaque at the d= yn reg spec level, just like OAuth keeps things opaque at its own level. If y= ou also want to do something fancy with that token, like carry an assertion,= you can do it precisely because it is an otherwise opaque OAuth token.=20 >=20 > -- Justin=20 >=20 > On 05/24/2013 08:20 PM, Phil Hunt wrote: >> The use cases I have heard of from Justin and Morteza at IIW are based on= federated scenarios. These are not just locally asserted tokens. >>=20 >> Your assertion that the tokens are local and my assertion they are federa= ted suggests there are things that must be sorted out/understood. >>=20 >> I'm merely implying that if you don't want to profile this, then don't us= e HTTP Auth to pass the information. The reason HTTP Auth pushes the inter-= op issues is that many deployment architectures have multi-layers of compone= nts processing security in a platform. Thus inter-op has to be well defined= . >>=20 >> When the logic is concentrated into just OAuth registration components, w= e can have looser definition IMHO. Though others will argue the assertion s= till needs to be tightly defined. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-24, at 5:06 PM, John Bradley wrote: >>=20 >>> Phil, >>>=20 >>> The OAuth token used authorize access to the registration endpoint( if o= ne is required) would be issued by the registration server via some method e= g cut and paste from a developer portal, email or perhaps via OAuth to a Dev= eloper API management application. That is declared out of scope because= the token is optional and there are lots of ways developers can get them. >>>=20 >>> I see it as a OAuth access token with some scopes attached to it like an= y other access token. You seem to be thinking it is something else. I do= n't understand what third party would be issuing these tokens. You seem to h= ave a use case in mind but I don't think I understand it. >>>=20 >>> John B. >>>=20 >>> On 2013-05-24, at 7:26 PM, Nat Sakimura wrote: >>>=20 >>>>=20 >>>>=20 >>>> =3Dnat via iPhone >>>>=20 >>>> May 25, 2013 7:16=E3=80=81Phil Hunt wrote:=20 >>>>>=20 >>>>>=20 >>>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>>>=20 >>>>>> I agree with Justin. >>>>>>=20 >>>>>> If you want tight authentication on the AS that issues the tokens we c= an use OAuth for that with short lived tokens granted based on a SAML SSO , P= IV card or whatever floats your boat for authentication. >>>>>=20 >>>>> [PH] I don't want tight authn. This is *registration*. Yet we are pret= ending we are authenticating when we aren't. >>>>=20 >>>> It is not authentication.=20 >>>> It is an access authorization to this API.=20 >>>>=20 >>>>>=20 >>>>>> How the tokens are issued to the OAuth client doing the registration (= not the OAuth client being registered) is up to the AS running the registrat= ion endpoint. They are OAuth tokens and you can cram an assertion in them i= f you like. =20 >>>>>=20 >>>>> [PH] This is nothing to do with my point here. >>>>>>=20 >>>>>> Dynamic registration for OAuth shou= ld be built with OAuth! =20 >>>>> [PH] Well I was going to bring that up but didn't want to freak peopl= e out. The idea you refer to was why not use oauth to issue an access token t= o registration server. But that just makes people's head explode. >>>>>=20 >>>>>>=20 >>>>>> John B. >>>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." wr= ote: >>>>>>=20 >>>>>>> I completely disagree with this = assessment. The latest draft (which was just posted) has new language de= scribing what this token is and what it's for, and I hope that will clear th= ings up. But even so, let me try to address your concerns in-line. >>>>>>>=20 >>>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I have been struggling with the concept of an initial client = credential covered in the current d= raft (rev 10): >>>>>>>> The Client Registration Endpoint MAY accept an initial authorizatio= n >>>>>>>> credential in the form of an OAuth 2.0 [RFC6749] access token in= >>>>>>>> order to limit registration to only previously authorized partie= s. >>>>>>>> The method by which this access token is obtained by the registr= ant >>>>>>>> is generally out-of-band and is out of scope of this specificati= on. >>>>>>>=20 >>>>>>> The Client Registration Endpoint is an OAuth Protected Resource. Thi= s token is a means for authorizing calls to the endpoint. Can you use it for= other things? Sure, just like you can use OAuth tokens for other things (pa= ssing data about authentication, for instance). But fundamentally, it's just= another token that's scoped to one endpoint for a specific purpose. >>>>>>>=20 >>>>>>>> The use case is very important since it opens the door for a way fo= r trusted entities to sign assertions that could be accepted by a set of dep= loyed authorization serv= ers. For potential software API developers (e.g. Oracle CRM), the developer= could potentially register with Oracle CRMs registration service manually, a= nd obtain a signed assertion for use in their client software. Upon initiat= ing dynamic registration, the client software would present the assertion as= its initial authorization in the HTTP Authorization header as Justin descri= bes above. >>>>>>>>=20 >>>>>>>> While this has worked in practice so far, I am concerned about this= assertion being presented in this way. >>>>>>>>=20 >>>>>>>> The authentication header has special meaning to many servers. Depe= nding on implementation architecture, the authorization header will first be= intercepted by the authentication components in the server. Here's where I= get worried. >>>>>>>>=20 >>>>>>>> 1. The assertion being presented is not an Authn assertion. There i= s no "authentication session" tied to the assertion >>>>>>>=20 >>>>>>> That's fine. Not all OAuth tokens are authentication assertions toda= y, and this is just another OAuth token.=20 >>>>>>>=20 >>>>>>>> 2. The assertion isn't an authentication, but rather signed client= metadata. >>>>>>>=20 >>>>>>> If you want to interpret the token as both authorization to call the= registration endpoint as well as client metadata, you can do that. But you'= re going to have to define how that metadata is passed, how = it's signed, how it's interpreted, etc. Which,= you'll note, is exactly what you can do with an OAuth token already. You ca= n use an OAuth token as an opaque blob, or you can define structure, signatu= res, etc., to pack information inside of it. If the two always had to be tog= ether, then OAuth would be defined with JWTs only and we'd have something th= at was much less useful. >>>>>>>=20 >>>>>>>> 3. The bearer assertion is easily copied. Thus the server should o= nly trust this as metadata >>>>>>>=20 >>>>>>> Depends on the kind of client, and with BB+ we've defined a matrix o= f client types with different policy rules (since we can control policy in B= B+ land). Our discovery and registry setup lets us enforce these rules appro= priately as well. >>>>>>>=20 >>>>>>>> 4. It ends up performing the same role as software_id >>>>>>>=20 >>>>>>> Not really. How does software_id (on its own) represent a that the h= older is authorized to make this call? You'd have to put rules around softwa= re_id saying that it needs to be processed in a particular way, and I think s= uch rules are far too restrictive for this draft. Another difference is that= a bearer token isn't generally self-asserted, and it's assumed the registra= tion server will have some means of validating this token, like it would wit= h any OAuth token. It's more like you can use the Initial Registration Token= to fulfill the same role that you're suggesting software_id be used for, wh= ich, to me, is more of an argument against the more-limited software_id than= it is against the existing technology. >>>>>=20 >>>>> [PH] At minimum, as a UUID it is self asserted and only identifies a c= ommon unique value shared between instances of a particular piece of softwar= e. >>>>>=20 >>>>> But there is nothing saying it can't be a JWT signed assertion serving= the function of passing on signed client metadata. >>>>>=20 >>>>> The *big* difference is that the processing of the token occurs within= the registration endpoint. The ONLY endpoint that should accept this. >>>>>=20 >>>>> When you stick it in the HTTP Auth header it will likely get processed= by the platform security system which then has to have special handling cod= e to intercept this custom, undefined, unprofiled token. >>>>>=20 >>>>> Of course, you could just bypass platform security on everything=E2=80= =A6. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> While I think it is ok for existing implementations to continue wit= h this practice, I would prefer to standardize passing of client software as= sertion metadata outside of the authentication channel in HTTP. >>>>>>>=20 >>>>>>> The token in question is fundamentally an authorization mechanism fo= r calling the registration endpoint. I agree there's value in passing client= software assertions around, and that we should solve that in an interoperab= le way, but that's a completely sepa= rate question from registration. >>>>>=20 >>>>> [PH] What you are passing in Blue Button is a software assertion. It'= s not an authorization or an authentication. Authorization would have to be= issued locally. Authentication, could be federated, but there are no authn= statements are there. So it is a bearer software assertion. The only reas= on it is better than UUID is that we can evaluate trust of a third party wit= h regards to the statements contained. =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> A further benefit is that the registration endpoint authentication s= ystem only has to deal with locally issued credentials. The logic for handli= ng federated client meta data can be isolated to the registration server log= ic. >>>>>>>=20 >>>>>>> You can still do that if your registration server is the one generat= ing the initial access token. Normally, the registration endpoint's going to= be tightly tied to the authorization server, and whatever process is used t= o get the initial registration token is going to also be tightly tied to the= registration server.=20 >>>>>=20 >>>>> [PH] I think the whole point of having an "initial authentication ass= ertion" is that it is federated -- generated by third party. Why would I bot= her if it is local? =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> My feeling is that if we keep "initial authorization credential" as= being passed in the HTTP Authorization header, then strict rules about the c= ontents of the token and the processing rules must be defined so that HTTP s= erver security systems can be extended to = support this. >>>>>>>=20 >>>>>>> It's an OAuth token. >>>>>=20 >>>>> [PH[ NO IT IS NOT. The token is issued by a third party provider. Be= sides when someone says "OAuth Token" I take that to mean an ACCESS token. I= f it is anything else it is just a JWT or SAML token. >>>>>=20 >>>>>>> You use whatever HTTP security systems that you already have to proc= ess OAuth tokens on it. If you also want to use it to tell you something abo= ut client metadata, you're going to have to define further processing, yes, b= ecause "an OAuth token" doesn't tell you anything about what's inside of it o= r what the token means -- on purpose. But you'd have to do the same thing wi= th software_id. But nothing is saying that you need to do that, or that it h= as to be an assertion at all. Maybe you just want to lock down your API to k= now developers, so you issue them hex blobs to call the API with. Those coul= d expire 5 minutes from when you issued them, if you wanted. Or they could b= e SAML blobs, or JWTs, or anything else that can pass for an OAuth token. Th= ere's no reason any of this should be disallowed by the registration spec, b= ecause the registration spec doesn't care. All it cares about is that it's a= n OAuth token and it's (somehow) validated by the registration endpoint in s= uch a way that the HTTP call to the Re= gistration Endpoint is valid. This is a= bsolutely bog-standard OAuth Protected Resource here. By defining it as an O= Auth token (and no further), we immediately gain all of the flexibility and p= ower of OAuth tokens.=20 >>>>>=20 >>>>> [PH} Sure what you suggest can and will work. But it is 10x more compl= ex architecturally. =20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If we use software_id, and indicate that it can accept a "software r= egistration assertion", we can be more flexible and minimize the processing r= ules we have to declare in the draft. That said, if there is a case to adopt= strict rules here too, I am open. >>>>>>>=20 >>>>>>> I still think that software_id is really only useful and interoperab= le in the presence of strict rules, which is why I'm not convinced it belong= s in the draft as is and instead belongs in an extension that defines such r= ules. This draft would be way beyond the two paragraphs that you had spoken o= f previously, and it would be both useful and interoperable. But it's enough= complexity and enough of a very specific corner case that I am not at all c= omfortable putting that level of processing into the dynamic registration dr= aft. I am willing to put software_id into dynamic registration as a hook to s= ome future-to-be-defined specifica= tion that tells you how to validate it and parse it and use it for validatin= g client metadata and tie it to a developer and all that fun stuff -- I don'= t personally see the utility in that, but I don't think it'd really break an= ything if it went in and you thought you could use it to bootstrap your proc= ess. >>>>>=20 >>>>> [PH] =20 >>>>> 1. What rules do you need around a UUID? It is JUST a unique identifi= er. >>>>> 2. If an assertion, how is it *any* differ= ent from intial client assertion other than the component of the server that= must process it? >>>>>=20 >>>>> As I said, if you make it part of authentication, then complexity incr= eases and therefore we would have to tightly profile the assertion so that t= oken authentication system will accept these federated tokens. >>>>>=20 >>>>> If you leave it as part of software_id, then we can be more informal (= to a point). >>>>>=20 >>>>> I can't help this, it is just the way serv= ers are made. The horse has left the barn as John says. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-6026DF01-BE59-4D5A-9A61-16054C8E2AB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Http auth is not the place to be passi= ng non-standard assertions where tighter interop is needed. 
=
Using a parameter is better suited for this. 

Phi= l

On 2013-05-28, at 7:53, Justin Richer <jricher@mitre.org> wrote:

=20 =20 =20 In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.<= /div>

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still needs to be tightly defined.


On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application.   &nbs= p; That is declared out of scope because the token is optional and there are lots of ways developers can get them.

I see it as a OAuth access token with some scopes attached to it like any other access token.   You seem to be thinking it is something else.   I don't understand what third party would be issuing these tokens.  You seem to have a use case in mind but I don'= t think I understand it.

John B.

On 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com= > wrote:



=3Dnat via iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   They are= OAuth tokens and you can cram an assertion in them if you like.  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but= didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server.  Bu= t that just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

=
I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.
=


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers.  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this assertion being presented in this way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's where I get worried.

1.  The assertio= n being presented is not an Authn assertion. There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 
2.  The assertio= n isn't an authentication, but rather signed client metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference= is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on everything=E2=80=A6.

=

While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion.  It's not an authorization or an authentication.  Authorization would have to be issued locally.  Authentication, could be federated, but there are no authn statements are there.  So it is a bearer software assertion.  The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained.  


A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. 

[PH]  I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT.  The token is issued by a= third party provider.  Besides when someone= says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else it is= just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a point).
=

I can't help this, it is just the way servers are made.  The horse has left the barn as John says.

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




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

=20
= --Apple-Mail-6026DF01-BE59-4D5A-9A61-16054C8E2AB4-- From jricher@mitre.org Tue May 28 10:15:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0C21F94C3 for ; Tue, 28 May 2013 10:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIPsoTPDgnKA for ; Tue, 28 May 2013 10:15:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 75CEF21F96CE for ; Tue, 28 May 2013 10:15:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4D1E4245001C; Tue, 28 May 2013 13:15:41 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 629A42650008; Tue, 28 May 2013 13:15:36 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 28 May 2013 13:15:36 -0400 Message-ID: <51A4E612.5070901@mitre.org> Date: Tue, 28 May 2013 13:14:58 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> <51A4C4F8.2090704@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060706050901080004070607" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 17:15:54 -0000 --------------060706050901080004070607 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Then pass the auth token as a parameter. RFC6750 already says you can do that. -- Justin On 05/28/2013 01:00 PM, Phil Hunt wrote: > Http auth is not the place to be passing non-standard assertions where > tighter interop is needed. > > Using a parameter is better suited for this. > > Phil > > On 2013-05-28, at 7:53, Justin Richer > wrote: > >> In BB+, our OAuth tokens are federated because we're doing federated >> OAuth using signed/structured tokens and introspection endpoints that >> the AS and PR know what to do with. We're fundamentally using the >> initial access token as an authorization for calling the endpoint and >> triggering special privileges, and in order to process that >> authorization we've specified how to parse the token as an assertion >> and do discovery and binding to various components of that assertion. >> But as far as the protocol is concerned, it's an authorization to the >> endpoint. >> >> There is absolutely no reason that I can think of to limit it to just >> this kind of complicated scenario. You can use whatever means you >> want to get the initial registration token into the client software, >> and the registration endpoint can use whatever means you want to >> validate the token. >> >> You're absolutely right that if you use the token to push information >> around, you're going to need to specify a lot more in order to make >> it interoperable. This is precisely the reason that I want to keep >> things opaque at the dyn reg spec level, just like OAuth keeps things >> opaque at its own level. If you also want to do something fancy with >> that token, like carry an assertion, you can do it precisely because >> it is an otherwise opaque OAuth token. >> >> -- Justin >> >> On 05/24/2013 08:20 PM, Phil Hunt wrote: >>> The use cases I have heard of from Justin and Morteza at IIW are >>> based on federated scenarios. These are not just locally asserted >>> tokens. >>> >>> Your assertion that the tokens are local and my assertion they are >>> federated suggests there are things that must be sorted out/understood. >>> >>> I'm merely implying that if you don't want to profile this, then >>> don't use HTTP Auth to pass the information. The reason HTTP Auth >>> pushes the inter-op issues is that many deployment architectures >>> have multi-layers of components processing security in a platform. >>> Thus inter-op has to be well defined. >>> >>> When the logic is concentrated into just OAuth registration >>> components, we can have looser definition IMHO. Though others will >>> argue the assertion still needs to be tightly defined. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-05-24, at 5:06 PM, John Bradley wrote: >>> >>>> Phil, >>>> >>>> The OAuth token used authorize access to the registration endpoint( >>>> if one is required) would be issued by the registration server via >>>> some method eg cut and paste from a developer portal, email or >>>> perhaps via OAuth to a Developer API management application. >>>> That is declared out of scope because the token is optional and >>>> there are lots of ways developers can get them. >>>> >>>> I see it as a OAuth access token with some scopes attached to it >>>> like any other access token. You seem to be thinking it is >>>> something else. I don't understand what third party would be >>>> issuing these tokens. You seem to have a use case in mind but I >>>> don't think I understand it. >>>> >>>> John B. >>>> >>>> On 2013-05-24, at 7:26 PM, Nat Sakimura >>> > wrote: >>>> >>>>> >>>>> >>>>> =nat via iPhone >>>>> >>>>> May 25, 2013 7:16、Phil Hunt >>>> > wrote: >>>>>> >>>>>> >>>>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>>>> >>>>>>> I agree with Justin. >>>>>>> >>>>>>> If you want tight authentication on the AS that issues the >>>>>>> tokens we can use OAuth for that with short lived tokens granted >>>>>>> based on a SAML SSO , PIV card or whatever floats your boat for >>>>>>> authentication. >>>>>> >>>>>> [PH] I don't want tight authn. This is *registration*. Yet we are >>>>>> pretending we are authenticating when we aren't. >>>>> >>>>> It is not authentication. >>>>> It is an access authorization to this API. >>>>> >>>>>> >>>>>>> How the tokens are issued to the OAuth client doing the >>>>>>> registration (not the OAuth client being registered) is up to >>>>>>> the AS running the registration endpoint. They are OAuth >>>>>>> tokens and you can cram an assertion in them if you like. >>>>>> >>>>>> [PH] This is nothing to do with my point here. >>>>>>> >>>>>>> Dynamic registration for OAuth should be built with OAuth! >>>>>> [PH] Well I was going to bring that up but didn't want to freak >>>>>> people out. The idea you refer to was why not use oauth to issue >>>>>> an access token to registration server. But that just makes >>>>>> people's head explode. >>>>>> >>>>>>> >>>>>>> John B. >>>>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." >>>>>>> > wrote: >>>>>>> >>>>>>>> I completely disagree with this assessment. The latest draft >>>>>>>> (which was just posted) has new language describing what this >>>>>>>> token is and what it's for, and I hope that will clear things >>>>>>>> up. But even so, let me try to address your concerns in-line. >>>>>>>> >>>>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I have been struggling with the concept of an initial client >>>>>>>>> credential covered in the current draft (rev 10): >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> The Client Registration Endpoint is an OAuth Protected >>>>>>>> Resource. This token is a means for authorizing calls to the >>>>>>>> endpoint. Can you use it for other things? Sure, just like you >>>>>>>> can use OAuth tokens for other things (passing data about >>>>>>>> authentication, for instance). But fundamentally, it's just >>>>>>>> another token that's scoped to one endpoint for a specific purpose. >>>>>>>> >>>>>>>>> The use case is very important since it opens the door for a >>>>>>>>> way for trusted entities to sign assertions that could be >>>>>>>>> accepted by a set of deployed authorization servers. For >>>>>>>>> potential software API developers (e.g. Oracle CRM), the >>>>>>>>> developer could potentially register with Oracle CRMs >>>>>>>>> registration service manually, and obtain a signed assertion >>>>>>>>> for use in their client software. Upon initiating dynamic >>>>>>>>> registration, the client software would present the assertion >>>>>>>>> as its initial authorization in the HTTP Authorization header >>>>>>>>> as Justin describes above. >>>>>>>>> >>>>>>>>> While this has worked in practice so far, I am concerned about >>>>>>>>> this assertion being presented in this way. >>>>>>>>> >>>>>>>>> The authentication header has special meaning to many servers. >>>>>>>>> Depending on implementation architecture, the authorization >>>>>>>>> header will first be intercepted by the authentication >>>>>>>>> components in the server. Here's where I get worried. >>>>>>>>> >>>>>>>>> 1. The assertion being presented is not an Authn assertion. >>>>>>>>> There is no "authentication session" tied to the assertion >>>>>>>> >>>>>>>> That's fine. Not all OAuth tokens are authentication assertions >>>>>>>> today, and this is just another OAuth token. >>>>>>>> >>>>>>>>> 2. The assertion isn't an authentication, but rather signed >>>>>>>>> client metadata. >>>>>>>> >>>>>>>> If you want to interpret the token as both authorization to >>>>>>>> call the registration endpoint as well as client metadata, you >>>>>>>> can do that. But you're going to have to define how that >>>>>>>> metadata is passed, how it's signed, how it's interpreted, etc. >>>>>>>> Which, you'll note, is exactly what you can do with an OAuth >>>>>>>> token already. You can use an OAuth token as an opaque blob, or >>>>>>>> you can define structure, signatures, etc., to pack information >>>>>>>> inside of it. If the two always had to be together, then OAuth >>>>>>>> would be defined with JWTs only and we'd have something that >>>>>>>> was much less useful. >>>>>>>> >>>>>>>>> 3. The bearer assertion is easily copied. Thus the server >>>>>>>>> should only trust this as metadata >>>>>>>> >>>>>>>> Depends on the kind of client, and with BB+ we've defined a >>>>>>>> matrix of client types with different policy rules (since we >>>>>>>> can control policy in BB+ land). Our discovery and registry >>>>>>>> setup lets us enforce these rules appropriately as well. >>>>>>>> >>>>>>>>> 4. It ends up performing the same role as software_id >>>>>>>> >>>>>>>> Not really. How does software_id (on its own) represent a that >>>>>>>> the holder is authorized to make this call? You'd have to put >>>>>>>> rules around software_id saying that it needs to be processed >>>>>>>> in a particular way, and I think such rules are far too >>>>>>>> restrictive for this draft. Another difference is that a bearer >>>>>>>> token isn't generally self-asserted, and it's assumed the >>>>>>>> registration server will have some means of validating this >>>>>>>> token, like it would with any OAuth token. It's more like you >>>>>>>> can use the Initial Registration Token to fulfill the same role >>>>>>>> that you're suggesting software_id be used for, which, to me, >>>>>>>> is more of an argument against the more-limited software_id >>>>>>>> than it is against the existing technology. >>>>>> >>>>>> [PH] At minimum, as a UUID it is self asserted and only >>>>>> identifies a common unique value shared between instances of a >>>>>> particular piece of software. >>>>>> >>>>>> But there is nothing saying it can't be a JWT signed assertion >>>>>> serving the function of passing on signed client metadata. >>>>>> >>>>>> The *big* difference is that the processing of the token occurs >>>>>> within the registration endpoint. The ONLY endpoint that should >>>>>> accept this. >>>>>> >>>>>> When you stick it in the HTTP Auth header it will likely get >>>>>> processed by the platform security system which then has to have >>>>>> special handling code to intercept this custom, undefined, >>>>>> unprofiled token. >>>>>> >>>>>> Of course, you could just bypass platform security on everything…. >>>>>>>> >>>>>>>>> >>>>>>>>> _While I think it is ok for existing implementations to >>>>>>>>> continue with this practice_, I would prefer to standardize >>>>>>>>> passing of client software assertion metadata outside of the >>>>>>>>> authentication channel in HTTP. >>>>>>>> >>>>>>>> The token in question is fundamentally an authorization >>>>>>>> mechanism for calling the registration endpoint. I agree >>>>>>>> there's value in passing client software assertions around, and >>>>>>>> that we should solve that in an interoperable way, but that's a >>>>>>>> completely separate question from registration. >>>>>> >>>>>> [PH] What you are passing in Blue Button is a software assertion. >>>>>> It's not an authorization or an authentication. Authorization >>>>>> would have to be issued locally. Authentication, could be >>>>>> federated, but there are no authn statements are there. So it is >>>>>> a bearer software assertion. The only reason it is better than >>>>>> UUID is that we can evaluate trust of a third party with regards >>>>>> to the statements contained. >>>>>>>> >>>>>>>>> >>>>>>>>> A further benefit is that the registration endpoint >>>>>>>>> authentication system only has to deal with locally issued >>>>>>>>> credentials. The logic for handling federated client meta data >>>>>>>>> can be isolated to the registration server logic. >>>>>>>> >>>>>>>> You can still do that if your registration server is the one >>>>>>>> generating the initial access token. Normally, the registration >>>>>>>> endpoint's going to be tightly tied to the authorization >>>>>>>> server, and whatever process is used to get the initial >>>>>>>> registration token is going to also be tightly tied to the >>>>>>>> registration server. >>>>>> >>>>>> [PH] I think the whole point of having an "initial >>>>>> authentication assertion" is that it is federated -- generated by >>>>>> third party. Why would I bother if it is local? >>>>>>>> >>>>>>>>> >>>>>>>>> My feeling is that if we keep "initial authorization >>>>>>>>> credential" as being passed in the HTTP Authorization header, >>>>>>>>> then strict rules about the contents of the token and the >>>>>>>>> processing rules must be defined so that HTTP server security >>>>>>>>> systems can be extended to support this. >>>>>>>> >>>>>>>> It's an OAuth token. >>>>>> >>>>>> [PH[ NO IT IS NOT. The token is issued by a third party >>>>>> provider. Besides when someone says "OAuth Token" I take that to >>>>>> mean an ACCESS token. If it is anything else it is just a JWT or >>>>>> SAML token. >>>>>> >>>>>>>> You use whatever HTTP security systems that you already have to >>>>>>>> process OAuth tokens on it. If you also want to use it to tell >>>>>>>> you something about client metadata, you're going to have to >>>>>>>> define further processing, yes, because "an OAuth token" >>>>>>>> doesn't tell you anything about what's inside of it or what the >>>>>>>> token means -- on purpose. But you'd have to do the same thing >>>>>>>> with software_id. But nothing is saying that you need to do >>>>>>>> that, or that it has to be an assertion at all. Maybe you just >>>>>>>> want to lock down your API to know developers, so you issue >>>>>>>> them hex blobs to call the API with. Those could expire 5 >>>>>>>> minutes from when you issued them, if you wanted. Or they could >>>>>>>> be SAML blobs, or JWTs, or anything else that can pass for an >>>>>>>> OAuth token. There's no reason any of this should be disallowed >>>>>>>> by the registration spec, because the registration spec doesn't >>>>>>>> care. All it cares about is that it's an OAuth token and it's >>>>>>>> (somehow) validated by the registration endpoint in such a way >>>>>>>> that the HTTP call to the Registration Endpoint is valid. This >>>>>>>> is absolutely bog-standard OAuth Protected Resource here. By >>>>>>>> defining it as an OAuth token (and no further), we immediately >>>>>>>> gain all of the flexibility and power of OAuth tokens. >>>>>> >>>>>> [PH} Sure what you suggest can and will work. But it is 10x more >>>>>> complex architecturally. >>>>>>>> >>>>>>>>> >>>>>>>>> If we use software_id, and indicate that it can accept a >>>>>>>>> "software registration assertion", we can be more flexible and >>>>>>>>> minimize the processing rules we have to declare in the draft. >>>>>>>>> That said, if there is a case to adopt strict rules here too, >>>>>>>>> I am open. >>>>>>>> >>>>>>>> I still think that software_id is really only useful and >>>>>>>> interoperable in the presence of strict rules, which is why I'm >>>>>>>> not convinced it belongs in the draft as is and instead belongs >>>>>>>> in an extension that defines such rules. This draft would be >>>>>>>> way beyond the two paragraphs that you had spoken of >>>>>>>> previously, and it would be both useful and interoperable. But >>>>>>>> it's enough complexity and enough of a very specific corner >>>>>>>> case that I am not at all comfortable putting that level of >>>>>>>> processing into the dynamic registration draft. I am willing to >>>>>>>> put software_id into dynamic registration as a hook to some >>>>>>>> future-to-be-defined specification that tells you how to >>>>>>>> validate it and parse it and use it for validating client >>>>>>>> metadata and tie it to a developer and all that fun stuff -- I >>>>>>>> don't personally see the utility in that, but I don't think >>>>>>>> it'd really break anything if it went in and you thought you >>>>>>>> could use it to bootstrap your process. >>>>>> >>>>>> [PH] >>>>>> 1. What rules do you need around a UUID? It is JUST a unique >>>>>> identifier. >>>>>> 2. If an assertion, how is it *any* different from intial client >>>>>> assertion other than the component of the server that must >>>>>> process it? >>>>>> >>>>>> As I said, if you make it part of authentication, then complexity >>>>>> increases and therefore we would have to tightly profile the >>>>>> assertion so that token authentication system will accept these >>>>>> federated tokens. >>>>>> >>>>>> If you leave it as part of software_id, then we can be more >>>>>> informal (to a point). >>>>>> >>>>>> I can't help this, it is just the way servers are made. The >>>>>> horse has left the barn as John says. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> --------------060706050901080004070607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Then pass the auth token as a parameter. RFC6750 already says you can do that.

 -- Justin

On 05/28/2013 01:00 PM, Phil Hunt wrote:
Http auth is not the place to be passing non-standard assertions where tighter interop is needed. 

Using a parameter is better suited for this. 

Phil

On 2013-05-28, at 7:53, Justin Richer <jricher@mitre.org> wrote:

In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still needs to be tightly defined.


On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application.     That is declared out of scope because the token is optional and there are lots of ways developers can get them.

I see it as a OAuth access token with some scopes attached to it like any other access token.   You seem to be thinking it is something else.   I don't understand what third party would be issuing these tokens.  You seem to have a use case in mind but I don't think I understand it.

John B.

On 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com> wrote:



=nat via iPhone

May 25, 2013 7:16、Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   They are OAuth tokens and you can cram an assertion in them if you like.  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server.  But that just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers.  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this assertion being presented in this way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed client metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on everything….


While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion.  It's not an authorization or an authentication.  Authorization would have to be issued locally.  Authentication, could be federated, but there are no authn statements are there.  So it is a bearer software assertion.  The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained.  


A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. 

[PH]  I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT.  The token is issued by a third party provider.  Besides when someone says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else it is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a point).

I can't help this, it is just the way servers are made.  The horse has left the barn as John says.

 -- Justin

_______________________________________________
OAuth mailing 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


--------------060706050901080004070607-- From ve7jtb@ve7jtb.com Tue May 28 12:02:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3A21E80A3 for ; Tue, 28 May 2013 12:02:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6XwCC54SKqT for ; Tue, 28 May 2013 12:02:19 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 877EF11E80BA for ; Tue, 28 May 2013 12:02:09 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so4552108qeb.38 for ; Tue, 28 May 2013 12:02:08 -0700 (PDT) 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=XYLk+95KgpCXMVdI/gKXzM9iSf3rqvzLm3p5dW9Kfao=; b=QALbryA6dHLSrGSqEqEHhqogJBD5qgSOLy/C3HE3jmQV3NS8u+i/LxQ62yL9dSwgR3 9ZB+1MTW41RuT6pq0R8Zz+h7M/dNSmGVaoyXBRgf3yTrUFw856uHsiGkM9SVc7gLpLsH 65YTaDfqlEHA+8i2813T9+qP9VriBHcmRhKt0ULWK/BZyA1diKCc5c0dKFRWEIiBKq6w AJMBpXk+NWgN7U+RpIU6CqPC1/unjNNc6fJHNqFq0tP/yGyRIth2GLRYJcZshIbKeayt xPRP5XisQxZmhPQg3AIZxs+zWXqRMFwP8HQLXGiWGWRUjEevDrUuMcEWYY5ggIM18YyI /Wmg== X-Received: by 10.224.61.1 with SMTP id r1mr33142046qah.93.1369767728670; Tue, 28 May 2013 12:02:08 -0700 (PDT) Received: from [192.168.1.36] (190-20-51-3.baf.movistar.cl. [190.20.51.3]) by mx.google.com with ESMTPSA id u14sm29107841qao.6.2013.05.28.12.01.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 12:02:07 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_95ACD50D-04C9-4E5D-8549-3ED88B45F1E7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51A4E612.5070901@mitre.org> Date: Tue, 28 May 2013 15:01:38 -0400 Message-Id: <9EEEB4DB-A669-4C71-8394-8D8C687875F4@ve7jtb.com> References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> <51A4C4F8.2090704@mitre.org> <51A4E612.5070901@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn8WLia1MBYfMNfd+2TFo4rAcftQVnsgsNZC725XdLmP/l0AAy8PfA6Wgc4V8S3gkqVC/oN Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 19:02:34 -0000 --Apple-Mail=_95ACD50D-04C9-4E5D-8549-3ED88B45F1E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF702C1D-023C-4934-BF15-CC01195DE4A6" --Apple-Mail=_EF702C1D-023C-4934-BF15-CC01195DE4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes it can be passed as appropriate. That is also one reason why we = separated the client_secret_post and client_secret_basic in = registration, for RS and clients who may have a limited ability to deal = with headers. On 2013-05-28, at 1:14 PM, Justin Richer wrote: > Then pass the auth token as a parameter. RFC6750 already says you can = do that. >=20 > -- Justin >=20 > On 05/28/2013 01:00 PM, Phil Hunt wrote: >> Http auth is not the place to be passing non-standard assertions = where tighter interop is needed.=20 >>=20 >> Using a parameter is better suited for this.=20 >>=20 >> Phil >>=20 >> On 2013-05-28, at 7:53, Justin Richer wrote: >>=20 >>> In BB+, our OAuth tokens are federated because we're doing federated = OAuth using signed/structured tokens and introspection endpoints that = the AS and PR know what to do with. We're fundamentally using the = initial access token as an authorization for calling the endpoint and = triggering special privileges, and in order to process that = authorization we've specified how to parse the token as an assertion and = do discovery and binding to various components of that assertion. But as = far as the protocol is concerned, it's an authorization to the endpoint. >>>=20 >>> There is absolutely no reason that I can think of to limit it to = just this kind of complicated scenario. You can use whatever means you = want to get the initial registration token into the client software, and = the registration endpoint can use whatever means you want to validate = the token.=20 >>>=20 >>> You're absolutely right that if you use the token to push = information around, you're going to need to specify a lot more in order = to make it interoperable. This is precisely the reason that I want to = keep things opaque at the dyn reg spec level, just like OAuth keeps = things opaque at its own level. If you also want to do something fancy = with that token, like carry an assertion, you can do it precisely = because it is an otherwise opaque OAuth token.=20 >>>=20 >>> -- Justin=20 >>>=20 >>> On 05/24/2013 08:20 PM, Phil Hunt wrote: >>>> The use cases I have heard of from Justin and Morteza at IIW are = based on federated scenarios. These are not just locally asserted = tokens. >>>>=20 >>>> Your assertion that the tokens are local and my assertion they are = federated suggests there are things that must be sorted out/understood. >>>>=20 >>>> I'm merely implying that if you don't want to profile this, then = don't use HTTP Auth to pass the information. The reason HTTP Auth = pushes the inter-op issues is that many deployment architectures have = multi-layers of components processing security in a platform. Thus = inter-op has to be well defined. >>>>=20 >>>> When the logic is concentrated into just OAuth registration = components, we can have looser definition IMHO. Though others will = argue the assertion still needs to be tightly defined. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-24, at 5:06 PM, John Bradley wrote: >>>>=20 >>>>> Phil, >>>>>=20 >>>>> The OAuth token used authorize access to the registration = endpoint( if one is required) would be issued by the registration server = via some method eg cut and paste from a developer portal, email or = perhaps via OAuth to a Developer API management application. That is = declared out of scope because the token is optional and there are lots = of ways developers can get them. >>>>>=20 >>>>> I see it as a OAuth access token with some scopes attached to it = like any other access token. You seem to be thinking it is something = else. I don't understand what third party would be issuing these = tokens. You seem to have a use case in mind but I don't think I = understand it. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2013-05-24, at 7:26 PM, Nat Sakimura = wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =3Dnat via iPhone >>>>>>=20 >>>>>> May 25, 2013 7:16=E3=80=81Phil Hunt = wrote:=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>>>>>=20 >>>>>>>> I agree with Justin. >>>>>>>>=20 >>>>>>>> If you want tight authentication on the AS that issues the = tokens we can use OAuth for that with short lived tokens granted based = on a SAML SSO , PIV card or whatever floats your boat for = authentication. >>>>>>>=20 >>>>>>> [PH] I don't want tight authn. This is *registration*. Yet we = are pretending we are authenticating when we aren't. >>>>>>=20 >>>>>> It is not authentication.=20 >>>>>> It is an access authorization to this API.=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> How the tokens are issued to the OAuth client doing the = registration (not the OAuth client being registered) is up to the AS = running the registration endpoint. They are OAuth tokens and you can = cram an assertion in them if you like. =20 >>>>>>>=20 >>>>>>> [PH] This is nothing to do with my point here. >>>>>>>>=20 >>>>>>>> Dynamic registration for OAuth should be built with OAuth! =20 >>>>>>> [PH] Well I was going to bring that up but didn't want to freak = people out. The idea you refer to was why not use oauth to issue an = access token to registration server. But that just makes people's head = explode. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> John B. >>>>>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." = wrote: >>>>>>>>=20 >>>>>>>>> I completely disagree with this assessment. The latest draft = (which was just posted) has new language describing what this token is = and what it's for, and I hope that will clear things up. But even so, = let me try to address your concerns in-line. >>>>>>>>>=20 >>>>>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> I have been struggling with the concept of an initial client = credential covered in the current draft (rev 10): >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The Client Registration Endpoint is an OAuth Protected = Resource. This token is a means for authorizing calls to the endpoint. = Can you use it for other things? Sure, just like you can use OAuth = tokens for other things (passing data about authentication, for = instance). But fundamentally, it's just another token that's scoped to = one endpoint for a specific purpose. >>>>>>>>>=20 >>>>>>>>>> The use case is very important since it opens the door for a = way for trusted entities to sign assertions that could be accepted by a = set of deployed authorization servers. For potential software API = developers (e.g. Oracle CRM), the developer could potentially register = with Oracle CRMs registration service manually, and obtain a signed = assertion for use in their client software. Upon initiating dynamic = registration, the client software would present the assertion as its = initial authorization in the HTTP Authorization header as Justin = describes above. >>>>>>>>>>=20 >>>>>>>>>> While this has worked in practice so far, I am concerned = about this assertion being presented in this way. >>>>>>>>>>=20 >>>>>>>>>> The authentication header has special meaning to many = servers. Depending on implementation architecture, the authorization = header will first be intercepted by the authentication components in the = server. Here's where I get worried. >>>>>>>>>>=20 >>>>>>>>>> 1. The assertion being presented is not an Authn assertion. = There is no "authentication session" tied to the assertion >>>>>>>>>=20 >>>>>>>>> That's fine. Not all OAuth tokens are authentication = assertions today, and this is just another OAuth token.=20 >>>>>>>>>=20 >>>>>>>>>> 2. The assertion isn't an authentication, but rather signed = client metadata. >>>>>>>>>=20 >>>>>>>>> If you want to interpret the token as both authorization to = call the registration endpoint as well as client metadata, you can do = that. But you're going to have to define how that metadata is passed, = how it's signed, how it's interpreted, etc. Which, you'll note, is = exactly what you can do with an OAuth token already. You can use an = OAuth token as an opaque blob, or you can define structure, signatures, = etc., to pack information inside of it. If the two always had to be = together, then OAuth would be defined with JWTs only and we'd have = something that was much less useful. >>>>>>>>>=20 >>>>>>>>>> 3. The bearer assertion is easily copied. Thus the server = should only trust this as metadata >>>>>>>>>=20 >>>>>>>>> Depends on the kind of client, and with BB+ we've defined a = matrix of client types with different policy rules (since we can control = policy in BB+ land). Our discovery and registry setup lets us enforce = these rules appropriately as well. >>>>>>>>>=20 >>>>>>>>>> 4. It ends up performing the same role as software_id >>>>>>>>>=20 >>>>>>>>> Not really. How does software_id (on its own) represent a that = the holder is authorized to make this call? You'd have to put rules = around software_id saying that it needs to be processed in a particular = way, and I think such rules are far too restrictive for this draft. = Another difference is that a bearer token isn't generally self-asserted, = and it's assumed the registration server will have some means of = validating this token, like it would with any OAuth token. It's more = like you can use the Initial Registration Token to fulfill the same role = that you're suggesting software_id be used for, which, to me, is more of = an argument against the more-limited software_id than it is against the = existing technology. >>>>>>>=20 >>>>>>> [PH] At minimum, as a UUID it is self asserted and only = identifies a common unique value shared between instances of a = particular piece of software. >>>>>>>=20 >>>>>>> But there is nothing saying it can't be a JWT signed assertion = serving the function of passing on signed client metadata. >>>>>>>=20 >>>>>>> The *big* difference is that the processing of the token occurs = within the registration endpoint. The ONLY endpoint that should accept = this. >>>>>>>=20 >>>>>>> When you stick it in the HTTP Auth header it will likely get = processed by the platform security system which then has to have special = handling code to intercept this custom, undefined, unprofiled token. >>>>>>>=20 >>>>>>> Of course, you could just bypass platform security on = everything=E2=80=A6. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> While I think it is ok for existing implementations to = continue with this practice, I would prefer to standardize passing of = client software assertion metadata outside of the authentication channel = in HTTP. >>>>>>>>>=20 >>>>>>>>> The token in question is fundamentally an authorization = mechanism for calling the registration endpoint. I agree there's value = in passing client software assertions around, and that we should solve = that in an interoperable way, but that's a completely separate question = from registration. >>>>>>>=20 >>>>>>> [PH] What you are passing in Blue Button is a software = assertion. It's not an authorization or an authentication. = Authorization would have to be issued locally. Authentication, could be = federated, but there are no authn statements are there. So it is a = bearer software assertion. The only reason it is better than UUID is = that we can evaluate trust of a third party with regards to the = statements contained. =20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> A further benefit is that the registration endpoint = authentication system only has to deal with locally issued credentials. = The logic for handling federated client meta data can be isolated to the = registration server logic. >>>>>>>>>=20 >>>>>>>>> You can still do that if your registration server is the one = generating the initial access token. Normally, the registration = endpoint's going to be tightly tied to the authorization server, and = whatever process is used to get the initial registration token is going = to also be tightly tied to the registration server.=20 >>>>>>>=20 >>>>>>> [PH] I think the whole point of having an "initial = authentication assertion" is that it is federated -- generated by third = party. Why would I bother if it is local? =20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> My feeling is that if we keep "initial authorization = credential" as being passed in the HTTP Authorization header, then = strict rules about the contents of the token and the processing rules = must be defined so that HTTP server security systems can be extended to = support this. >>>>>>>>>=20 >>>>>>>>> It's an OAuth token. >>>>>>>=20 >>>>>>> [PH[ NO IT IS NOT. The token is issued by a third party = provider. Besides when someone says "OAuth Token" I take that to mean = an ACCESS token. If it is anything else it is = just a JWT or SAML token. >>>>>>>=20 >>>>>>>>> You use whatever HTTP security systems that you already have = to process OAuth tokens on it. If you also want to use it to tell you = something about client metadata, you're going to have to define further = processing, yes, because "an OAuth token" doesn't tell you anything = about what's inside of it or what the token means -- on purpose. But = you'd have to do the same thing with software_id. But nothing is saying = that you need to do that, or that it has to be an assertion at all. = Maybe you just want to lock down your API to know developers, so you = issue them hex blobs to call the API with. Those could expire 5 minutes = from when you issued them, if you wanted. Or they could be SAML blobs, = or JWTs, or anything else that can pass for an OAuth token. There's no = reason any of this should be disallowed by the registration spec, = because the registration spec doesn't care. All it cares about is that = it's an OAuth token and it's (somehow) validated by the registration = endpoint in such a way that the HTTP call to the Registration Endpoint = is valid. This is absolutely bog-standard OAuth Protected Resource here. = By defining it as an OAuth token (and no further), we immediately gain = all of the flexibility and power of OAuth tokens.=20 >>>>>>>=20 >>>>>>> [PH} Sure what you suggest can and will work. But it is 10x more = complex architecturally. =20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> If we use software_id, and indicate that it can accept a = "software registration assertion", we can be more flexible and minimize = the processing rules we have to declare in the draft. That said, if = there is a case to adopt strict rules here too, I am open. >>>>>>>>>=20 >>>>>>>>> I still think that software_id is really only useful and = interoperable in the presence of strict rules, which is why I'm not = convinced it belongs in the draft as is and instead belongs in an = extension that defines such rules. This draft would be way beyond the = two paragraphs that you had spoken of previously, and it would be both = useful and interoperable. But it's enough complexity and enough of a = very specific corner case that I am not at all comfortable putting that = level of processing into the dynamic registration draft. I am willing to = put software_id into dynamic registration as a hook to some = future-to-be-defined specification that tells you how to validate it and = parse it and use it for validating client metadata and tie it to a = developer and all that fun stuff -- I don't personally see the utility = in that, but I don't think it'd really break anything if it went in and = you thought you could use it to bootstrap your process. >>>>>>>=20 >>>>>>> [PH] =20 >>>>>>> 1. What rules do you need around a UUID? It is JUST a unique = identifier. >>>>>>> 2. If an assertion, how is it *any* different from intial client = assertion other than the component of the server that must process it? >>>>>>>=20 >>>>>>> As I said, if you make it part of authentication, then = complexity increases and therefore we would have to tightly profile the = assertion so that token authentication system will accept these = federated tokens. >>>>>>>=20 >>>>>>> If you leave it as part of software_id, then we can be more = informal (to a point). >>>>>>>=20 >>>>>>> I can't help this, it is just the way servers are made. The = horse has left the barn as John says. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 --Apple-Mail=_EF702C1D-023C-4934-BF15-CC01195DE4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes = it can be passed as appropriate.   That is also one reason why we = separated the jricher@mitre.org> = wrote:

=20 =20
Then pass the auth token as a parameter. RFC6750 already says you can do that.

 -- Justin

On 05/28/2013 01:00 PM, Phil Hunt wrote:
Http auth is not the place to be passing non-standard assertions where tighter interop is needed. 

Using a parameter is better suited for this. 

Phil

On 2013-05-28, at 7:53, Justin Richer <jricher@mitre.org> wrote:

In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil = Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is = that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still = needs to be tightly defined.


On 2013-05-24, at 5:06 PM, John Bradley = wrote:

sakimura@gmail.com> wrote:



=3Dnat via iPhone

May 25, 2013 7:16=E3=80=81Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   = They are OAuth tokens and you can cram an assertion in them if you like.  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth!  
[PH]  Well I was going to bring = that up but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server.  But that = just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." = <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
=
 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific = purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers. =  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this assertion being presented in this = way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's = where I get = worried.

1. =  The assertion being presented is not an Authn assertion. There is no = "authentication session" tied to the = assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 

2. =  The assertion isn't an = authentication, but rather signed client = metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3. =  The bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well.

4.  It = ends up performing the same role as = software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing = technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of = software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept = this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on = everything=E2=80=A6.


While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in = HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion. =  It's not an authorization or an authentication.  Authorization = would have to be issued locally.  Authentication, could be = federated, but there are no authn statements are there.  So it is a bearer = software assertion.  The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained. =  


A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration = server. 

[PH]  I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth = token.

[PH[ NO IT IS NOT.  The token is issued by a third party provider.  Besides when someone says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else it = is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth = tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am = open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your = process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique = identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a point).

I can't help this, it is just the way servers are made.  The horse = has left the barn as John says.

 -- = Justin

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

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


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




_______________________________________________=

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



= --Apple-Mail=_EF702C1D-023C-4934-BF15-CC01195DE4A6-- --Apple-Mail=_95ACD50D-04C9-4E5D-8549-3ED88B45F1E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI4MTkwMTM4WjAjBgkqhkiG9w0BCQQxFgQUmJkBxgzi UEQoo6JmdXXbrBKLXeswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAi2RP7Apz0v1cJy3VtXW1mVP7bKyqK+MogDI+buAy NuF+2nLJcRy7ENGg3u/xp0y2dTPZrdB8i7zxXjzOOAzW5sONbQvWjtGm43vbE6plsje+MfNMY2XI uowzoxtE+nMDcENaSENDylpOK4602rjjchnt/DDi1jcSfUkIs0ZJgifv+rg1Xn6skyk1YToLpUH9 kHxivKDRjG6nazi0ZLz/Y+I4Ve3Tr+h/S14I25qOS1Uej7viwyiNBBSsBujlyYuVS6BKYnTQpoKB l/diA+mkqH6LbKLkBirXOxvLkAsCChWj35va2l1pCpxF1CX42p8giSJHmGu7TvjRQ6kO1xDYHQAA AAAAAA== --Apple-Mail=_95ACD50D-04C9-4E5D-8549-3ED88B45F1E7-- From gffletch@aol.com Tue May 28 12:40:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E1911E80F6 for ; Tue, 28 May 2013 12:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-iRqtEmP4ed for ; Tue, 28 May 2013 12:40:24 -0700 (PDT) Received: from omr-d09.mx.aol.com (omr-d09.mx.aol.com [205.188.108.133]) by ietfa.amsl.com (Postfix) with ESMTP id 561BB11E80F8 for ; Tue, 28 May 2013 12:40:23 -0700 (PDT) Received: from mtaout-da06.r1000.mx.aol.com (mtaout-da06.r1000.mx.aol.com [172.29.51.134]) by omr-d09.mx.aol.com (Outbound Mail Relay) with ESMTP id C607A7005C846; Tue, 28 May 2013 15:40:22 -0400 (EDT) Received: from ping-audit-10-181-176-212-20120320.ops.aol.com (ping-audit-10-181-176-212-20120320.ops.aol.com [10.181.176.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 91395E00008A; Tue, 28 May 2013 15:40:19 -0400 (EDT) Message-ID: <51A50821.7060402@aol.com> Date: Tue, 28 May 2013 15:40:17 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <8F29B5A3-10D8-401C-BAE4-94253180FFA1@mitre.org> <9D54D4D3-A092-48B2-AF15-58D99B525270@oracle.com> <-6944393266323949592@unknownmsgid> <07C6E286-6717-45A4-91CE-80EF8356FA45@ve7jtb.com> <9F387D51-C80C-4CE0-B53E-C5654CE8216F@oracle.com> <51A4C4F8.2090704@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020605090302090004080307" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1369770022; bh=lN3nnJIMlu0RpDRVjtGoHJJ9pYYa4KHcGxTexEyYgrI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=IdaDNND8kHoaGOgIU8E0ntVLhPXsjpqo2ge4l4d9VELTq2cG1nESyQljOJMoV7iXs sA95DERa3rDgSHsr+WwJBAnl5MlaoZLLycytaSFqJlqtTW/COdVDbzPi8GcBa+kykH 2P/fGeKXjScS1RZke2yfeOW5Pq6jLCAYB+l1lyYo= X-AOL-SCOLL-SCORE: 1:2:495483584:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d338651a50821618a X-AOL-IP: 10.181.176.212 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration X-BeenThere: oauth@ietf.org X-Mailman-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, 28 May 2013 19:40:32 -0000 This is a multi-part message in MIME format. --------------020605090302090004080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As Justin and John have said... I think all that the spec is saying is that the registration endpoint can be an OAuth2 protected resource. In that sense, the Authorization header is the correct place for this token as defined by RFC 6750. Any additional semantics of how to use the Authorization token are out-of-scope for the spec. If there are additional capabilities or semantics that are desired, then a profile of the dyn reg spec can be created to cover those semantics. As it stands now, if an authorization token is specified, or the AS requires one, then the AS is responsible for validating the token and either providing or rejecting access to the endpoint. That makes sense to me and fits fine with the use of the Authorization header. Thanks, George On 5/28/13 1:00 PM, Phil Hunt wrote: > Http auth is not the place to be passing non-standard assertions where > tighter interop is needed. > > Using a parameter is better suited for this. > > Phil > > On 2013-05-28, at 7:53, Justin Richer > wrote: > >> In BB+, our OAuth tokens are federated because we're doing federated >> OAuth using signed/structured tokens and introspection endpoints that >> the AS and PR know what to do with. We're fundamentally using the >> initial access token as an authorization for calling the endpoint and >> triggering special privileges, and in order to process that >> authorization we've specified how to parse the token as an assertion >> and do discovery and binding to various components of that assertion. >> But as far as the protocol is concerned, it's an authorization to the >> endpoint. >> >> There is absolutely no reason that I can think of to limit it to just >> this kind of complicated scenario. You can use whatever means you >> want to get the initial registration token into the client software, >> and the registration endpoint can use whatever means you want to >> validate the token. >> >> You're absolutely right that if you use the token to push information >> around, you're going to need to specify a lot more in order to make >> it interoperable. This is precisely the reason that I want to keep >> things opaque at the dyn reg spec level, just like OAuth keeps things >> opaque at its own level. If you also want to do something fancy with >> that token, like carry an assertion, you can do it precisely because >> it is an otherwise opaque OAuth token. >> >> -- Justin >> >> On 05/24/2013 08:20 PM, Phil Hunt wrote: >>> The use cases I have heard of from Justin and Morteza at IIW are >>> based on federated scenarios. These are not just locally asserted >>> tokens. >>> >>> Your assertion that the tokens are local and my assertion they are >>> federated suggests there are things that must be sorted out/understood. >>> >>> I'm merely implying that if you don't want to profile this, then >>> don't use HTTP Auth to pass the information. The reason HTTP Auth >>> pushes the inter-op issues is that many deployment architectures >>> have multi-layers of components processing security in a platform. >>> Thus inter-op has to be well defined. >>> >>> When the logic is concentrated into just OAuth registration >>> components, we can have looser definition IMHO. Though others will >>> argue the assertion still needs to be tightly defined. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-05-24, at 5:06 PM, John Bradley wrote: >>> >>>> Phil, >>>> >>>> The OAuth token used authorize access to the registration endpoint( >>>> if one is required) would be issued by the registration server via >>>> some method eg cut and paste from a developer portal, email or >>>> perhaps via OAuth to a Developer API management application. >>>> That is declared out of scope because the token is optional and >>>> there are lots of ways developers can get them. >>>> >>>> I see it as a OAuth access token with some scopes attached to it >>>> like any other access token. You seem to be thinking it is >>>> something else. I don't understand what third party would be >>>> issuing these tokens. You seem to have a use case in mind but I >>>> don't think I understand it. >>>> >>>> John B. >>>> >>>> On 2013-05-24, at 7:26 PM, Nat Sakimura >>> > wrote: >>>> >>>>> >>>>> >>>>> =nat via iPhone >>>>> >>>>> May 25, 2013 7:16?Phil Hunt >>>> > wrote: >>>>>> >>>>>> >>>>>> On 2013-05-24, at 2:54 PM, John Bradley wrote: >>>>>> >>>>>>> I agree with Justin. >>>>>>> >>>>>>> If you want tight authentication on the AS that issues the >>>>>>> tokens we can use OAuth for that with short lived tokens granted >>>>>>> based on a SAML SSO , PIV card or whatever floats your boat for >>>>>>> authentication. >>>>>> >>>>>> [PH] I don't want tight authn. This is *registration*. Yet we are >>>>>> pretending we are authenticating when we aren't. >>>>> >>>>> It is not authentication. >>>>> It is an access authorization to this API. >>>>> >>>>>> >>>>>>> How the tokens are issued to the OAuth client doing the >>>>>>> registration (not the OAuth client being registered) is up to >>>>>>> the AS running the registration endpoint. They are OAuth >>>>>>> tokens and you can cram an assertion in them if you like. >>>>>> >>>>>> [PH] This is nothing to do with my point here. >>>>>>> >>>>>>> Dynamic registration for OAuth should be built with OAuth! >>>>>> [PH] Well I was going to bring that up but didn't want to freak >>>>>> people out. The idea you refer to was why not use oauth to issue >>>>>> an access token to registration server. But that just makes >>>>>> people's head explode. >>>>>> >>>>>>> >>>>>>> John B. >>>>>>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." >>>>>>> > wrote: >>>>>>> >>>>>>>> I completely disagree with this assessment. The latest draft >>>>>>>> (which was just posted) has new language describing what this >>>>>>>> token is and what it's for, and I hope that will clear things >>>>>>>> up. But even so, let me try to address your concerns in-line. >>>>>>>> >>>>>>>> On May 24, 2013, at 4:02 PM, Phil Hunt >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I have been struggling with the concept of an initial client >>>>>>>>> credential covered in the current draft (rev 10): >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> The Client Registration Endpoint is an OAuth Protected >>>>>>>> Resource. This token is a means for authorizing calls to the >>>>>>>> endpoint. Can you use it for other things? Sure, just like you >>>>>>>> can use OAuth tokens for other things (passing data about >>>>>>>> authentication, for instance). But fundamentally, it's just >>>>>>>> another token that's scoped to one endpoint for a specific purpose. >>>>>>>> >>>>>>>>> The use case is very important since it opens the door for a >>>>>>>>> way for trusted entities to sign assertions that could be >>>>>>>>> accepted by a set of deployed authorization servers. For >>>>>>>>> potential software API developers (e.g. Oracle CRM), the >>>>>>>>> developer could potentially register with Oracle CRMs >>>>>>>>> registration service manually, and obtain a signed assertion >>>>>>>>> for use in their client software. Upon initiating dynamic >>>>>>>>> registration, the client software would present the assertion >>>>>>>>> as its initial authorization in the HTTP Authorization header >>>>>>>>> as Justin describes above. >>>>>>>>> >>>>>>>>> While this has worked in practice so far, I am concerned about >>>>>>>>> this assertion being presented in this way. >>>>>>>>> >>>>>>>>> The authentication header has special meaning to many servers. >>>>>>>>> Depending on implementation architecture, the authorization >>>>>>>>> header will first be intercepted by the authentication >>>>>>>>> components in the server. Here's where I get worried. >>>>>>>>> >>>>>>>>> 1. The assertion being presented is not an Authn assertion. >>>>>>>>> There is no "authentication session" tied to the assertion >>>>>>>> >>>>>>>> That's fine. Not all OAuth tokens are authentication assertions >>>>>>>> today, and this is just another OAuth token. >>>>>>>> >>>>>>>>> 2. The assertion isn't an authentication, but rather signed >>>>>>>>> client metadata. >>>>>>>> >>>>>>>> If you want to interpret the token as both authorization to >>>>>>>> call the registration endpoint as well as client metadata, you >>>>>>>> can do that. But you're going to have to define how that >>>>>>>> metadata is passed, how it's signed, how it's interpreted, etc. >>>>>>>> Which, you'll note, is exactly what you can do with an OAuth >>>>>>>> token already. You can use an OAuth token as an opaque blob, or >>>>>>>> you can define structure, signatures, etc., to pack information >>>>>>>> inside of it. If the two always had to be together, then OAuth >>>>>>>> would be defined with JWTs only and we'd have something that >>>>>>>> was much less useful. >>>>>>>> >>>>>>>>> 3. The bearer assertion is easily copied. Thus the server >>>>>>>>> should only trust this as metadata >>>>>>>> >>>>>>>> Depends on the kind of client, and with BB+ we've defined a >>>>>>>> matrix of client types with different policy rules (since we >>>>>>>> can control policy in BB+ land). Our discovery and registry >>>>>>>> setup lets us enforce these rules appropriately as well. >>>>>>>> >>>>>>>>> 4. It ends up performing the same role as software_id >>>>>>>> >>>>>>>> Not really. How does software_id (on its own) represent a that >>>>>>>> the holder is authorized to make this call? You'd have to put >>>>>>>> rules around software_id saying that it needs to be processed >>>>>>>> in a particular way, and I think such rules are far too >>>>>>>> restrictive for this draft. Another difference is that a bearer >>>>>>>> token isn't generally self-asserted, and it's assumed the >>>>>>>> registration server will have some means of validating this >>>>>>>> token, like it would with any OAuth token. It's more like you >>>>>>>> can use the Initial Registration Token to fulfill the same role >>>>>>>> that you're suggesting software_id be used for, which, to me, >>>>>>>> is more of an argument against the more-limited software_id >>>>>>>> than it is against the existing technology. >>>>>> >>>>>> [PH] At minimum, as a UUID it is self asserted and only >>>>>> identifies a common unique value shared between instances of a >>>>>> particular piece of software. >>>>>> >>>>>> But there is nothing saying it can't be a JWT signed assertion >>>>>> serving the function of passing on signed client metadata. >>>>>> >>>>>> The *big* difference is that the processing of the token occurs >>>>>> within the registration endpoint. The ONLY endpoint that should >>>>>> accept this. >>>>>> >>>>>> When you stick it in the HTTP Auth header it will likely get >>>>>> processed by the platform security system which then has to have >>>>>> special handling code to intercept this custom, undefined, >>>>>> unprofiled token. >>>>>> >>>>>> Of course, you could just bypass platform security on everything.... >>>>>>>> >>>>>>>>> >>>>>>>>> _While I think it is ok for existing implementations to >>>>>>>>> continue with this practice_, I would prefer to standardize >>>>>>>>> passing of client software assertion metadata outside of the >>>>>>>>> authentication channel in HTTP. >>>>>>>> >>>>>>>> The token in question is fundamentally an authorization >>>>>>>> mechanism for calling the registration endpoint. I agree >>>>>>>> there's value in passing client software assertions around, and >>>>>>>> that we should solve that in an interoperable way, but that's a >>>>>>>> completely separate question from registration. >>>>>> >>>>>> [PH] What you are passing in Blue Button is a software assertion. >>>>>> It's not an authorization or an authentication. Authorization >>>>>> would have to be issued locally. Authentication, could be >>>>>> federated, but there are no authn statements are there. So it is >>>>>> a bearer software assertion. The only reason it is better than >>>>>> UUID is that we can evaluate trust of a third party with regards >>>>>> to the statements contained. >>>>>>>> >>>>>>>>> >>>>>>>>> A further benefit is that the registration endpoint >>>>>>>>> authentication system only has to deal with locally issued >>>>>>>>> credentials. The logic for handling federated client meta data >>>>>>>>> can be isolated to the registration server logic. >>>>>>>> >>>>>>>> You can still do that if your registration server is the one >>>>>>>> generating the initial access token. Normally, the registration >>>>>>>> endpoint's going to be tightly tied to the authorization >>>>>>>> server, and whatever process is used to get the initial >>>>>>>> registration token is going to also be tightly tied to the >>>>>>>> registration server. >>>>>> >>>>>> [PH] I think the whole point of having an "initial >>>>>> authentication assertion" is that it is federated -- generated by >>>>>> third party. Why would I bother if it is local? >>>>>>>> >>>>>>>>> >>>>>>>>> My feeling is that if we keep "initial authorization >>>>>>>>> credential" as being passed in the HTTP Authorization header, >>>>>>>>> then strict rules about the contents of the token and the >>>>>>>>> processing rules must be defined so that HTTP server security >>>>>>>>> systems can be extended to support this. >>>>>>>> >>>>>>>> It's an OAuth token. >>>>>> >>>>>> [PH[ NO IT IS NOT. The token is issued by a third party >>>>>> provider. Besides when someone says "OAuth Token" I take that to >>>>>> mean an ACCESS token. If it is anything else it is just a JWT or >>>>>> SAML token. >>>>>> >>>>>>>> You use whatever HTTP security systems that you already have to >>>>>>>> process OAuth tokens on it. If you also want to use it to tell >>>>>>>> you something about client metadata, you're going to have to >>>>>>>> define further processing, yes, because "an OAuth token" >>>>>>>> doesn't tell you anything about what's inside of it or what the >>>>>>>> token means -- on purpose. But you'd have to do the same thing >>>>>>>> with software_id. But nothing is saying that you need to do >>>>>>>> that, or that it has to be an assertion at all. Maybe you just >>>>>>>> want to lock down your API to know developers, so you issue >>>>>>>> them hex blobs to call the API with. Those could expire 5 >>>>>>>> minutes from when you issued them, if you wanted. Or they could >>>>>>>> be SAML blobs, or JWTs, or anything else that can pass for an >>>>>>>> OAuth token. There's no reason any of this should be disallowed >>>>>>>> by the registration spec, because the registration spec doesn't >>>>>>>> care. All it cares about is that it's an OAuth token and it's >>>>>>>> (somehow) validated by the registration endpoint in such a way >>>>>>>> that the HTTP call to the Registration Endpoint is valid. This >>>>>>>> is absolutely bog-standard OAuth Protected Resource here. By >>>>>>>> defining it as an OAuth token (and no further), we immediately >>>>>>>> gain all of the flexibility and power of OAuth tokens. >>>>>> >>>>>> [PH} Sure what you suggest can and will work. But it is 10x more >>>>>> complex architecturally. >>>>>>>> >>>>>>>>> >>>>>>>>> If we use software_id, and indicate that it can accept a >>>>>>>>> "software registration assertion", we can be more flexible and >>>>>>>>> minimize the processing rules we have to declare in the draft. >>>>>>>>> That said, if there is a case to adopt strict rules here too, >>>>>>>>> I am open. >>>>>>>> >>>>>>>> I still think that software_id is really only useful and >>>>>>>> interoperable in the presence of strict rules, which is why I'm >>>>>>>> not convinced it belongs in the draft as is and instead belongs >>>>>>>> in an extension that defines such rules. This draft would be >>>>>>>> way beyond the two paragraphs that you had spoken of >>>>>>>> previously, and it would be both useful and interoperable. But >>>>>>>> it's enough complexity and enough of a very specific corner >>>>>>>> case that I am not at all comfortable putting that level of >>>>>>>> processing into the dynamic registration draft. I am willing to >>>>>>>> put software_id into dynamic registration as a hook to some >>>>>>>> future-to-be-defined specification that tells you how to >>>>>>>> validate it and parse it and use it for validating client >>>>>>>> metadata and tie it to a developer and all that fun stuff -- I >>>>>>>> don't personally see the utility in that, but I don't think >>>>>>>> it'd really break anything if it went in and you thought you >>>>>>>> could use it to bootstrap your process. >>>>>> >>>>>> [PH] >>>>>> 1. What rules do you need around a UUID? It is JUST a unique >>>>>> identifier. >>>>>> 2. If an assertion, how is it *any* different from intial client >>>>>> assertion other than the component of the server that must >>>>>> process it? >>>>>> >>>>>> As I said, if you make it part of authentication, then complexity >>>>>> increases and therefore we would have to tightly profile the >>>>>> assertion so that token authentication system will accept these >>>>>> federated tokens. >>>>>> >>>>>> If you leave it as part of software_id, then we can be more >>>>>> informal (to a point). >>>>>> >>>>>> I can't help this, it is just the way servers are made. The >>>>>> horse has left the barn as John says. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing 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 --------------020605090302090004080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As Justin and John have said... I think all that the spec is saying is that the registration endpoint can be an OAuth2 protected resource. In that sense, the Authorization header is the correct place for this token as defined by RFC 6750. Any additional semantics of how to use the Authorization token are out-of-scope for the spec. If there are additional capabilities or semantics that are desired, then a profile of the dyn reg spec can be created to cover those semantics.

As it stands now, if an authorization token is specified, or the AS requires one, then the AS is responsible for validating the token and either providing or rejecting access to the endpoint. That makes sense to me and fits fine with the use of the Authorization header.

Thanks,
George

On 5/28/13 1:00 PM, Phil Hunt wrote:
Http auth is not the place to be passing non-standard assertions where tighter interop is needed. 

Using a parameter is better suited for this. 

Phil

On 2013-05-28, at 7:53, Justin Richer <jricher@mitre.org> wrote:

In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client software, and the registration endpoint can use whatever means you want to validate the token.

You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token.

 -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still needs to be tightly defined.


On 2013-05-24, at 5:06 PM, John Bradley wrote:

Phil,

The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application.     That is declared out of scope because the token is optional and there are lots of ways developers can get them.

I see it as a OAuth access token with some scopes attached to it like any other access token.   You seem to be thinking it is something else.   I don't understand what third party would be issuing these tokens.  You seem to have a use case in mind but I don't think I understand it.

John B.

On 2013-05-24, at 7:26 PM, Nat Sakimura <sakimura@gmail.com> wrote:



=nat via iPhone

May 25, 2013 7:16、Phil Hunt <phil.hunt@oracle.com>  wrote: 


On 2013-05-24, at 2:54 PM, John Bradley wrote:

I agree with Justin.

If you want tight authentication on the AS that issues the tokens we can use OAuth for that with short lived tokens granted based on a SAML SSO , PIV card or whatever floats your boat for authentication.

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

It is not authentication. 
It is an access authorization to this API. 


How the tokens are issued to the OAuth client doing the registration (not the OAuth client being registered) is up to the AS running the registration endpoint.   They are OAuth tokens and you can cram an assertion in them if you like.  

[PH] This is nothing to do with my point here.

Dynamic registration for OAuth should be built with OAuth!  
[PH]  Well I was going to bring that up but didn't want to freak people out. The idea you refer to was why not use oauth to issue an access token to registration server.  But that just makes people's head explode.


John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.

On May 24, 2013, at 4:02 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): 
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.


The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose.

The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers.  For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software.  Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above.

While this has worked in practice so far, I am concerned about this assertion being presented in this way.

The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server.  Here's where I get worried.

1.  The assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 

2.  The assertion isn't an authentication, but rather signed client metadata.

If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful.

3.  The bearer assertion is easily copied. Thus the server should only trust this as metadata

Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well.

4.  It ends up performing the same role as software_id

Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology.

[PH] At minimum, as a UUID it is self asserted and only identifies a common unique value shared between instances of a particular piece of software.

But there is nothing saying it can't be a JWT signed assertion serving the function of passing on signed client metadata.

The *big* difference is that the processing of the token occurs within the registration endpoint. The ONLY endpoint that should accept this.

When you stick it in the HTTP Auth header it will likely get processed by the platform security system which then has to have special handling code to intercept this custom, undefined, unprofiled token.

Of course, you could just bypass platform security on everything….


While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP.

The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration.

[PH] What you are passing in Blue Button is a software assertion.  It's not an authorization or an authentication.  Authorization would have to be issued locally.  Authentication, could be federated, but there are no authn statements are there.  So it is a bearer software assertion.  The only reason it is better than UUID is that we can evaluate trust of a third party with regards to the statements contained.  


A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic.

You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. 

[PH]  I think the whole point of having an "initial authentication assertion" is that it is federated -- generated by third party. Why would I bother if it is local?  


My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this.

It's an OAuth token.

[PH[ NO IT IS NOT.  The token is issued by a third party provider.  Besides when someone says "OAuth Token" I take that to mean an ACCESS token.  If it is anything else it is just a JWT or SAML token.

You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. 

[PH} Sure what you suggest can and will work. But it is 10x more complex architecturally.  


If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open.

I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process.

[PH]  
1. What rules do you need around a UUID?  It is JUST a unique identifier.
2. If an assertion, how is it *any* different from intial client assertion other than the component of the server that must process it?

As I said, if you make it part of authentication, then complexity increases and therefore we would have to tightly profile the assertion so that token authentication system will accept these federated tokens.

If you leave it as part of software_id, then we can be more informal (to a point).

I can't help this, it is just the way servers are made.  The horse has left the barn as John says.

 -- Justin

_______________________________________________
OAuth mailing 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

--------------020605090302090004080307-- From vincetsang@gmail.com Tue May 28 20:03:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4467611E80D7 for ; Tue, 28 May 2013 20:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvV5RDckYc3b for ; Tue, 28 May 2013 20:03:55 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 39D6511E80DF for ; Tue, 28 May 2013 20:03:55 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so3692113wgh.3 for ; Tue, 28 May 2013 20:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NHKs5zRLUQ4UVwc3or5elvVp4hGCeMBVlYfuOKftJH8=; b=ryChdX4dhCs1J+16GwTlavKtFhv6CkIpo+2YxKLBxS89rXQFSt3yZtLqnVfnUUnPMe kav9m9XsDW4+JR3kuKYxiz2hLa4xs21qJKaoylzwZIJcbQDU1G1rzvU5mqh+qTN+/HM2 jdrgJHULr6k1pFI3RciqnkuaBb2lnnV5CuTW2b1qdy1Nlwnq9z3TMcymOmtMlkwpZUz7 u3fSrJHO/+IBC3d5rfNkX14kha4OE5C12Gg6D8VkMc18DS9tJPdQD0VYkcrjIF7lngEa /F4WtLAu6o9qWVRvnuIOfw7kkPHbgPP9lRi3CIWzAQ5lrv54wfIT9M+LObi5BeWwpBdZ TVuQ== MIME-Version: 1.0 X-Received: by 10.194.175.132 with SMTP id ca4mr532280wjc.11.1369796634329; Tue, 28 May 2013 20:03:54 -0700 (PDT) Received: by 10.216.80.198 with HTTP; Tue, 28 May 2013 20:03:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 May 2013 11:03:54 +0800 Message-ID: From: Vincent Tsang To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e013d1d8ecdc57e04ddd2a16c Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 03:03:56 -0000 --089e013d1d8ecdc57e04ddd2a16c Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, Thanks for your reply. Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed. Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application. I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully. Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications? Thanks. Vincent --089e013d1d8ecdc57e04ddd2a16c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

Thanks for your reply.=
Actually I am new to OAuth and am simply trying to search = for the best industrial practice for granting access tokens when the client= to our application API is a simple windows applications, which in most cas= es runs on PC's with web browser installed.=A0
Therefore the scenario doesn't quite match what is described= in the document, as the user doesn't need a separate machine to perfor= m the verification; it's just that the client application doesn't h= ave internet browsing capability itself (in this sense it's similar to = the "device" described in this document, though not quite) and so= user needs to launch a separate browser application.=A0
I ended up on this device profile spec just because it seems to = match closer to our scenario when compared to the 4 cases described in the = OAuth 2 spec, but it could be the case that I didn't understand it full= y.=A0
Maybe I should rephrase my question: could someone please advice= what should be the best practice for granting OAuth tokens to clients whic= h are native windows applications?

Thanks.
Vincent

--089e013d1d8ecdc57e04ddd2a16c-- From sakimura@gmail.com Tue May 28 20:38:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652D721F8C40 for ; Tue, 28 May 2013 20:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd1y0e5ol+7G for ; Tue, 28 May 2013 20:38:34 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 910E821F894E for ; Tue, 28 May 2013 20:38:33 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so8536379lbf.28 for ; Tue, 28 May 2013 20:38:32 -0700 (PDT) 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=glWOhqFPz49CiARYgDOXipcy2aJ762m4C+8aF2ZoVj4=; b=L3tPTZuCcBi1jq/B+OkE2kNgQ3VA5YWO6LDUbEenuCTIR8D++tUDGpXw0Qz/GoCO57 mbpwCGkElwp/kfUhTh8Zc0SXKge1LLhQH/1eZvPOM4zsPbUxPJYi3+nYDGhjOe7forJG TLMH9h7/YVa9oWmN5jOV2yiGwN3r5YTCfiZKkFRYEiB+UTDkogT/Rucp7+JXHgTbXll/ D7541SZnUhNcYjmQ8clZ5N+wq08Lv2cq44hn8JVVMtbTyCGAGJhhx7ntAS6yB9pQY/ko c98b6zm1YgNhmYAw13L5a4Wr6SUpsF0sLvTE3LS/g1ijdls1MqJY1vIB7KG/rT+vTac7 aLvw== X-Received: by 10.112.35.69 with SMTP id f5mr577084lbj.105.1369798712100; Tue, 28 May 2013 20:38:32 -0700 (PDT) References: From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 29 May 2013 12:38:28 +0900 Message-ID: <-8470720313341818373@unknownmsgid> To: Vincent Tsang Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: base64 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 03:38:38 -0000 QSBsaXR0bGUgbW9yZSBhcHBsaWNhdGlvbiBhbmQgdXNlciBjb250ZXh0IHdvdWxkIGhlbHAuDQpB IHVzZSBjYXNlLCBzbyB0byBzcGVhay4NCg0KTmF0DQoNCjIwMTMvMDUvMjkgMTI6MDQbJEIhIhso QlZpbmNlbnQgVHNhbmcgPHZpbmNldHNhbmdAZ21haWwuY29tPiAbJEIkTiVhJUMlOyE8JTgbKEI6 DQoNCj4gSGkgSGFubmVzLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQo+IEFjdHVhbGx5 IEkgYW0gbmV3IHRvIE9BdXRoIGFuZCBhbSBzaW1wbHkgdHJ5aW5nIHRvIHNlYXJjaCBmb3IgdGhl IGJlc3QgaW5kdXN0cmlhbCBwcmFjdGljZSBmb3IgZ3JhbnRpbmcgYWNjZXNzIHRva2VucyB3aGVu IHRoZSBjbGllbnQgdG8gb3VyIGFwcGxpY2F0aW9uIEFQSSBpcyBhIHNpbXBsZSB3aW5kb3dzIGFw cGxpY2F0aW9ucywgd2hpY2ggaW4gbW9zdCBjYXNlcyBydW5zIG9uIFBDJ3Mgd2l0aCB3ZWIgYnJv d3NlciBpbnN0YWxsZWQuDQo+IFRoZXJlZm9yZSB0aGUgc2NlbmFyaW8gZG9lc24ndCBxdWl0ZSBt YXRjaCB3aGF0IGlzIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQsIGFzIHRoZSB1c2VyIGRvZXNu J3QgbmVlZCBhIHNlcGFyYXRlIG1hY2hpbmUgdG8gcGVyZm9ybSB0aGUgdmVyaWZpY2F0aW9uOyBp dCdzIGp1c3QgdGhhdCB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIGRvZXNuJ3QgaGF2ZSBpbnRlcm5l dCBicm93c2luZyBjYXBhYmlsaXR5IGl0c2VsZiAoaW4gdGhpcyBzZW5zZSBpdCdzIHNpbWlsYXIg dG8gdGhlICJkZXZpY2UiIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCB0aG91Z2ggbm90IHF1 aXRlKSBhbmQgc28gdXNlciBuZWVkcyB0byBsYXVuY2ggYSBzZXBhcmF0ZSBicm93c2VyIGFwcGxp Y2F0aW9uLg0KPiBJIGVuZGVkIHVwIG9uIHRoaXMgZGV2aWNlIHByb2ZpbGUgc3BlYyBqdXN0IGJl Y2F1c2UgaXQgc2VlbXMgdG8gbWF0Y2ggY2xvc2VyIHRvIG91ciBzY2VuYXJpbyB3aGVuIGNvbXBh cmVkIHRvIHRoZSA0IGNhc2VzIGRlc2NyaWJlZCBpbiB0aGUgT0F1dGggMiBzcGVjLCBidXQgaXQg Y291bGQgYmUgdGhlIGNhc2UgdGhhdCBJIGRpZG4ndCB1bmRlcnN0YW5kIGl0IGZ1bGx5Lg0KPiBN YXliZSBJIHNob3VsZCByZXBocmFzZSBteSBxdWVzdGlvbjogY291bGQgc29tZW9uZSBwbGVhc2Ug YWR2aWNlIHdoYXQgc2hvdWxkIGJlIHRoZSBiZXN0IHByYWN0aWNlIGZvciBncmFudGluZyBPQXV0 aCB0b2tlbnMgdG8gY2xpZW50cyB3aGljaCBhcmUgbmF0aXZlIHdpbmRvd3MgYXBwbGljYXRpb25z Pw0KPg0KPiBUaGFua3MuDQo+IFZpbmNlbnQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From vincetsang@gmail.com Tue May 28 21:31:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5890721E804B for ; Tue, 28 May 2013 21:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvKVYdNOqST8 for ; Tue, 28 May 2013 21:31:31 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2885811E80D1 for ; Tue, 28 May 2013 21:31:31 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hj6so3123288wib.17 for ; Tue, 28 May 2013 21:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fT9OsfrFLTS9no3oYL1dIxxvZ8buTmVT4yuhncrftao=; b=XZ5MT08jZ3gclKcppTfBWVrkZH02Xb7RbOMnaWmJVm5q4uTbhQOgSZELsXdqWMBJJh 2jRY0TWeRoP/dkizw5peZBIAmsskN8yiebqwqGFbhQgyfP4NnkCtZF4GNMqHjrsz94xV Jiu01SbbWVDCy3SualorptvkQ4dfQet13K1pJ86ddEYC+SmibtqaOPE3LNwv8oKlISoU TsemsTMuoB1ejh/H4jxzfIUR72tGn3mYxg/SovGTCqsCwyz2ocrdy7H6PqkxS26IBQUA GB4emgc+rHoPuCgybrw/iD+SiNcrGitNe11pXfq3tbwI0bYAAVyONiimVSi2Q7PH/omy hjsQ== MIME-Version: 1.0 X-Received: by 10.194.175.132 with SMTP id ca4mr717178wjc.11.1369801890212; Tue, 28 May 2013 21:31:30 -0700 (PDT) Received: by 10.216.80.198 with HTTP; Tue, 28 May 2013 21:31:30 -0700 (PDT) In-Reply-To: <-8470720313341818373@unknownmsgid> References: <-8470720313341818373@unknownmsgid> Date: Wed, 29 May 2013 12:31:30 +0800 Message-ID: From: Vincent Tsang To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e013d1d8e14320904ddd3dbb9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 04:31:32 -0000 --089e013d1d8e14320904ddd3dbb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura wrote: > A little more application and user context would help. > A use case, so to speak. > > Nat > > 2013/05/29 12:04=E3=80=81Vincent Tsang =E3=81=AE= =E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > > Hi Hannes, > > > > Thanks for your reply. > > Actually I am new to OAuth and am simply trying to search for the best > industrial practice for granting access tokens when the client to our > application API is a simple windows applications, which in most cases run= s > on PC's with web browser installed. > > Therefore the scenario doesn't quite match what is described in the > document, as the user doesn't need a separate machine to perform the > verification; it's just that the client application doesn't have internet > browsing capability itself (in this sense it's similar to the "device" > described in this document, though not quite) and so user needs to launch= a > separate browser application. > > I ended up on this device profile spec just because it seems to match > closer to our scenario when compared to the 4 cases described in the OAut= h > 2 spec, but it could be the case that I didn't understand it fully. > > Maybe I should rephrase my question: could someone please advice what > should be the best practice for granting OAuth tokens to clients which ar= e > native windows applications? > > > > Thanks. > > Vincent > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --089e013d1d8e14320904ddd3dbb9 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhlIGNsaWVudCBpcyBhIG5hdGl2ZSB3aW5kb3dzIGFwcGxpY2F0aW9u LCBmb3IgaW5zdGFuY2UsIGEgZG9jdW1lbnQgZWRpdG9yIGxpa2UgTVMgV29yZC4mbmJzcDs8ZGl2 PlRoZSBlZGl0b3IgY2FuIHVwbG9hZCBjb3BpZXMgdG8gdGhlIGNsb3VkIChlLmcuIEFtYXpvbiBT MyksIHRoZW4gcmVjb3JkIHRoZSB2ZXJzaW9uIGhpc3RvcnkgYW5kIG5vdGVzIGFzc29jaWF0ZWQg d2l0aCBlYWNoIGNsb3VkIGNvcHkgdG8gb3VyIGNsb3VkIHNlcnZpY2UgdmlhIG91ciBjbG91ZCBh cHBsaWNhdGlvbiBBUEkgKHRvIGJlIHNlY3VyZWQgYnkgT0F1dGggYWNjZXNzIHRva2VucykuPC9k aXY+DQo8ZGl2PkkgdGhpbmsgaXQmIzM5O3Mgc2ltaWxhciB0byB0aGUgY2FzZSB3aXRoIGEgbWVk aWEgcGxheWVyIGFwcGxpY2F0aW9uIChsaWtlIFZMQy9XaW5kb3dzIE1lZGlhIFBsYXllcikgdGhh dCBzZW5kcyBwbGF5bGlzdC9oaXN0b3J5IGluZm8gdG8gdGhlIGNsb3VkIHZpYSBzb21lIGNsb3Vk IGFwcGxpY2F0aW9uIEFQSS4mbmJzcDs8L2Rpdj48ZGl2PkkmIzM5O20ganVzdCBub3Qgc3VyZSB3 aGljaCBvZiB0aGUgNCBzY2VuYXJpb3MgZGVzY3JpYmVkIGluIHRoZSBPQXV0aCBzcGVjIGNvdWxk IGZpdCBpbiBoZXJlLi4uJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT48YnI+PC9kaXY+PGRpdiBzdHls ZT5UaGFua3MuPC9kaXY+PGRpdiBzdHlsZT5WaW5jZW50PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBj bGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdl ZCwgTWF5IDI5LCAyMDEzIGF0IDExOjM4IEFNLCBOYXQgU2FraW11cmEgPHNwYW4gZGlyPSJsdHIi PiZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPkEgbGl0dGxlIG1vcmUgYXBwbGljYXRp b24gYW5kIHVzZXIgY29udGV4dCB3b3VsZCBoZWxwLjxicj4NCkEgdXNlIGNhc2UsIHNvIHRvIHNw ZWFrLjxicj4NCjxicj4NCk5hdDxicj4NCjxicj4NCjIwMTMvMDUvMjkgMTI6MDQbJEIhIhsoQlZp bmNlbnQgVHNhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW5jZXRzYW5nQGdtYWlsLmNvbSI+dmlu Y2V0c2FuZ0BnbWFpbC5jb208L2E+Jmd0OyAbJEIkTiVhJUMlOyE8JTgbKEI6PGJyPg0KPGRpdiBj bGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+PGJyPg0KJmd0OyBIaSBIYW5uZXMsPGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIHJlcGx5Ljxicj4NCiZndDsgQWN0dWFsbHkg SSBhbSBuZXcgdG8gT0F1dGggYW5kIGFtIHNpbXBseSB0cnlpbmcgdG8gc2VhcmNoIGZvciB0aGUg YmVzdCBpbmR1c3RyaWFsIHByYWN0aWNlIGZvciBncmFudGluZyBhY2Nlc3MgdG9rZW5zIHdoZW4g dGhlIGNsaWVudCB0byBvdXIgYXBwbGljYXRpb24gQVBJIGlzIGEgc2ltcGxlIHdpbmRvd3MgYXBw bGljYXRpb25zLCB3aGljaCBpbiBtb3N0IGNhc2VzIHJ1bnMgb24gUEMmIzM5O3Mgd2l0aCB3ZWIg YnJvd3NlciBpbnN0YWxsZWQuPGJyPg0KDQomZ3Q7IFRoZXJlZm9yZSB0aGUgc2NlbmFyaW8gZG9l c24mIzM5O3QgcXVpdGUgbWF0Y2ggd2hhdCBpcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LCBh cyB0aGUgdXNlciBkb2VzbiYjMzk7dCBuZWVkIGEgc2VwYXJhdGUgbWFjaGluZSB0byBwZXJmb3Jt IHRoZSB2ZXJpZmljYXRpb247IGl0JiMzOTtzIGp1c3QgdGhhdCB0aGUgY2xpZW50IGFwcGxpY2F0 aW9uIGRvZXNuJiMzOTt0IGhhdmUgaW50ZXJuZXQgYnJvd3NpbmcgY2FwYWJpbGl0eSBpdHNlbGYg KGluIHRoaXMgc2Vuc2UgaXQmIzM5O3Mgc2ltaWxhciB0byB0aGUgJnF1b3Q7ZGV2aWNlJnF1b3Q7 IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCB0aG91Z2ggbm90IHF1aXRlKSBhbmQgc28gdXNl ciBuZWVkcyB0byBsYXVuY2ggYSBzZXBhcmF0ZSBicm93c2VyIGFwcGxpY2F0aW9uLjxicj4NCg0K Jmd0OyBJIGVuZGVkIHVwIG9uIHRoaXMgZGV2aWNlIHByb2ZpbGUgc3BlYyBqdXN0IGJlY2F1c2Ug aXQgc2VlbXMgdG8gbWF0Y2ggY2xvc2VyIHRvIG91ciBzY2VuYXJpbyB3aGVuIGNvbXBhcmVkIHRv IHRoZSA0IGNhc2VzIGRlc2NyaWJlZCBpbiB0aGUgT0F1dGggMiBzcGVjLCBidXQgaXQgY291bGQg YmUgdGhlIGNhc2UgdGhhdCBJIGRpZG4mIzM5O3QgdW5kZXJzdGFuZCBpdCBmdWxseS48YnI+DQoN CiZndDsgTWF5YmUgSSBzaG91bGQgcmVwaHJhc2UgbXkgcXVlc3Rpb246IGNvdWxkIHNvbWVvbmUg cGxlYXNlIGFkdmljZSB3aGF0IHNob3VsZCBiZSB0aGUgYmVzdCBwcmFjdGljZSBmb3IgZ3JhbnRp bmcgT0F1dGggdG9rZW5zIHRvIGNsaWVudHMgd2hpY2ggYXJlIG5hdGl2ZSB3aW5kb3dzIGFwcGxp Y2F0aW9ucz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MuPGJyPg0KJmd0OyBWaW5jZW50PGJy Pg0KJmd0Ozxicj4NCjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9IkhPRW5aYiI+PGRpdiBjbGFzcz0i aDUiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvZGl2 PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --089e013d1d8e14320904ddd3dbb9-- From lainhart@us.ibm.com Wed May 29 06:26:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7674F21F8976 for ; Wed, 29 May 2013 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haD8nn1rPQX8 for ; Wed, 29 May 2013 06:26:50 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93721F8916 for ; Wed, 29 May 2013 06:26:50 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 May 2013 09:26:48 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 29 May 2013 09:26:46 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id CF1EF38C801A; Wed, 29 May 2013 09:26:44 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4TDQjxj338878; Wed, 29 May 2013 09:26:45 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4TDQiX2020402; Wed, 29 May 2013 09:26:44 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r4TDQib0020399; Wed, 29 May 2013 09:26:44 -0400 In-Reply-To: References: <-8470720313341818373@unknownmsgid> To: Vincent Tsang MIME-Version: 1.0 X-KeepSent: 35A0195E:6911A37A-85257B7A:0049A8A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 Message-ID: From: Todd W Lainhart Date: Wed, 29 May 2013 09:26:42 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 05/29/2013 09:26:44, Serialize complete at 05/29/2013 09:26:44 Content-Type: multipart/alternative; boundary="=_alternative 0049D9F285257B7A_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13052913-7182-0000-0000-000006FBB469 Cc: "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 13:26:56 -0000 This is a multipart message in MIME format. --=_alternative 0049D9F285257B7A_= Content-Type: text/plain; charset="ISO-2022-JP" On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Vincent Tsang To: Nat Sakimura , Cc: "oauth@ietf.org" Date: 05/29/2013 12:31 AM Subject: Re: [OAUTH-WG] Device profile usage Sent by: oauth-bounces@ietf.org The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04$B!"(BVincent Tsang $B$N%a%C%;!<%8(B: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed. > Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application. > I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications? > > Thanks. > Vincent > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=_alternative 0049D9F285257B7A_= Content-Type: text/html; charset="ISO-2022-JP" On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Vincent Tsang <vincetsang@gmail.com>
To:        Nat Sakimura <sakimura@gmail.com>,
Cc:        "oauth@ietf.org" <oauth@ietf.org>
Date:        05/29/2013 12:31 AM
Subject:        Re: [OAUTH-WG] Device profile usage
Sent by:        oauth-bounces@ietf.org



The client is a native windows application, for instance, a document editor like MS Word.
The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens).
I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API.
I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here...

Thanks.
Vincent


On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <sakimura@gmail.com> wrote:
A little more application and user context would help.
A use case, so to speak.

Nat

2013/05/29 12:04$B!"(BVincent Tsang <vincetsang@gmail.com> $B$N%a%C%;!<%8(B:

> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed.
> Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application.
> I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully.
> Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications?
>
> Thanks.
> Vincent
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--=_alternative 0049D9F285257B7A_=-- From Adam.Lewis@motorolasolutions.com Wed May 29 06:54:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA17A21F8D2B for ; Wed, 29 May 2013 06:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4mi-gHdp8pK for ; Wed, 29 May 2013 06:54:35 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2EC21F8AD8 for ; Wed, 29 May 2013 06:54:34 -0700 (PDT) Received: from mail199-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 13:54:33 +0000 Received: from mail199-va3 (localhost [127.0.0.1]) by mail199-va3-R.bigfish.com (Postfix) with ESMTP id BA6FE4600D9 for ; Wed, 29 May 2013 13:54:33 +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: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432Ic85ahzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1155h) Received-SPF: pass (mail199-va3: 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:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail199-va3 (localhost.localdomain [127.0.0.1]) by mail199-va3 (MessageSwitch) id 1369835671947179_9365; Wed, 29 May 2013 13:54:31 +0000 (UTC) Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.248]) by mail199-va3.bigfish.com (Postfix) with ESMTP id E324B18021B for ; Wed, 29 May 2013 13:54:31 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 13:54:27 +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 r4TDsRlW005643 for ; Wed, 29 May 2013 08:54:27 -0500 (CDT) Received: from DB8EHSOBE038.bigfish.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r4TDsPNS005639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 May 2013 08:54:26 -0500 (CDT) Received: from mail110-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 13:54:25 +0000 Received: from mail110-db8 (localhost [127.0.0.1]) by mail110-db8-R.bigfish.com (Postfix) with ESMTP id 7AFFD180197 for ; Wed, 29 May 2013 13:54:25 +0000 (UTC) Received: from mail110-db8 (localhost.localdomain [127.0.0.1]) by mail110-db8 (MessageSwitch) id 1369835663122517_20122; Wed, 29 May 2013 13:54:23 +0000 (UTC) Received: from DB8EHSMHS024.bigfish.com (unknown [10.174.8.254]) by mail110-db8.bigfish.com (Postfix) with ESMTP id 11BC4300055; Wed, 29 May 2013 13:54:23 +0000 (UTC) Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by DB8EHSMHS024.bigfish.com (10.174.4.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 13:54:21 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.126]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0311.000; Wed, 29 May 2013 13:54:11 +0000 From: Lewis Adam-CAL022 To: Vincent Tsang , Nat Sakimura Thread-Topic: [OAUTH-WG] Device profile usage Thread-Index: AQHOXBlnTKXfRjB7qEeY0Vk/CLUtV5kbg8MAgAAO0gCAAJxiYA== Date: Wed, 29 May 2013 13:54:10 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9659AE3FF@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <-8470720313341818373@unknownmsgid> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.46.183] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9659AE3FFBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.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] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 13:54:42 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9659AE3FFBY2PRD0411MB441_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Vincent =1B$B!D=1B(B it sounds to me like you should be looking at the c= ode flow. It is optimized for the use case you describe (or at least as I = understand it). A native application which uses an installed web browser t= o interact with the AS and obtain a token for your client. Using this flow= , your native windows app would communicate with the AS via (for example) F= irefox or IE. Your request would register a custom redirect URI, which you= r app would handle. When the AS sends the code back, the web browser will = hand it back to your native app. Your native app would then communicate di= rectly with the AS and exchange the code for an access token which your app= could then use to communicate with its API endpoint. -adam From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of V= incent Tsang Sent: Tuesday, May 28, 2013 11:32 PM To: Nat Sakimura Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Device profile usage The client is a native windows application, for instance, a document editor= like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the= version history and notes associated with each cloud copy to our cloud ser= vice via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/= Windows Media Player) that sends playlist/history info to the cloud via som= e cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec coul= d fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura > wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04=1B$B!"=1B(BVincent Tsang > =1B$B$N%a%C%;!<%8=1B(B: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best in= dustrial practice for granting access tokens when the client to our applica= tion API is a simple windows applications, which in most cases runs on PC's= with web browser installed. > Therefore the scenario doesn't quite match what is described in the docum= ent, as the user doesn't need a separate machine to perform the verificatio= n; it's just that the client application doesn't have internet browsing cap= ability itself (in this sense it's similar to the "device" described in thi= s document, though not quite) and so user needs to launch a separate browse= r application. > I ended up on this device profile spec just because it seems to match clo= ser to our scenario when compared to the 4 cases described in the OAuth 2 s= pec, but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what sho= uld be the best practice for granting OAuth tokens to clients which are nat= ive windows applications? > > Thanks. > Vincent > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9659AE3FFBY2PRD0411MB441_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Vincent =1B$B!D=1B(B i= t sounds to me like you should be looking at the code flow.  It is opt= imized for the use case you describe (or at least as I understand it). = ; A native application which uses an installed web browser to interact with = the AS and obtain a token for your client.  Using this flow, your nati= ve windows app would communicate with the AS via (for example) Firefox or I= E.  Your request would register a custom redirect URI, which your app would handle.  When the AS sends the cod= e back, the web browser will hand it back to your native app.  Your na= tive app would then communicate directly with the AS and exchange the code = for an access token which your app could then use to communicate with its API endpoint.

 <= /p>

-adam

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Vincent Tsang
Sent: Tuesday, May 28, 2013 11:32 PM
To: Nat Sakimura
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Device profile usage

 

The client is a native windows application, for inst= ance, a document editor like MS Word. 

The editor can upload copies to the cloud (e.g. Amaz= on S3), then record the version history and notes associated with each clou= d copy to our cloud service via our cloud application API (to be secured by= OAuth access tokens).

I think it's similar to the case with a media player= application (like VLC/Windows Media Player) that sends playlist/history in= fo to the cloud via some cloud application API. 

I'm just not sure which of the 4 scenarios described= in the OAuth spec could fit in here... 

 

Thanks.

Vincent

 

On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

A little more application and user context would hel= p.
A use case, so to speak.

Nat

2013/05/29 12:04=1B$B!"=1B(BVincent Tsang <vincetsang@gmail.com> =1B$B$N%a%C%;!<%8=1B(B:


> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best= industrial practice for granting access tokens when the client to our appl= ication API is a simple windows applications, which in most cases runs on P= C's with web browser installed.
> Therefore the scenario doesn't quite match what is described in the do= cument, as the user doesn't need a separate machine to perform the verifica= tion; it's just that the client application doesn't have internet browsing = capability itself (in this sense it's similar to the "device" described in this document, though not q= uite) and so user needs to launch a separate browser application.
> I ended up on this device profile spec just because it seems to match = closer to our scenario when compared to the 4 cases described in the OAuth = 2 spec, but it could be the case that I didn't understand it fully.
> Maybe I should rephrase my question: could someone please advice what = should be the best practice for granting OAuth tokens to clients which are = native windows applications?
>
> Thanks.
> Vincent
>

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

 

--_000_59E470B10C4630419ED717AC79FCF9A9659AE3FFBY2PRD0411MB441_-- From jricher@mitre.org Wed May 29 06:56:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893A321F8459 for ; Wed, 29 May 2013 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mH990LxTctu for ; Wed, 29 May 2013 06:56:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7627621F86CE for ; Wed, 29 May 2013 06:56:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E05101F0774; Wed, 29 May 2013 09:56:04 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C79A11F079F; Wed, 29 May 2013 09:56:04 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 29 May 2013 09:56:04 -0400 Message-ID: <51A608CD.1040604@mitre.org> Date: Wed, 29 May 2013 09:55:25 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vincent Tsang References: <-8470720313341818373@unknownmsgid> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000103070503040401000200" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 13:56:12 -0000 --------------000103070503040401000200 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The device flow is really made for cases where the client software can't open a full browser at all, like a limited set top box or embedded device. Since you can access a browser, you can very easily do an authorization code flow with a native app. The only "trick" is getting the code back to the application, and you've got several options there. The basics go like this: 0. App gets registered with the auth server (either by hand or using dynamic registration -- your pick, but it's a tradeoff: if the former, you probably won't be able to use a client_secret; if the latter, you can more easily have a client_secret but you have to manage multiple instances of the client with separate client_id's) 1. App needs to access protected API, so it creates a request URL to the authorization server's authorization endpoint (using response_type=code) 2. App opens the system browser (using whatever native system tools for this) with the authorization URL created in (1) 3. User goes to the authorization page in the web browser 4. User authenticates to the authorization server (however the auth server wants to authenticate the user) 5. User approves the application 6. Authorization server generates an auth code and appends it to the callback URL for the application. this is where you have a few options: 6a. Callback URL uses a custom URI scheme like "myapp://oauth?code=foobar" that opens up a callback to the running application. This is very common on mobile systems. 6b. Callback URL goes to trusted web page that displays the code to the user, the user copies and pastes this code into the application. This is hardy against technology differences but requires user input. 6c. Callback URL goes to a trusted backend service that takes the code and pushes it through some trusted means out to the application instance. Again, this is more common on mobile platforms than on the desktop. 6d. Callback URL goes to a temporary HTTP server stood up on localhost that is run by the app, like "http://localhost:93214/oauth?code=foobar". Since the app is running this embedded web server and it's only on localhost, it can easily grab the code from the request. 6e. Callback URL goes to a trusted webpage that puts the code into the HTML title element or other portion of the page, and the app scans all open windows looking for a specific pattern. Google was fond of this hack, for some reason, but I wouldn't recommend it. 7. Once it has the code, App calls the Token Endpoint with the code and (if possible) its credentials, gets an access token (and optionally a refresh token). Personally, I've written apps that do 6a, 6b, and 6d with various levels of complexity and success. All depends on what you have available on your platform. Hope this helps, -- Justin On 05/29/2013 12:31 AM, Vincent Tsang wrote: > The client is a native windows application, for instance, a document > editor like MS Word. > The editor can upload copies to the cloud (e.g. Amazon S3), then > record the version history and notes associated with each cloud copy > to our cloud service via our cloud application API (to be secured by > OAuth access tokens). > I think it's similar to the case with a media player application (like > VLC/Windows Media Player) that sends playlist/history info to the > cloud via some cloud application API. > I'm just not sure which of the 4 scenarios described in the OAuth spec > could fit in here... > > Thanks. > Vincent > > > On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura > wrote: > > A little more application and user context would help. > A use case, so to speak. > > Nat > > 2013/05/29 12:04?Vincent Tsang > ??????: > > > Hi Hannes, > > > > Thanks for your reply. > > Actually I am new to OAuth and am simply trying to search for > the best industrial practice for granting access tokens when the > client to our application API is a simple windows applications, > which in most cases runs on PC's with web browser installed. > > Therefore the scenario doesn't quite match what is described in > the document, as the user doesn't need a separate machine to > perform the verification; it's just that the client application > doesn't have internet browsing capability itself (in this sense > it's similar to the "device" described in this document, though > not quite) and so user needs to launch a separate browser application. > > I ended up on this device profile spec just because it seems to > match closer to our scenario when compared to the 4 cases > described in the OAuth 2 spec, but it could be the case that I > didn't understand it fully. > > Maybe I should rephrase my question: could someone please advice > what should be the best practice for granting OAuth tokens to > clients which are native windows applications? > > > > Thanks. > > Vincent > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000103070503040401000200 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The device flow is really made for cases where the client software can't open a full browser at all, like a limited set top box or embedded device. Since you can access a browser, you can very easily do an authorization code flow with a native app. The only "trick" is getting the code back to the application, and you've got several options there. The basics go like this:

0. App gets registered with the auth server (either by hand or using dynamic registration -- your pick, but it's a tradeoff: if the former, you probably won't be able to use a client_secret; if the latter, you can more easily have a client_secret but you have to manage multiple instances of the client with separate client_id's)
1. App needs to access protected API, so it creates a request URL to the authorization server's authorization endpoint (using response_type=code)
2. App opens the system browser (using whatever native system tools for this) with the authorization URL created in (1)
3. User goes to the authorization page in the web browser
4. User authenticates to the authorization server (however the auth server wants to authenticate the user)
5. User approves the application
6. Authorization server generates an auth code and appends it to the callback URL for the application. this is where you have a few options:
    6a. Callback URL uses a custom URI scheme like "myapp://oauth?code=foobar" that opens up a callback to the running application. This is very common on mobile systems.
    6b. Callback URL goes to trusted web page that displays the code to the user, the user copies and pastes this code into the application. This is hardy against technology differences but requires user input.
    6c. Callback URL goes to a trusted backend service that takes the code and pushes it through some trusted means out to the application instance. Again, this is more common on mobile platforms than on the desktop.
    6d. Callback URL goes to a temporary HTTP server stood up on localhost that is run by the app, like "http://localhost:93214/oauth?code=foobar". Since the app is running this embedded web server and it's only on localhost, it can easily grab the code from the request.
    6e. Callback URL goes to a trusted webpage that puts the code into the HTML title element or other portion of the page, and the app scans all open windows looking for a specific pattern. Google was fond of this hack, for some reason, but I wouldn't recommend it.
7. Once it has the code, App calls the Token Endpoint with the code and (if possible) its credentials, gets an access token (and optionally a refresh token).


Personally, I've written apps that do 6a, 6b, and 6d with various levels of complexity and success. All depends on what you have available on your platform.

Hope this helps,
 -- Justin


On 05/29/2013 12:31 AM, Vincent Tsang wrote:
The client is a native windows application, for instance, a document editor like MS Word. 
The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens).
I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. 
I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... 

Thanks.
Vincent


On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <sakimura@gmail.com> wrote:
A little more application and user context would help.
A use case, so to speak.

Nat

2013/05/29 12:04、Vincent Tsang <vincetsang@gmail.com> のメッセージ:

> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed.
> Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application.
> I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully.
> Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications?
>
> Thanks.
> Vincent
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

--------------000103070503040401000200-- From vincetsang@gmail.com Wed May 29 07:20:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4321F91CB; Wed, 29 May 2013 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E5bwSt5GL7R; Wed, 29 May 2013 07:20:32 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7114021F9121; Wed, 29 May 2013 07:20:31 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so3552507wib.2 for ; Wed, 29 May 2013 07:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N8Syqjm4xqvR51yTNyMv05Wz3CMfgzUFxT5wPPrJAVA=; b=lBGnbiTSSM9ccTA43KIKlqzGiWtNikXXrWYQ1mn7HGQXMfl8C5EOz+4psKnGBnfvJx KQD6R3HIrcvGqchNoHc9NdXb/JLnjS/PWkMShBM09vJvZSI2x1h06Nz5bBNLsBA4izQo 0mzmHIk0md+9e6t2AQNU4yiQSnFG0as1RvdxQZPiQnSb1MB17kAlWAiDRn/D+HME5GqB 9lEhRHVmowN0UHk21C09JaJl58MsavRSBGf4KYnrI1BPoCWXhb2TNK9lsQiANIfL7Tiq 6DVgN1lOeBoBxw7K8KkouJPKI+Iu6ip6wMfkBYwMfswjf8C3lWEnn1ra5oOSZsVsAwBw 4+dw== MIME-Version: 1.0 X-Received: by 10.180.212.49 with SMTP id nh17mr15730696wic.60.1369837230610; Wed, 29 May 2013 07:20:30 -0700 (PDT) Received: by 10.216.80.198 with HTTP; Wed, 29 May 2013 07:20:30 -0700 (PDT) In-Reply-To: References: <-8470720313341818373@unknownmsgid> Date: Wed, 29 May 2013 22:20:30 +0800 Message-ID: From: Vincent Tsang To: Todd W Lainhart Content-Type: multipart/alternative; boundary=001a11c34c8487e13704dddc153c Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 14:20:33 -0000 --001a11c34c8487e13704dddc153c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? Thanks. Vincent On Wednesday, May 29, 2013, Todd W Lainhart wrote: > On behalf of what will the access token be granted - the app (e.g. Word), > or the user running the app? > > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com * > > > > > From: Vincent Tsang 'cvml', 'vincetsang@gmail.com');>> > To: Nat Sakimura 'sakimura@gmail.com');>>, > Cc: "oauth@ietf.org = " > > > Date: 05/29/2013 12:31 AM > Subject: Re: [OAUTH-WG] Device profile usage > Sent by: oauth-bounces@ietf.org 'oauth-bounces@ietf.org');> > ------------------------------ > > > > The client is a native windows application, for instance, a document > editor like MS Word. > The editor can upload copies to the cloud (e.g. Amazon S3), then record > the version history and notes associated with each cloud copy to our clou= d > service via our cloud application API (to be secured by OAuth access > tokens). > I think it's similar to the case with a media player application (like > VLC/Windows Media Player) that sends playlist/history info to the cloud v= ia > some cloud application API. > I'm just not sure which of the 4 scenarios described in the OAuth spec > could fit in here... > > Thanks. > Vincent > > > On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <*sakimura@gmail.com*> > wrote: > A little more application and user context would help. > A use case, so to speak. > > Nat > > 2013/05/29 12:04=A1=A2Vincent Tsang <*vincetsang@gmail.com* 'cvml', 'vincetsang@gmail.com');>> =A4=CE=A5=E1=A5=C3=A5=BB=A9`=A5=B8: > > > Hi Hannes, > > > > Thanks for your reply. > > Actually I am new to OAuth and am simply trying to search for the best > industrial practice for granting access tokens when the client to our > application API is a simple windows applications, which in most cases run= s > on PC's with web browser installed. > > Therefore the scenario doesn't quite match what is described in the > document, as the user doesn't need a separate machine to perform the > verification; it's just that the client application doesn't have internet > browsing capability itself (in this sense it's similar to the "device" > described in this document, though not quite) and so user needs to launch= a > separate browser application. > > I ended up on this device profile spec just because it seems to match > closer to our scenario when compared to the 4 cases described in the OAut= h > 2 spec, but it could be the case that I didn't understand it fully. > > Maybe I should rephrase my question: could someone please advice what > should be the best practice for granting OAuth tokens to clients which ar= e > native windows applications? > > > > Thanks. > > Vincent > > > > _______________________________________________ > > OAuth mailing list > > *OAuth@ietf.org* > > *https://www.ietf.org/mailman/listinfo/oauth* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c34c8487e13704dddc153c Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 VGhlIHNhbWUgdXNlciBjb3VsZCBydW4gdGhlIGFwcCBvbiBtdWx0aXBsZSBjb21wdXRlcnMgYW5k IEkgd2FudCB0byBkaXN0aW5ndWlzaCBlYWNoIHJ1bm5pbmcgaW5zdGFuY2UsIHNvIEkgdGhpbmsm bmJzcDtpdCYjMzk7cyB0aGUgYXBwPyZuYnNwOzxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLiZu YnNwOzwvZGl2PjxkaXY+VmluY2VudDxzcGFuPjwvc3Bhbj48YnI+PGJyPk9uIFdlZG5lc2RheSwg TWF5IDI5LCAyMDEzLCBUb2RkIFcgTGFpbmhhcnQgIHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxmb250IGZhY2U9InNhbnMtc2VyaWYiPk9u IGJlaGFsZiBvZiB3aGF0IHdpbGwgdGhlIGFjY2VzcyB0b2tlbg0KYmUgZ3JhbnRlZCAtIHRoZSBh cHAgKGUuZy4gV29yZCksIG9yIHRoZSB1c2VyIHJ1bm5pbmcgdGhlIGFwcD88YnI+DQo8L2ZvbnQ+ DQo8YnI+DQo8dGFibGUgd2lkdGg9IjIyMyIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBz ZSI+DQo8dGJvZHk+PHRyIGhlaWdodD0iOCI+DQo8dGQgd2lkdGg9IjIyMyIgYmdjb2xvcj0id2hp dGUiIHN0eWxlPSJib3JkZXItc3R5bGU6c29saWQ7Ym9yZGVyLWNvbG9yOiMwMDAwMDA7Ym9yZGVy LXdpZHRoOjBweCAwcHggMHB4IDBweDtwYWRkaW5nOjBweCAwcHgiPjxmb250IHNpemU9IjEiIGZh Y2U9IlZlcmRhbmEiPjxiPjxicj4NCjxicj4NCjxicj4NClRvZGQgTGFpbmhhcnQ8YnI+DQpSYXRp b25hbCBzb2Z0d2FyZTxicj4NCklCTSBDb3Jwb3JhdGlvbjxicj4NCjU1MCBLaW5nIFN0cmVldCwg TGl0dGxldG9uLCBNQSAwMTQ2MC0xMjUwPC9iPjwvZm9udD48Zm9udCBzaXplPSIxIiBmYWNlPSJB cmlhbCI+PGI+PGJyPg0KMS05NzgtODk5LTQ3MDU8YnI+DQoyLTI3Ni00NzA1IChUL0wpPGJyPg0K PGEgaHJlZj0iamF2YXNjcmlwdDpfZSh7fSwgJiMzOTtjdm1sJiMzOTssICYjMzk7bGFpbmhhcnRA dXMuaWJtLmNvbSYjMzk7KTsiIHRhcmdldD0iX2JsYW5rIj5sYWluaGFydEB1cy5pYm0uY29tPC9h PjwvYj48L2ZvbnQ+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzVmNWY1ZiIgZmFjZT0ic2Fucy1zZXJp ZiI+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPSIx IiBmYWNlPSJzYW5zLXNlcmlmIj5WaW5jZW50IFRzYW5nICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0 Ol9lKHt9LCAmIzM5O2N2bWwmIzM5OywgJiMzOTt2aW5jZXRzYW5nQGdtYWlsLmNvbSYjMzk7KTsi IHRhcmdldD0iX2JsYW5rIj52aW5jZXRzYW5nQGdtYWlsLmNvbTwvYT4mZ3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjNWY1ZjVmIiBmYWNlPSJzYW5zLXNlcmlmIj5UbzogJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPSIxIiBmYWNlPSJzYW5z LXNlcmlmIj5OYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2Uoe30sICYjMzk7 Y3ZtbCYjMzk7LCAmIzM5O3Nha2ltdXJhQGdtYWlsLmNvbSYjMzk7KTsiIHRhcmdldD0iX2JsYW5r Ij5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OywNCjwvZm9udD4NCjxicj48Zm9udCBzaXplPSIx IiBjb2xvcj0iIzVmNWY1ZiIgZmFjZT0ic2Fucy1zZXJpZiI+Q2M6ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 PGEgaHJlZj0iamF2YXNjcmlwdDpfZSh7fSwgJiMzOTtjdm1sJiMzOTssICYjMzk7b2F1dGhAaWV0 Zi5vcmcmIzM5Oyk7IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7DQom bHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSh7fSwgJiMzOTtjdm1sJiMzOTssICYjMzk7b2F1dGhA aWV0Zi5vcmcmIzM5Oyk7IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozwv Zm9udD4NCjxicj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzVmNWY1ZiIgZmFjZT0ic2Fucy1zZXJp ZiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPSIx IiBmYWNlPSJzYW5zLXNlcmlmIj4wNS8yOS8yMDEzIDEyOjMxIEFNPC9mb250Pg0KPGJyPjxmb250 IHNpemU9IjEiIGNvbG9yPSIjNWY1ZjVmIiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9IjEiIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbT0FVVEgtV0ddDQpEZXZpY2UgcHJvZmlsZSB1c2FnZTwvZm9udD4NCjxicj48 Zm9udCBzaXplPSIxIiBjb2xvcj0iIzVmNWY1ZiIgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTog Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPSIxIiBmYWNlPSJz YW5zLXNlcmlmIj48YSBocmVmPSJqYXZhc2NyaXB0Ol9lKHt9LCAmIzM5O2N2bWwmIzM5OywgJiMz OTtvYXV0aC1ib3VuY2VzQGlldGYub3JnJiMzOTspOyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGNsaWVudCBpcyBhIG5h dGl2ZSB3aW5kb3dzIGFwcGxpY2F0aW9uLA0KZm9yIGluc3RhbmNlLCBhIGRvY3VtZW50IGVkaXRv ciBsaWtlIE1TIFdvcmQuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPSIzIiBmYWNlPSJzYW5zLXNl cmlmIj5UaGUgZWRpdG9yIGNhbiB1cGxvYWQgY29waWVzIHRvIHRoZQ0KY2xvdWQgKGUuZy4gQW1h em9uIFMzKSwgdGhlbiByZWNvcmQgdGhlIHZlcnNpb24gaGlzdG9yeSBhbmQgbm90ZXMgYXNzb2Np YXRlZA0Kd2l0aCBlYWNoIGNsb3VkIGNvcHkgdG8gb3VyIGNsb3VkIHNlcnZpY2UgdmlhIG91ciBj bG91ZCBhcHBsaWNhdGlvbiBBUEkNCih0byBiZSBzZWN1cmVkIGJ5IE9BdXRoIGFjY2VzcyB0b2tl bnMpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPSIzIiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5r IGl0JiMzOTtzIHNpbWlsYXIgdG8gdGhlIGNhc2Ugd2l0aA0KYSBtZWRpYSBwbGF5ZXIgYXBwbGlj YXRpb24gKGxpa2UgVkxDL1dpbmRvd3MgTWVkaWEgUGxheWVyKSB0aGF0IHNlbmRzIHBsYXlsaXN0 L2hpc3RvcnkNCmluZm8gdG8gdGhlIGNsb3VkIHZpYSBzb21lIGNsb3VkIGFwcGxpY2F0aW9uIEFQ SS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9IjMiIGZhY2U9InNhbnMtc2VyaWYiPkkmIzM5O20g anVzdCBub3Qgc3VyZSB3aGljaCBvZiB0aGUgNCBzY2VuYXJpb3MNCmRlc2NyaWJlZCBpbiB0aGUg T0F1dGggc3BlYyBjb3VsZCBmaXQgaW4gaGVyZS4uLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PSIzIiBmYWNlPSJzYW5zLXNlcmlmIj5WaW5jZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9IjMi IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPSIzIiBmYWNl PSJzYW5zLXNlcmlmIj5PbiBXZWQsIE1heSAyOSwgMjAxMyBhdCAxMTozOCBBTSwgTmF0DQpTYWtp bXVyYSAmbHQ7PC9mb250PjxhIGhyZWY9ImphdmFzY3JpcHQ6X2Uoe30sICYjMzk7Y3ZtbCYjMzk7 LCAmIzM5O3Nha2ltdXJhQGdtYWlsLmNvbSYjMzk7KTsiIHRhcmdldD0iX2JsYW5rIj48Zm9udCBz aXplPSIzIiBjb2xvcj0iYmx1ZSIgZmFjZT0ic2Fucy1zZXJpZiI+PHU+c2FraW11cmFAZ21haWwu Y29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0iMyIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0K d3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9IjMiIGZhY2U9InNhbnMtc2VyaWYiPkEgbGl0 dGxlIG1vcmUgYXBwbGljYXRpb24gYW5kIHVzZXIgY29udGV4dA0Kd291bGQgaGVscC48YnI+DQpB IHVzZSBjYXNlLCBzbyB0byBzcGVhay48YnI+DQo8YnI+DQpOYXQ8YnI+DQo8YnI+DQoyMDEzLzA1 LzI5IDEyOjA0GyRCISIbKEJWaW5jZW50IFRzYW5nICZsdDs8L2ZvbnQ+PGEgaHJlZj0iamF2YXNj cmlwdDpfZSh7fSwgJiMzOTtjdm1sJiMzOTssICYjMzk7dmluY2V0c2FuZ0BnbWFpbC5jb20mIzM5 Oyk7IiB0YXJnZXQ9Il9ibGFuayI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsdWUiIGZhY2U9InNh bnMtc2VyaWYiPjx1PnZpbmNldHNhbmdAZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0KGyRCJE4lYSVDJTshPCU4GyhCOjwvZm9udD4N Cjxicj48Zm9udCBzaXplPSIzIiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7IEhpIEhhbm5l cyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9yIHlvdXIgcmVwbHkuPGJyPg0KJmd0OyBB Y3R1YWxseSBJIGFtIG5ldyB0byBPQXV0aCBhbmQgYW0gc2ltcGx5IHRyeWluZyB0byBzZWFyY2gg Zm9yIHRoZQ0KYmVzdCBpbmR1c3RyaWFsIHByYWN0aWNlIGZvciBncmFudGluZyBhY2Nlc3MgdG9r ZW5zIHdoZW4gdGhlIGNsaWVudCB0bw0Kb3VyIGFwcGxpY2F0aW9uIEFQSSBpcyBhIHNpbXBsZSB3 aW5kb3dzIGFwcGxpY2F0aW9ucywgd2hpY2ggaW4gbW9zdCBjYXNlcw0KcnVucyBvbiBQQyYjMzk7 cyB3aXRoIHdlYiBicm93c2VyIGluc3RhbGxlZC48YnI+DQomZ3Q7IFRoZXJlZm9yZSB0aGUgc2Nl bmFyaW8gZG9lc24mIzM5O3QgcXVpdGUgbWF0Y2ggd2hhdCBpcyBkZXNjcmliZWQgaW4gdGhlDQpk b2N1bWVudCwgYXMgdGhlIHVzZXIgZG9lc24mIzM5O3QgbmVlZCBhIHNlcGFyYXRlIG1hY2hpbmUg dG8gcGVyZm9ybSB0aGUgdmVyaWZpY2F0aW9uOw0KaXQmIzM5O3MganVzdCB0aGF0IHRoZSBjbGll bnQgYXBwbGljYXRpb24gZG9lc24mIzM5O3QgaGF2ZSBpbnRlcm5ldCBicm93c2luZyBjYXBhYmls aXR5DQppdHNlbGYgKGluIHRoaXMgc2Vuc2UgaXQmIzM5O3Mgc2ltaWxhciB0byB0aGUgJnF1b3Q7 ZGV2aWNlJnF1b3Q7IGRlc2NyaWJlZA0KaW4gdGhpcyBkb2N1bWVudCwgdGhvdWdoIG5vdCBxdWl0 ZSkgYW5kIHNvIHVzZXIgbmVlZHMgdG8gbGF1bmNoIGEgc2VwYXJhdGUNCmJyb3dzZXIgYXBwbGlj YXRpb24uPGJyPg0KJmd0OyBJIGVuZGVkIHVwIG9uIHRoaXMgZGV2aWNlIHByb2ZpbGUgc3BlYyBq dXN0IGJlY2F1c2UgaXQgc2VlbXMgdG8gbWF0Y2gNCmNsb3NlciB0byBvdXIgc2NlbmFyaW8gd2hl biBjb21wYXJlZCB0byB0aGUgNCBjYXNlcyBkZXNjcmliZWQgaW4gdGhlIE9BdXRoDQoyIHNwZWMs IGJ1dCBpdCBjb3VsZCBiZSB0aGUgY2FzZSB0aGF0IEkgZGlkbiYjMzk7dCB1bmRlcnN0YW5kIGl0 IGZ1bGx5Ljxicj4NCiZndDsgTWF5YmUgSSBzaG91bGQgcmVwaHJhc2UgbXkgcXVlc3Rpb246IGNv dWxkIHNvbWVvbmUgcGxlYXNlIGFkdmljZSB3aGF0DQpzaG91bGQgYmUgdGhlIGJlc3QgcHJhY3Rp Y2UgZm9yIGdyYW50aW5nIE9BdXRoIHRva2VucyB0byBjbGllbnRzIHdoaWNoDQphcmUgbmF0aXZl IHdpbmRvd3MgYXBwbGljYXRpb25zPzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcy48YnI+DQom Z3Q7IFZpbmNlbnQ8YnI+DQomZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9IjMiIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9mb250PjxhIGhy ZWY9ImphdmFzY3JpcHQ6X2Uoe30sICYjMzk7Y3ZtbCYjMzk7LCAmIzM5O09BdXRoQGlldGYub3Jn JiMzOTspOyIgdGFyZ2V0PSJfYmxhbmsiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibHVlIiBmYWNl PSJzYW5zLXNlcmlmIj48dT5PQXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 IjMiIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48Zm9u dCBzaXplPSIzIiBjb2xvcj0iYmx1ZSIgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC9hPg0KPGJyPjx0dD48 Zm9udD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9ImphdmFzY3JpcHQ6X2Uoe30sICYjMzk7 Y3ZtbCYjMzk7LCAmIzM5O09BdXRoQGlldGYub3JnJiMzOTspOyIgdGFyZ2V0PSJfYmxhbmsiPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48dHQ+PGZvbnQ+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvZm9udD48L3R0Pjwv YT48dHQ+PGZvbnQ+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pg0K --001a11c34c8487e13704dddc153c-- From jricher@mitre.org Wed May 29 07:22:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1921F9017 for ; Wed, 29 May 2013 07:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZweoq0cIiSs for ; Wed, 29 May 2013 07:22:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31421F9060 for ; Wed, 29 May 2013 07:22:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E30A1F07AC; Wed, 29 May 2013 10:22:21 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0D7EF1F05AA; Wed, 29 May 2013 10:22:21 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 29 May 2013 10:22:20 -0400 Message-ID: <51A60EF6.8040403@mitre.org> Date: Wed, 29 May 2013 10:21:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vincent Tsang References: <-8470720313341818373@unknownmsgid> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060804080102010908060803" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 14:22:34 -0000 --------------060804080102010908060803 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Yes, it's the app that is granted a token on behalf of the user. This is a very classic OAuth pattern. -- Justin On 05/29/2013 10:20 AM, Vincent Tsang wrote: > The same user could run the app on multiple computers and I want to > distinguish each running instance, so I think it's the app? > > Thanks. > Vincent > > On Wednesday, May 29, 2013, Todd W Lainhart wrote: > > On behalf of what will the access token be granted - the app (e.g. > Word), or the user running the app? > > * > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250** > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com 'lainhart@us.ibm.com');>* > > > > > > > From: Vincent Tsang 'cvml', 'vincetsang@gmail.com');>> > To: Nat Sakimura 'sakimura@gmail.com');>>, > Cc: "oauth@ietf.org 'oauth@ietf.org');>" 'oauth@ietf.org');>> > Date: 05/29/2013 12:31 AM > Subject: Re: [OAUTH-WG] Device profile usage > Sent by: oauth-bounces@ietf.org 'oauth-bounces@ietf.org');> > ------------------------------------------------------------------------ > > > > The client is a native windows application, for instance, a > document editor like MS Word. > The editor can upload copies to the cloud (e.g. Amazon S3), then > record the version history and notes associated with each cloud > copy to our cloud service via our cloud application API (to be > secured by OAuth access tokens). > I think it's similar to the case with a media player application > (like VLC/Windows Media Player) that sends playlist/history info > to the cloud via some cloud application API. > I'm just not sure which of the 4 scenarios described in the OAuth > spec could fit in here... > > Thanks. > Vincent > > > On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura > <_sakimura@gmail.com_ 'sakimura@gmail.com');>> wrote: > A little more application and user context would help. > A use case, so to speak. > > Nat > > 2013/05/29 12:04?Vincent Tsang <_vincetsang@gmail.com_ > > ??????: > > > Hi Hannes, > > > > Thanks for your reply. > > Actually I am new to OAuth and am simply trying to search for > the best industrial practice for granting access tokens when the > client to our application API is a simple windows applications, > which in most cases runs on PC's with web browser installed. > > Therefore the scenario doesn't quite match what is described in > the document, as the user doesn't need a separate machine to > perform the verification; it's just that the client application > doesn't have internet browsing capability itself (in this sense > it's similar to the "device" described in this document, though > not quite) and so user needs to launch a separate browser application. > > I ended up on this device profile spec just because it seems to > match closer to our scenario when compared to the 4 cases > described in the OAuth 2 spec, but it could be the case that I > didn't understand it fully. > > Maybe I should rephrase my question: could someone please advice > what should be the best practice for granting OAuth tokens to > clients which are native windows applications? > > > > Thanks. > > Vincent > > > > _______________________________________________ > > OAuth mailing 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 --------------060804080102010908060803 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Yes, it's the app that is granted a token on behalf of the user. This is a very classic OAuth pattern.

 -- Justin

On 05/29/2013 10:20 AM, Vincent Tsang wrote:
The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? 

Thanks. 
Vincent

On Wednesday, May 29, 2013, Todd W Lainhart wrote:
On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Vincent Tsang <vincetsang@gmail.com>
To:        Nat Sakimura <sakimura@gmail.com>,
Cc:        "oauth@ietf.org" <oauth@ietf.org>
Date:        05/29/2013 12:31 AM
Subject:        Re: [OAUTH-WG] Device profile usage
Sent by:        oauth-bounces@ietf.org



The client is a native windows application, for instance, a document editor like MS Word.
The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens).
I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API.
I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here...

Thanks.
Vincent


On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <sakimura@gmail.com> wrote:
A little more application and user context would help.
A use case, so to speak.

Nat

2013/05/29 12:04、Vincent Tsang <vincetsang@gmail.com> のメッセージ:

> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed.
> Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application.
> I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully.
> Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications?
>
> Thanks.
> Vincent
>
> _______________________________________________
> OAuth mailing 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

--------------060804080102010908060803-- From tonynad@microsoft.com Wed May 29 08:25:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED62521F93A6 for ; Wed, 29 May 2013 08:25:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hefYjXuQHUre for ; Wed, 29 May 2013 08:25:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D321F941F for ; Wed, 29 May 2013 08:25:25 -0700 (PDT) Received: from BN1BFFO11FD008.protection.gbl (10.58.52.203) by BN1AFFO11HUB011.protection.gbl (10.58.52.121) with Microsoft SMTP Server (TLS) id 15.0.707.0; Wed, 29 May 2013 15:23:50 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 29 May 2013 15:23:50 +0000 Received: from CO9EHSOBE037.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 29 May 2013 15:23:36 +0000 Received: from mail53-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 15:23:35 +0000 Received: from mail53-co9 (localhost [127.0.0.1]) by mail53-co9-R.bigfish.com (Postfix) with ESMTP id 9E8EB2607AC for ; Wed, 29 May 2013 15:23:35 +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(zz98dI9371Ic85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh17ej9a9j1155h) Received-SPF: softfail (mail53-co9: 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:BY2PR03MB192; H:BY2PR03MB189.namprd03.prod.outlook.com; LANG:en; Received: from mail53-co9 (localhost.localdomain [127.0.0.1]) by mail53-co9 (MessageSwitch) id 1369841013685702_19116; Wed, 29 May 2013 15:23:33 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.230]) by mail53-co9.bigfish.com (Postfix) with ESMTP id A51722801FC; Wed, 29 May 2013 15:23:33 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 15:23:32 +0000 Received: from BY2PR03MB192.namprd03.prod.outlook.com (10.242.36.144) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 29 May 2013 15:23:31 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB192.namprd03.prod.outlook.com (10.242.36.144) with Microsoft SMTP Server (TLS) id 15.0.698.13; Wed, 29 May 2013 15:23:29 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.161]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.161]) with mapi id 15.00.0698.010; Wed, 29 May 2013 15:23:29 +0000 From: Anthony Nadalin To: Dick Hardt , O Auth WG Thread-Topic: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE Thread-Index: AQHOW8FGkRCakpTLnEu4Z1c1BnoSlZkcSPkA Date: Wed, 29 May 2013 15:23:28 +0000 Message-ID: References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:2a:2:92a:7243:8cd5:1397] Content-Type: multipart/alternative; boundary="_000_bdf66a4a6ade4c9f967b6ec2e5893f7dBY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB192.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%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(199002)(24454002)(54356001)(79102001)(74316001)(6806003)(74366001)(71186001)(81542001)(33646001)(76576001)(74876001)(81342001)(65816001)(74706001)(512954002)(76796001)(76786001)(16676001)(16236675002)(15202345002)(46102001)(74502001)(20776003)(54316002)(56816002)(53806001)(74662001)(80022001)(59766001)(56776001)(76482001)(51856001)(47446002)(69226001)(77982001)(49866001)(50986001)(47736001)(47976001)(4396001)(31966008)(63696002)(42262001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB011; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08617F610C Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 15:25:41 -0000 --_000_bdf66a4a6ade4c9f967b6ec2e5893f7dBY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So there could be privacy issues on why I would not want the ISS or AUD out= side the encrypted payload From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Tuesday, May 28, 2013 9:34 AM To: O Auth WG Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Paramet= er Names in JWE Following up on this topic ... On Wed, May 1, 2013 at 2:12 PM, Dick Hardt > wrote: "iss" and "aud" would be optional parameters in a JWE. These parameters are= in the payload, but since it is encrypted, the payload must be decrypted b= efore they can be read. Some times knowing these parameters is required to = be able to decrypt the payload ... These would be additions to 9.3.1 in the JWT specification. Why "iss" is needed: Bob and Charlie each gave Alice a KID and a symmetric key to use to verify = and decrypt tokens from them. The App and Alice share keys so Alice knows it is the App. The User authorizes Bob to give the App a token (which authorizes the App t= o do something) The App gives the token to Alice. Since Alice indirectly received the token, the only way for Alice to know = who sent the token, is to look at the KID as the "iss" claim is encrypted. = If the "kid" values are GUIDs, then Alice can just look up the "kid" and re= trieve the associated symmetric key, and then decrypt and verify the token = and THEN see who sent it. If there is a collision in KID values (Bon and Ch= arlie gave the same KID for different keys), then Alice will not know which= symmetric key to use. Why "aud" is needed: Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symm= etric key to Gwen. Ellen and Gwen trust each other and know how to talk to each other. Gwen do= es not know Dave. Ellen does not know Frank The App and Gwen share keys so Gwen knows it is the App. The User authorizes Dave to give the App a token Dave gives the token to Gwen (Dave does not have a relationship with Ellen) Gwen now has a token that Ellen can decrypt and verify, but has no method f= or knowing that Ellen can do that. The "aud" property would allow Gwen to g= ive the token to Ellen to decrypt and verify. -- -- Dick --_000_bdf66a4a6ade4c9f967b6ec2e5893f7dBY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So there could be privacy= issues on why I would not want the ISS or AUD outside the encrypted payloa= d

 

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Tuesday, May 28, 2013 9:34 AM
To: O Auth WG
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud"= to Reserved Header Parameter Names in JWE

 

Following up on this topic ... 

 

On Wed, May 1, 2013 at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

"iss" and "aud" would be optiona= l parameters in a JWE. These parameters are in the payload, but since it is= encrypted, the payload must be decrypted before they can be read. Some tim= es knowing these parameters is required to be able to decrypt the payload …

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify = and decrypt tokens from them.

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App t= o do something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to = know who sent the token, is to look at the KID as the "iss" claim= is encrypted. If the "kid" values are GUIDs, then Alice can just= look up the "kid" and retrieve the associated symmetric key, and then decrypt and verify the token and THEN see who sent it. If th= ere is a collision in KID values (Bon and Charlie gave the same KID for dif= ferent keys), then Alice will not know which symmetric key to use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symm= etric key to Gwen.

Ellen and Gwen trust each other and know how to talk to each other. Gwen do= es not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)=

Gwen now has a token that Ellen can decrypt and verify, but has no method f= or knowing that Ellen can do that. The "aud" property would allow= Gwen to give the token to Ellen to decrypt and verify.



 

--
-- Dick

--_000_bdf66a4a6ade4c9f967b6ec2e5893f7dBY2PR03MB189namprd03pro_-- From dick.hardt@gmail.com Wed May 29 08:47:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9F821F9590 for ; Wed, 29 May 2013 08:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEsGe8oe1yGy for ; Wed, 29 May 2013 08:47:36 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E907821F9509 for ; Wed, 29 May 2013 08:47:35 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so4395559bkc.18 for ; Wed, 29 May 2013 08:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OhM3v3GTvT+QRl77FvEFKCglVKc+Lpnw21FMxdCSEqE=; b=S4Z5JiVwvxkTWbrnPc2825iaY4r+nm+Bq4r4v5qDd1DeeGyVK/cJyzatcxrDh4u8DD zNK11bvO8QsZTBx4WeFBnisVv1ajgJSUcbDRyhcNaCKhwTI9MmZTdOCSzZIGY3TgEJpw u+Zp1q3XNqkFSPdhZZ/g2bBDnwNWsL6vVUpUaOgbYQxfJJm+mWSG4eqqD5YJpUYJ83HA e5dXiHGZdfWaa3gdOlMovVMLpqJ4LEFp/ehuwl8UBMppmKEMgDNHNTlJoo/cGn44WGGi /aEg4txeQ2NXc8xfawBIfuZY9hkx6bCyEcWf8OWLAtdbTx2WvADWMWBMGCTlyhw8V3MH RHNA== MIME-Version: 1.0 X-Received: by 10.204.170.200 with SMTP id e8mr824504bkz.168.1369842454971; Wed, 29 May 2013 08:47:34 -0700 (PDT) Received: by 10.204.228.8 with HTTP; Wed, 29 May 2013 08:47:34 -0700 (PDT) In-Reply-To: References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> Date: Wed, 29 May 2013 08:47:34 -0700 Message-ID: From: Dick Hardt To: Anthony Nadalin Content-Type: multipart/alternative; boundary=bcaec52c6635ed895704dddd4c0b Cc: O Auth WG Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 15:47:37 -0000 --bcaec52c6635ed895704dddd4c0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, there could be privacy issues, and we can describe that as a consideration in the specification. It is not an issue in my use case. On Wed, May 29, 2013 at 8:23 AM, Anthony Nadalin wro= te: > So there could be privacy issues on why I would not want the ISS or AUD > outside the encrypted payload**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Dick Hardt > *Sent:* Tuesday, May 28, 2013 9:34 AM > *To:* O Auth WG > *Subject:* Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header > Parameter Names in JWE**** > > ** ** > > Following up on this topic ... **** > > ** ** > > On Wed, May 1, 2013 at 2:12 PM, Dick Hardt wrote:*= * > ** > > "iss" and "aud" would be optional parameters in a JWE. These parameters > are in the payload, but since it is encrypted, the payload must be > decrypted before they can be read. Some times knowing these parameters is > required to be able to decrypt the payload =85 > > These would be additions to 9.3.1 in the JWT specification. > > Why "iss" is needed: > > Bob and Charlie each gave Alice a KID and a symmetric key to use to verif= y > and decrypt tokens from them. > > The App and Alice share keys so Alice knows it is the App. > > The User authorizes Bob to give the App a token (which authorizes the App > to do something) > > The App gives the token to Alice. > > Since Alice indirectly received the token, the only way for Alice to kno= w > who sent the token, is to look at the KID as the "iss" claim is encrypted= . > If the "kid" values are GUIDs, then Alice can just look up the "kid" and > retrieve the associated symmetric key, and then decrypt and verify the > token and THEN see who sent it. If there is a collision in KID values (Bo= n > and Charlie gave the same KID for different keys), then Alice will not kn= ow > which symmetric key to use. > > Why "aud" is needed: > > Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and > symmetric key to Gwen. > > Ellen and Gwen trust each other and know how to talk to each other. Gwen > does not know Dave. Ellen does not know Frank > > The App and Gwen share keys so Gwen knows it is the App. > > The User authorizes Dave to give the App a token > > Dave gives the token to Gwen (Dave does not have a relationship with Elle= n) > > Gwen now has a token that Ellen can decrypt and verify, but has no method > for knowing that Ellen can do that. The "aud" property would allow Gwen t= o > give the token to Ellen to decrypt and verify.**** > > > > **** > > ** ** > > -- > -- Dick **** > --=20 -- Dick --bcaec52c6635ed895704dddd4c0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes, there could be privacy issues, and we can describe th= at as a consideration in the specification. It is not an issue in my use ca= se.


On W= ed, May 29, 2013 at 8:23 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

So there could be privacy= issues on why I would not want the ISS or AUD outside the encrypted payloa= d

=A0

From: oauth-bounces@ietf.or= g [mailto:o= auth-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Tuesday, May 28, 2013 9:34 AM
To: O Auth WG
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud"= to Reserved Header Parameter Names in JWE

=A0

Following up on this topic ...=A0

=A0

On Wed, May 1, 2013 at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

"iss" and "aud" would be optiona= l parameters in a JWE. These parameters are in the payload, but since it is= encrypted, the payload must be decrypted before they can be read. Some tim= es knowing these parameters is required to be able to decrypt the payload =85

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify = and decrypt tokens from them.

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App t= o do something)

The App gives the token to Alice.

Since Alice indirectly received the token, =A0the only way for Alice to kno= w who sent the token, is to look at the KID as the "iss" claim is= encrypted. If the "kid" values are GUIDs, then Alice can just lo= ok up the "kid" and retrieve the associated symmetric key, and then decrypt and verify the token and THEN see who sent it. If th= ere is a collision in KID values (Bon and Charlie gave the same KID for dif= ferent keys), then Alice will not know which symmetric key to use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symm= etric key to Gwen.

Ellen and Gwen trust each other and know how to talk to each other. Gwen do= es not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)=

Gwen now has a token that Ellen can decrypt and verify, but has no method f= or knowing that Ellen can do that. The "aud" property would allow= Gwen to give the token to Ellen to decrypt and verify.



=A0

--
-- Dick




--
-- Dick --bcaec52c6635ed895704dddd4c0b-- From lainhart@us.ibm.com Wed May 29 10:28:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAE21F91BF for ; Wed, 29 May 2013 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZVUZHRS+Qyu for ; Wed, 29 May 2013 10:28:06 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC921F90F1 for ; Wed, 29 May 2013 10:28:06 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 May 2013 11:28:05 -0600 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 29 May 2013 11:28:03 -0600 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 82BFF6E803F; Wed, 29 May 2013 13:27:58 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4THRkEl64880816; Wed, 29 May 2013 13:27:47 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4THRkrO006970; Wed, 29 May 2013 13:27:46 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r4THRkBD006967; Wed, 29 May 2013 13:27:46 -0400 In-Reply-To: References: <-8470720313341818373@unknownmsgid> To: Vincent Tsang MIME-Version: 1.0 X-KeepSent: F86999E0:8F266EE6-85257B7A:005F7345; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 Message-ID: From: Todd W Lainhart Date: Wed, 29 May 2013 13:27:44 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 05/29/2013 13:27:46, Serialize complete at 05/29/2013 13:27:46 Content-Type: multipart/alternative; boundary="=_alternative 005FEB3985257B7A_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13052917-3620-0000-0000-000002C5215F Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] Device profile usage X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 17:28:17 -0000 This is a multipart message in MIME format. --=_alternative 005FEB3985257B7A_= Content-Type: text/plain; charset="ISO-2022-JP" > The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? I asked, because I wondered if the client credentials flow or the auth code flow was the more appropriate flow. It sounds like you want to identify both the client and the user, but it's unclear if it's required that the client authenticate. Also, I can't tell from your use case if OAuth is the appropriate solution. If it is the right solution, Justin's response sounds like the way to go. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Vincent Tsang To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" , Nat Sakimura Date: 05/29/2013 10:29 AM Subject: Re: Device profile usage The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app? Thanks. Vincent On Wednesday, May 29, 2013, Todd W Lainhart wrote: On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Vincent Tsang To: Nat Sakimura , Cc: "oauth@ietf.org" Date: 05/29/2013 12:31 AM Subject: Re: [OAUTH-WG] Device profile usage Sent by: oauth-bounces@ietf.org The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04$B!"(BVincent Tsang $B$N%a%C%;!<%8(B: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed. > Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application. > I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications? > > Thanks. > Vincent > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=_alternative 005FEB3985257B7A_= Content-Type: text/html; charset="ISO-2022-JP" > The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app?

I asked, because I wondered if the client credentials flow or the auth code flow was the more appropriate flow. It sounds like you want to identify both the client and the user, but it's unclear if it's required that the client authenticate.  Also, I can't tell from your use case if OAuth is the appropriate solution.

If it is the right solution, Justin's response sounds like the way to go.



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Vincent Tsang <vincetsang@gmail.com>
To:        Todd W Lainhart/Lexington/IBM@IBMUS,
Cc:        "oauth@ietf.org" <oauth@ietf.org>, "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>, Nat Sakimura <sakimura@gmail.com>
Date:        05/29/2013 10:29 AM
Subject:        Re: Device profile usage



The same user could run the app on multiple computers and I want to distinguish each running instance, so I think it's the app?

Thanks.
Vincent

On Wednesday, May 29, 2013, Todd W Lainhart wrote:
On behalf of what will the access token be granted - the app (e.g. Word), or the user running the app?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com






From:        Vincent Tsang <vincetsang@gmail.com>
To:        Nat Sakimura <sakimura@gmail.com>,
Cc:        "oauth@ietf.org" <oauth@ietf.org>
Date:        05/29/2013 12:31 AM
Subject:        Re: [OAUTH-WG] Device profile usage
Sent by:        oauth-bounces@ietf.org



The client is a native windows application, for instance, a document editor like MS Word.
The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens).
I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API.
I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here...

Thanks.
Vincent


On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <sakimura@gmail.com> wrote:
A little more application and user context would help.
A use case, so to speak.

Nat

2013/05/29 12:04$B!"(BVincent Tsang <vincetsang@gmail.com> $B$N%a%C%;!<%8(B:

> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best industrial practice for granting access tokens when the client to our application API is a simple windows applications, which in most cases runs on PC's with web browser installed.
> Therefore the scenario doesn't quite match what is described in the document, as the user doesn't need a separate machine to perform the verification; it's just that the client application doesn't have internet browsing capability itself (in this sense it's similar to the "device" described in this document, though not quite) and so user needs to launch a separate browser application.
> I ended up on this device profile spec just because it seems to match closer to our scenario when compared to the 4 cases described in the OAuth 2 spec, but it could be the case that I didn't understand it fully.
> Maybe I should rephrase my question: could someone please advice what should be the best practice for granting OAuth tokens to clients which are native windows applications?
>
> Thanks.
> Vincent
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--=_alternative 005FEB3985257B7A_=-- From hannes.tschofenig@gmx.net Wed May 29 12:36:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C621F9817 for ; Wed, 29 May 2013 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGcBY+3aT6vW for ; Wed, 29 May 2013 12:35:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83521F9816 for ; Wed, 29 May 2013 12:35:56 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5rJ1-1UX5xj2z3x-00xuHN for ; Wed, 29 May 2013 21:35:54 +0200 Received: (qmail invoked by alias); 29 May 2013 19:35:54 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 29 May 2013 21:35:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/jXe8+weTjzT70GWTi/1M6rEgWf6vxCYpdVLyFyh fk0TgVmHLq+ACK From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2013 22:35:53 +0300 Message-Id: <5A436946-C417-402E-B1ED-327A035363BA@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Review of the assertion drafts X-BeenThere: oauth@ietf.org X-Mailman-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, 29 May 2013 19:36:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi assertion document authors,=20 Hi all,=20 I took a look at the assertion framework draft = (draft-ietf-oauth-assertions-11) and the SAML assertion profile document = (draft-ietf-oauth-saml2-bearer-16.txt).=20 In general, I have to say that they are moving in the right direction. I = see progress.=20 In the assertion draft I particularly liked the improved clarity about = what has to be agreed out-of-band (which relates to interoperability):=20= " Specific=09 items that require agreement are as follows: values for the = issuer=09 and audience identifiers, supported assertion and client=09 authentication types, the location of the token endpoint, and = the key=09 used to apply and verify the digital signature or keyed = message=09 digest over the assertion. " There are also various places where the number of options have been = reduced. Various clarifications in the text seem useful (e.g., the = client id to assertion mapping) although I have not checked them in = detail.=20 I was hoping for more constraints (so that fewer aspects need to be = configured out-of-band) but I guess you guys are not willing to = sacrifice flexibility. I am sure you have noticed that there are a lot = of things that need to be agreed out-of-band. I hope you feel confident = that those who deploy the specification are willing to take these steps. = But at least the spec is not silent about them and provides the = necessary information to the reader.=20 I also recognize improvements regarding the SAML assertion document. = While the use case description is still missing (that would give a bit = more background about what the deployment environment is) there is now a = better example available. The example illustrates an assertion grant; do = you think it would be useful to also show an example for a client = authentication with the SAML assertion?=20 I am planning to talk to Barry to see what he thinks about the updated = document and in the meanwhile I can read into the detailed changes. =20 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRpliZAAoJEGhJURNOOiAtEI0H/3iAd1FyAwPI+EsLri5rjE+q Ic7NGknlQSG/wl9w2xGuq32OuPo/PihLTuEpqIsxwoia5O5wKSX0X42wxMR9dLVk H9bSy5SFj8AoI66KPGeapBB6Lmuzm/7dWknJW9fv1BWIixEkAppY+M08aAYOHW6d OcOy+fEP2x9sx/CE1l6goaXi2hR7M9witrTiGr3Yf/BYkE9ouaAnnZYP/UMrP78N L2clRCykdzLMjjSzugNqnD6KJguHoH4JTnlDT3NS6jL+KwxgXUB5dd8OECuYzlbl 1Z3ORCzFrM7ODytH7HC7SCgsOkIyjb1/xFaTElkVFKkVmvR1rnBz/6+ydgJ+pVk=3D =3DvLB5 -----END PGP SIGNATURE----- From torsten@lodderstedt.net Thu May 30 03:34:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD82121F96F2 for ; Thu, 30 May 2013 03:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGALAPWurR9t for ; Thu, 30 May 2013 03:34:41 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7FD21F967B for ; Thu, 30 May 2013 03:34:40 -0700 (PDT) Received: from [91.2.70.87] (helo=[192.168.71.68]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ui0Bq-0002Qy-MP; Thu, 30 May 2013 12:34:38 +0200 Message-ID: <51A72B3E.9050300@lodderstedt.net> Date: Thu, 30 May 2013 12:34:38 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Justin Richer References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> In-Reply-To: <51A4BF27.50800@mitre.org> 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] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 10:34:46 -0000 Hi Justin, comments inline. >> >> section 1.4 >> >> How is the client supposed to identify/distinguish authorization >> servers? Based on the Client Registration Endpoint URI? Authorization >> server identification is necessary in order to map client_ids to >> authorization servers for clients, which are connected to multiple >> authorization servers. > That's a great question -- but I think it's entirely dependent on how > discovery and configuration is set up for a client, which is > ultimately orthogonal to registration. The way that I've implemented > it in our client is based on the OpenID Connect discovery process, > which bases everything in the server's configuration off of an > "issuer" URL. It would be easy enough to point out here that discovery > and differentiation of different servers is out of scope. At least this should be pointed out. I would rather prefer a definition how to relate client_id and authz server. I don't think your solution can be generalized for generic OAuth since the issuer is only known to OpenID Connect clients. In my opinion, a simple, generic concept could be based on the authorization server's client registration URL. A more sophisticated approach would be to introduce authorization server meta data discovery (as a subset of http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata), which might contain an OAuth authz server id. > >> >> section 1.4.1 f >> >> Why does the client secret expire while the access token ist still >> valid? Secret and token are stored at the same >> locations so an attacker may obtain both at once. > Secrets are used at the token endpoint, so the attack surface is > slightly different. Since you can only use the registration access > token at the registration endpoint, you can use it to rotate your > other credentials. I understand the mechanism. I don't see the benefit given the _slight_ difference in attack surface. In my opinion, the only difference might be on the server side, between HTTPS termination and actual endpoint business logic. So it might limit the impact if an attacker, for example, obtains client secrets from server log files. Is this threat worth to use different credentials with different lifecycles? > >> >> "token_endpoint_auth_method" >> What is the use case for dynamic registration of public clients? In >> my opinion, public clients exist because OAuth 2.0 core does not >> provided a mechanism to provision secrets to the different instances >> of an installed/native app. Dynamic registration closes this gap, so >> any installed app may retrieve a distinct secret. > > This gap-closing is true for some classes of client that used to have > to be public, like many native apps. But there are still clients that > have no use for a client secret, like in-browser clients that use the > implicit flow. Now if these clients are also talking to multiple auth > servers, they'll each need a client_id at the auth server (because > there's no practical way to publish a "public" client ID to *all* auth > servers). A discussion in the security considerations about the > limitations and usefulness of this use case is probably worthwhile, so > I'll make a note to do that. yes, clients using the implicit grant need a way to register. But they don't use the token endpoint. As this is about token endpoint authentication, I still don't see the need to have a "none" method there. > >> >> "client_secret_post vs client_secret_basic" >> BASIC and POST are essentially the same just different ways to send >> the client secret. If an authorization server supports both, both >> should work for any client. So are both methods treated differently? > I agree, and this was one of my original arguments for making this > field plural (or plural-able), but there hasn't been WG support for > that so far. I'm not arguing to make it plural. I think the authentication method is just "client_secret". > >> >> "jwks_uri" >> What is this data used for? the OAuth JWT Bearer Token Profiles? > > That's one, but it's really for any higher-level protocol that uses > signing and encryption. There are several out there that are using > JOSE on top of OAuth to do things, so we felt it was worthwhile to > have one standard place to have the client say "here's my public key". ok, understood. best regards, Torsten. > > -- Justin > >> >> best regards, >> Torsten. >> >> Am 24.05.2013 23:10, schrieb Richer, Justin P.: >>> New Dynamic Registration draft is published, incorporating much of >>> the discussion from the group this week. >>> >>> Some normative changes that should have minimal impact: >>> - "expires_at" is now "client_secret_expires_at" >>> - "issued_at" is now "client_id_issued_at" >>> - creation of an IANA registry for token_endpoint_auth_method >>> - removal of two underdefined values from >>> token_endpoint_auth_method (client_secret_jwt and private_key_jwt), >>> these are now defined in an extension (OpenID Connect Registration) >>> >>> And several editorial changes: >>> >>> - new "client lifecycle" section that describes how different >>> kinds of clients can use the dynamic registration protocol, how a >>> client's credentials get refreshed, and the relationship between the >>> Client Identifier and the Client software >>> - new "registration tokens and credentials" section describing the >>> different kinds of tokens and credentials used in the registration >>> process, what they're for, and why they're all separate >>> - clarified the definitions of several fields like policy_uri and >>> tos_uri >>> >>> Thanks for all the great feedback, and please keep the constructive >>> commentary coming! >>> -- Justin >>> >>> On May 24, 2013, at 4:36 PM, >>> 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 2.0 Dynamic Client Registration Protocol >>>> Author(s) : Justin Richer >>>> John Bradley >>>> Michael B. Jones >>>> Maciej Machulak >>>> Filename : draft-ietf-oauth-dyn-reg-11.txt >>>> Pages : 34 >>>> Date : 2013-05-24 >>>> >>>> Abstract: >>>> This specification defines an endpoint and protocol for dynamic >>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>> methods for the dynamically registered client to manage its >>>> registration. >>>> >>>> >>>> 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-11 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11 >>>> >>>> >>>> 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 jricher@mitre.org Thu May 30 07:21:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2255821F8FF3 for ; Thu, 30 May 2013 07:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxcH1e+DDT-U for ; Thu, 30 May 2013 07:21:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1A21F8C0C for ; Thu, 30 May 2013 07:21:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B184D1F03B3; Thu, 30 May 2013 10:21:46 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9BBCA1F0278; Thu, 30 May 2013 10:21:46 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 10:21:46 -0400 Message-ID: <51A76052.6040004@mitre.org> Date: Thu, 30 May 2013 10:21:06 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> In-Reply-To: <51A72B3E.9050300@lodderstedt.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 14:21:52 -0000 Torsten, thanks -- responses inline. On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote: > Hi Justin, > > comments inline. > >>> >>> section 1.4 >>> >>> How is the client supposed to identify/distinguish authorization >>> servers? Based on the Client Registration Endpoint URI? >>> Authorization server identification is necessary in order to map >>> client_ids to authorization servers for clients, which are connected >>> to multiple authorization servers. >> That's a great question -- but I think it's entirely dependent on how >> discovery and configuration is set up for a client, which is >> ultimately orthogonal to registration. The way that I've implemented >> it in our client is based on the OpenID Connect discovery process, >> which bases everything in the server's configuration off of an >> "issuer" URL. It would be easy enough to point out here that >> discovery and differentiation of different servers is out of scope. > > At least this should be pointed out. I would rather prefer a > definition how to relate client_id and authz server. > > I don't think your solution can be generalized for generic OAuth since > the issuer is only known to OpenID Connect clients. In my opinion, a > simple, generic concept could be based on the authorization server's > client registration URL. A more sophisticated approach would be to > introduce authorization server meta data discovery (as a subset of > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata), > which might contain an OAuth authz server id. I'm not comfortable with specifying a discovery or server differentiation method, but we can at least point out that the means by which the client differentiates servers is out of scope. > >> >>> >>> section 1.4.1 f >>> >>> Why does the client secret expire while the access token ist still >>> valid? Secret and token are stored at the same >>> locations so an attacker may obtain both at once. >> Secrets are used at the token endpoint, so the attack surface is >> slightly different. Since you can only use the registration access >> token at the registration endpoint, you can use it to rotate your >> other credentials. > > I understand the mechanism. I don't see the benefit given the _slight_ > difference in attack surface. In my opinion, the only difference might > be on the server side, between HTTPS termination and actual endpoint > business logic. So it might limit the impact if an attacker, for > example, obtains client secrets from server log files. Is this threat > worth to use different credentials with different lifecycles? That's getting into a different question, the question of the utility of the registration access token. We need that because not all clients have a client_secret (some just don't have any authn, some will use signing or assertions), among other reasons talked about in section 1.3. The fact that their lifecycles are independent simply stems from the fact that they're separate credentials, and that it's more likely desirable to have the client_secret expire in the real world. Also, note that you don't have to expire either of them. Or you can expire both of them at the same time but have some way to keep an expired credential around for one-last-refresh-call or something, you can do that. > >> >>> >>> "token_endpoint_auth_method" >>> What is the use case for dynamic registration of public clients? In >>> my opinion, public clients exist because OAuth 2.0 core does not >>> provided a mechanism to provision secrets to the different instances >>> of an installed/native app. Dynamic registration closes this gap, so >>> any installed app may retrieve a distinct secret. >> >> This gap-closing is true for some classes of client that used to have >> to be public, like many native apps. But there are still clients that >> have no use for a client secret, like in-browser clients that use the >> implicit flow. Now if these clients are also talking to multiple auth >> servers, they'll each need a client_id at the auth server (because >> there's no practical way to publish a "public" client ID to *all* >> auth servers). A discussion in the security considerations about the >> limitations and usefulness of this use case is probably worthwhile, >> so I'll make a note to do that. > > yes, clients using the implicit grant need a way to register. But they > don't use the token endpoint. As this is about token endpoint > authentication, I still don't see the need to have a "none" method there. The "none" method is needed because without it, a server will grant (and expect) a client_secret from a client that has no business having one (and no need for one). > >> >>> >>> "client_secret_post vs client_secret_basic" >>> BASIC and POST are essentially the same just different ways to send >>> the client secret. If an authorization server supports both, both >>> should work for any client. So are both methods treated differently? >> I agree, and this was one of my original arguments for making this >> field plural (or plural-able), but there hasn't been WG support for >> that so far. > > I'm not arguing to make it plural. I think the authentication method > is just "client_secret". That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. > >> >>> >>> "jwks_uri" >>> What is this data used for? the OAuth JWT Bearer Token Profiles? >> >> That's one, but it's really for any higher-level protocol that uses >> signing and encryption. There are several out there that are using >> JOSE on top of OAuth to do things, so we felt it was worthwhile to >> have one standard place to have the client say "here's my public key". > > ok, understood. > > best regards, > Torsten. >> >> -- Justin >> >>> >>> best regards, >>> Torsten. >>> >>> Am 24.05.2013 23:10, schrieb Richer, Justin P.: >>>> New Dynamic Registration draft is published, incorporating much of >>>> the discussion from the group this week. >>>> >>>> Some normative changes that should have minimal impact: >>>> - "expires_at" is now "client_secret_expires_at" >>>> - "issued_at" is now "client_id_issued_at" >>>> - creation of an IANA registry for token_endpoint_auth_method >>>> - removal of two underdefined values from >>>> token_endpoint_auth_method (client_secret_jwt and private_key_jwt), >>>> these are now defined in an extension (OpenID Connect Registration) >>>> >>>> And several editorial changes: >>>> >>>> - new "client lifecycle" section that describes how different >>>> kinds of clients can use the dynamic registration protocol, how a >>>> client's credentials get refreshed, and the relationship between >>>> the Client Identifier and the Client software >>>> - new "registration tokens and credentials" section describing >>>> the different kinds of tokens and credentials used in the >>>> registration process, what they're for, and why they're all separate >>>> - clarified the definitions of several fields like policy_uri and >>>> tos_uri >>>> >>>> Thanks for all the great feedback, and please keep the constructive >>>> commentary coming! >>>> -- Justin >>>> >>>> On May 24, 2013, at 4:36 PM, >>>> 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 2.0 Dynamic Client Registration Protocol >>>>> Author(s) : Justin Richer >>>>> John Bradley >>>>> Michael B. Jones >>>>> Maciej Machulak >>>>> Filename : draft-ietf-oauth-dyn-reg-11.txt >>>>> Pages : 34 >>>>> Date : 2013-05-24 >>>>> >>>>> Abstract: >>>>> This specification defines an endpoint and protocol for dynamic >>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>> methods for the dynamically registered client to manage its >>>>> registration. >>>>> >>>>> >>>>> 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-11 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11 >>>>> >>>>> >>>>> 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 jricher@mitre.org Thu May 30 08:25:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8121F8681 for ; Thu, 30 May 2013 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH0s2r3vJHxK for ; Thu, 30 May 2013 08:25:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 976D021F8A74 for ; Thu, 30 May 2013 08:25:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 394361F02A2; Thu, 30 May 2013 11:25:24 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2E2D21F0373; Thu, 30 May 2013 11:25:24 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Thu, 30 May 2013 11:25:23 -0400 From: "Richer, Justin P." To: Torsten Lodderstedt Thread-Topic: review comments on draft-ietf-oauth-dyn-reg-11.txt Thread-Index: AQHOXSFKoUPHFo+jJEeuqil8woB+1Jkd179qgABE2QA= Date: Thu, 30 May 2013 15:25:23 +0000 Message-ID: <83063673-83F0-4A9C-8A01-F39616559E73@mitre.org> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0a43da90-d30c-43e9-830e-7a26ff31d065@email.android.com> In-Reply-To: <0a43da90-d30c-43e9-830e-7a26ff31d065@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.9.108] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 15:25:35 -0000 On May 30, 2013, at 11:18 AM, Torsten Lodderstedt = wrote: > Hi Justin, >=20 > see below :-) >=20 > Justin Richer schrieb: >=20 >> Torsten, thanks -- responses inline. >>=20 >> On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote: >>> Hi Justin, >>>=20 >>> comments inline. >>>=20 >>>>>=20 >>>>> section 1.4 >>>>>=20 >>>>> How is the client supposed to identify/distinguish authorization=20 >>>>> servers? Based on the Client Registration Endpoint URI?=20 >>>>> Authorization server identification is necessary in order to map=20 >>>>> client_ids to authorization servers for clients, which are >> connected=20 >>>>> to multiple authorization servers. >>>> That's a great question -- but I think it's entirely dependent on >> how=20 >>>> discovery and configuration is set up for a client, which is=20 >>>> ultimately orthogonal to registration. The way that I've implemented >>=20 >>>> it in our client is based on the OpenID Connect discovery process,=20 >>>> which bases everything in the server's configuration off of an=20 >>>> "issuer" URL. It would be easy enough to point out here that=20 >>>> discovery and differentiation of different servers is out of scope. >>>=20 >>> At least this should be pointed out. I would rather prefer a=20 >>> definition how to relate client_id and authz server. >>>=20 >>> I don't think your solution can be generalized for generic OAuth >> since=20 >>> the issuer is only known to OpenID Connect clients. In my opinion, a=20 >>> simple, generic concept could be based on the authorization server's=20 >>> client registration URL. A more sophisticated approach would be to=20 >>> introduce authorization server meta data discovery (as a subset of=20 >>>=20 >> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetada= ta), >>=20 >>> which might contain an OAuth authz server id. >>=20 >> I'm not comfortable with specifying a discovery or server=20 >> differentiation method, but we can at least point out that the means by >>=20 >> which the client differentiates servers is out of scope. >=20 > OK, wfm. >=20 >>>>> section 1.4.1 f >>>>>=20 >>>>> Why does the client secret expire while the access token ist still=20 >>>>> valid? Secret and token are stored at the same >>>>> locations so an attacker may obtain both at once. >>>> Secrets are used at the token endpoint, so the attack surface is=20 >>>> slightly different. Since you can only use the registration access=20 >>>> token at the registration endpoint, you can use it to rotate your=20 >>>> other credentials. >>>=20 >>> I understand the mechanism. I don't see the benefit given the >> _slight_=20 >>> difference in attack surface. In my opinion, the only difference >> might=20 >>> be on the server side, between HTTPS termination and actual endpoint=20 >>> business logic. So it might limit the impact if an attacker, for=20 >>> example, obtains client secrets from server log files. Is this threat >>=20 >>> worth to use different credentials with different lifecycles? >>=20 >> That's getting into a different question, the question of the utility >> of=20 >> the registration access token. We need that because not all clients >> have=20 >> a client_secret (some just don't have any authn, some will use signing=20 >> or assertions), among other reasons talked about in section 1.3. The=20 >> fact that their lifecycles are independent simply stems from the fact=20 >> that they're separate credentials, and that it's more likely desirable=20 >> to have the client_secret expire in the real world. Also, note that you >>=20 >> don't have to expire either of them. Or you can expire both of them at=20 >> the same time but have some way to keep an expired credential around >> for=20 >> one-last-refresh-call or something, you can do that. >=20 > I understand. After thinking about it again I think it makes sense to hav= e different credentials in order to keep client mgnt and the OAuth flow ind= ependent. >=20 >>>>> "token_endpoint_auth_method" >>>>> What is the use case for dynamic registration of public clients? In >>=20 >>>>> my opinion, public clients exist because OAuth 2.0 core does not=20 >>>>> provided a mechanism to provision secrets to the different >> instances=20 >>>>> of an installed/native app. Dynamic registration closes this gap, >> so=20 >>>>> any installed app may retrieve a distinct secret. >>>>=20 >>>> This gap-closing is true for some classes of client that used to >> have=20 >>>> to be public, like many native apps. But there are still clients >> that=20 >>>> have no use for a client secret, like in-browser clients that use >> the=20 >>>> implicit flow. Now if these clients are also talking to multiple >> auth=20 >>>> servers, they'll each need a client_id at the auth server (because=20 >>>> there's no practical way to publish a "public" client ID to *all*=20 >>>> auth servers). A discussion in the security considerations about the >>=20 >>>> limitations and usefulness of this use case is probably worthwhile,=20 >>>> so I'll make a note to do that. >>>=20 >>> yes, clients using the implicit grant need a way to register. But >> they=20 >>> don't use the token endpoint. As this is about token endpoint=20 >>> authentication, I still don't see the need to have a "none" method >> there. >>=20 >> The "none" method is needed because without it, a server will grant >> (and=20 >> expect) a client_secret from a client that has no business having one=20 >> (and no need for one). >=20 > So you are saying this parameter is used to distinguish public and confid= ential clients? Yes, that's one key way that it can be used. On the grand scale, this param= eter just says what kind of authn credential the client is using. In core O= Auth, the only real distinction is "it has one or not", which is the differ= ence between a public and confidential client. This parameter lets you make= that distinction as well as going deeper. >=20 >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> "client_secret_post vs client_secret_basic" >>>>> BASIC and POST are essentially the same just different ways to send >>=20 >>>>> the client secret. If an authorization server supports both, both=20 >>>>> should work for any client. So are both methods treated >> differently? >>>> I agree, and this was one of my original arguments for making this=20 >>>> field plural (or plural-able), but there hasn't been WG support for=20 >>>> that so far. >>>=20 >>> I'm not arguing to make it plural. I think the authentication method=20 >>> is just "client_secret". >>=20 >> That was also an option that was brought up, but in the OIDC WG the=20 >> counter-argument was (as I recall) that the two are syntactically=20 >> separate and there's a desire to restrict to a single type, such as=20 >> disabling client_secret_post. Basically, to make it unambiguous. >=20 > Ok.=20 >=20 > Best regards, > Torsten. >=20 >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> "jwks_uri" >>>>> What is this data used for? the OAuth JWT Bearer Token Profiles? >>>>=20 >>>> That's one, but it's really for any higher-level protocol that uses=20 >>>> signing and encryption. There are several out there that are using=20 >>>> JOSE on top of OAuth to do things, so we felt it was worthwhile to=20 >>>> have one standard place to have the client say "here's my public >> key". >>>=20 >>> ok, understood. >>>=20 >>> best regards, >>> Torsten. >>>>=20 >>>> -- Justin >>>>=20 >>>>>=20 >>>>> best regards, >>>>> Torsten. >>>>>=20 >>>>> Am 24.05.2013 23:10, schrieb Richer, Justin P.: >>>>>> New Dynamic Registration draft is published, incorporating much of >>=20 >>>>>> the discussion from the group this week. >>>>>>=20 >>>>>> Some normative changes that should have minimal impact: >>>>>> - "expires_at" is now "client_secret_expires_at" >>>>>> - "issued_at" is now "client_id_issued_at" >>>>>> - creation of an IANA registry for token_endpoint_auth_method >>>>>> - removal of two underdefined values from=20 >>>>>> token_endpoint_auth_method (client_secret_jwt and >> private_key_jwt),=20 >>>>>> these are now defined in an extension (OpenID Connect >> Registration) >>>>>>=20 >>>>>> And several editorial changes: >>>>>>=20 >>>>>> - new "client lifecycle" section that describes how different=20 >>>>>> kinds of clients can use the dynamic registration protocol, how a=20 >>>>>> client's credentials get refreshed, and the relationship between=20 >>>>>> the Client Identifier and the Client software >>>>>> - new "registration tokens and credentials" section describing=20 >>>>>> the different kinds of tokens and credentials used in the=20 >>>>>> registration process, what they're for, and why they're all >> separate >>>>>> - clarified the definitions of several fields like policy_uri >> and=20 >>>>>> tos_uri >>>>>>=20 >>>>>> Thanks for all the great feedback, and please keep the >> constructive=20 >>>>>> commentary coming! >>>>>> -- Justin >>>>>>=20 >>>>>> On May 24, 2013, at 4:36 PM, >>>>>> wrote: >>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts=20 >>>>>>> directories. >>>>>>> This draft is a work item of the Web Authorization Protocol=20 >>>>>>> Working Group of the IETF. >>>>>>>=20 >>>>>>> Title : OAuth 2.0 Dynamic Client Registration >> Protocol >>>>>>> Author(s) : Justin Richer >>>>>>> John Bradley >>>>>>> Michael B. Jones >>>>>>> Maciej Machulak >>>>>>> Filename : draft-ietf-oauth-dyn-reg-11.txt >>>>>>> Pages : 34 >>>>>>> Date : 2013-05-24 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This specification defines an endpoint and protocol for >> dynamic >>>>>>> registration of OAuth 2.0 Clients at an Authorization Server >> and >>>>>>> methods for the dynamically registered client to manage its >>>>>>> registration. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-11 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >=20 From ve7jtb@ve7jtb.com Thu May 30 08:48:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6078F21F9298 for ; Thu, 30 May 2013 08:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28u7FHKlrXYX for ; Thu, 30 May 2013 08:48:45 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 061AF21F94C3 for ; Thu, 30 May 2013 08:48:39 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id f6so222908qej.20 for ; Thu, 30 May 2013 08:48:39 -0700 (PDT) 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=rfEt4kizwW+BvEBr7xoqF0Scgf0bwlDnMpYu3kNZ890=; b=ZEEytUR/n4L5foBA1GL3/xSq4rO2ckMRPVEZc1FLjgY6YnmrPROiLa/g5u+AX3HJWX m8+GpG4ZS1EF35GtTOFkompg2MVJsoo/y2813upy/BxYcSfzj5KU1I35qTVkqspUkQq3 pJM1jIauoXcFijL4J0fgmvzdW9C+VitvZdzQhviGrEapwAglNhSRgOdV0O79UzRJOouU 6ER4BJWnWcKkhWnqIDn0RokjH/4fK0FAjld131zQ9Npd7URZyoIXCY515kMUzn+3vYK1 7jCnnXhu/u1+Hxofo83bZGR/T0Rjl4udR4jKmNa4oqy9FX4O2myEikYmyjVpACE/HUoQ 09ng== X-Received: by 10.49.98.41 with SMTP id ef9mr2796975qeb.34.1369928919262; Thu, 30 May 2013 08:48:39 -0700 (PDT) Received: from [192.168.1.36] (190-20-30-2.baf.movistar.cl. [190.20.30.2]) by mx.google.com with ESMTPSA id w7sm36077688qej.7.2013.05.30.08.48.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 08:48:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1C9AFE5A-504E-4D6D-979A-3F257C5C8106"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51A76052.6040004@mitre.org> Date: Thu, 30 May 2013 11:48:26 -0400 Message-Id: <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm96KaKZV8L/l9ijVgQbWoHa+uPwNBuxLZVyPrHIvTdJeAHEjq7vG1o8osJlyyz64jWRLbY Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 15:48:56 -0000 --Apple-Mail=_1C9AFE5A-504E-4D6D-979A-3F257C5C8106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think Phil also had some processing reason why a Token endpoint or RS = wouldn't want to tale the authentication as a header, as the processing = was easier with them as parameters as they are potentially available to = different parts of the stack. That may have been mostly around RS, but = the principal may apply to the token endpoint as well. On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>>=20 >>>> "client_secret_post vs client_secret_basic" >>>> BASIC and POST are essentially the same just different ways to send = the client secret. If an authorization server supports both, both should = work for any client. So are both methods treated differently? >>> I agree, and this was one of my original arguments for making this = field plural (or plural-able), but there hasn't been WG support for that = so far. >>=20 >> I'm not arguing to make it plural. I think the authentication method = is just "client_secret". >=20 > That was also an option that was brought up, but in the OIDC WG the = counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. --Apple-Mail=_1C9AFE5A-504E-4D6D-979A-3F257C5C8106 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTU0ODI3WjAjBgkqhkiG9w0BCQQxFgQU8WLTGUXx imvtsKLy+CWcUQG3zdUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAImCZJqtr4yTBZX1PXayEoATbKmIwo0dsQSmtElb4 x3REe2PPlk6I10d/BtK2/eIqLrZWhiaO+proOz9HL7hdyI+ZoHGwu18CuzitDlUIQVytMt8ZRNqF /qov8ZjVb/OygSJcSpQOTtj+5ctvga++kyeKzfHWxSOGvgKTqNNipL5da+9BKpMJ9/vygb/pL150 k8nYov2eBbQ+/OINbClNX+Aivb12puQZ3w43HT8FhfqpEmeXCQYe4SvuYqFNWS6UXyykWkUWdRLH rekrIBEeIdxiksGuru78+c3KUQfDn6N4bDaA/ylotC24/Ldpm6EVzwR4Zf0+HNyFLnMBnz1T3QAA AAAAAA== --Apple-Mail=_1C9AFE5A-504E-4D6D-979A-3F257C5C8106-- From phil.hunt@oracle.com Thu May 30 08:52:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6595621F939E for ; Thu, 30 May 2013 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, MANGLED_CREDIT=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+a+VLS1rzgT for ; Thu, 30 May 2013 08:52:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99D21F93E6 for ; Thu, 30 May 2013 08:52:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UFqhw4029155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 15:52:44 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UFqiHa029147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 15:52:44 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UFqhdA001072; Thu, 30 May 2013 15:52:43 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 08:52:43 -0700 References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 30 May 2013 08:52:28 -0700 To: John Bradley X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 15:52:57 -0000 No different issue. I was concerned about the initial client assertion being= passed in as authen cred. It is a signed set of client reg metadata.=20 See we are confused. Hence my worry. :-) Phil On 2013-05-30, at 8:48, John Bradley wrote: > I think Phil also had some processing reason why a Token endpoint or RS wo= uldn't want to tale the authentication as a header, as the processing was ea= sier with them as parameters as they are potentially available to different p= arts of the stack. That may have been mostly around RS, but the principal m= ay apply to the token endpoint as well. >=20 > On 2013-05-30, at 10:21 AM, Justin Richer wrote: >=20 >>>>>=20 >>>>> "client_secret_post vs client_secret_basic" >>>>> BASIC and POST are essentially the same just different ways to send th= e client secret. If an authorization server supports both, both should work f= or any client. So are both methods treated differently? >>>> I agree, and this was one of my original arguments for making this fiel= d plural (or plural-able), but there hasn't been WG support for that so far.= >>>=20 >>> I'm not arguing to make it plural. I think the authentication method is j= ust "client_secret". >>=20 >> That was also an option that was brought up, but in the OIDC WG the count= er-argument was (as I recall) that the two are syntactically separate and th= ere's a desire to restrict to a single type, such as disabling client_secret= _post. Basically, to make it unambiguous. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Thu May 30 09:01:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7231A21F9600 for ; Thu, 30 May 2013 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXGYwlsWb7KI for ; Thu, 30 May 2013 09:00:52 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) by ietfa.amsl.com (Postfix) with ESMTP id DEEFD21F95F9 for ; Thu, 30 May 2013 09:00:25 -0700 (PDT) Received: from mtaout-da04.r1000.mx.aol.com (mtaout-da04.r1000.mx.aol.com [172.29.51.132]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id F0DE17005F6A4; Thu, 30 May 2013 12:00:13 -0400 (EDT) Received: from ping-audit-10-181-176-212-20120320.ops.aol.com (ping-audit-10-181-176-212-20120320.ops.aol.com [10.181.176.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 99AB4E00009A; Thu, 30 May 2013 12:00:13 -0400 (EDT) Message-ID: <51A7778B.3020001@aol.com> Date: Thu, 30 May 2013 12:00:11 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> In-Reply-To: <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> Content-Type: multipart/alternative; boundary="------------000309090505050105070101" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1369929613; bh=BiamPiwBzJvZYcwQLH+cfbIniphtMb9D1+tPJA8iGr4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=v1xW/9DTr+xNwiZYLhJTVTk1UOLIIVUoItdmoxBBkyODh5YCUZfhxMLzGDjE+BqSM P0wpFZdn/vqSZGvjEa96WLLqlY5g5WOgQwPwRz8eoPNF+4s5iAjIv9VCoQuH9m5pyM KacxGOLg3TTR4xFoxepiLcwFqBRIUMPiIcz9J0J0= X-AOL-SCOLL-SCORE: 0:2:460808672:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338451a7778c3cef X-AOL-IP: 10.181.176.212 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:01:04 -0000 This is a multi-part message in MIME format. --------------000309090505050105070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I still "argue" that the initial client access token (not assertion) is really just an authorization token for the endpoint (like any other OAuth2 protected resource). There is nothing within OAuth2 that precludes a system using structured authorization tokens that contain claims and using that claim data as factors in an authorization policy. Whether a token is structured or opaque doesn't change it's use as an authorization token. Even in traditional OAuth2 deployments, most opaque tokens identify the client to which the token was given. So I don't see this initial client access token as an authentication token but rather an authorization token. Maybe that few of "authentication token" vs "authorization token" is where there is confusion? Thanks, George On 5/30/13 11:52 AM, Phil Hunt wrote: > No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. > > See we are confused. Hence my worry. :-) > > Phil > > On 2013-05-30, at 8:48, John Bradley wrote: > >> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack. That may have been mostly around RS, but the principal may apply to the token endpoint as well. >> >> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >> >>>>>> "client_secret_post vs client_secret_basic" >>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? >>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. >>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret". >>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------000309090505050105070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I still "argue" that the initial client access token (not assertion) is really just an authorization token for the endpoint (like any other OAuth2 protected resource). There is nothing within OAuth2 that precludes a system using structured authorization tokens that contain claims and using that claim data as factors in an authorization policy. Whether a token is structured or opaque doesn't change it's use as an authorization token. Even in traditional OAuth2 deployments, most opaque tokens identify the client to which the token was given. So I don't see this initial client access token as an authentication token but rather an authorization token.

Maybe that few of "authentication token" vs "authorization token" is where there is confusion?

Thanks,
George

On 5/30/13 11:52 AM, Phil Hunt wrote:
No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:


I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:


"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?

I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.

I'm not arguing to make it plural. I think the authentication method is just "client_secret".

That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.

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

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


--------------000309090505050105070101-- From phil.hunt@oracle.com Thu May 30 09:04:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD321F8FBE for ; Thu, 30 May 2013 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.114 X-Spam-Level: X-Spam-Status: No, score=-4.114 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, MANGLED_CREDIT=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCIX+i0v2Awe for ; Thu, 30 May 2013 09:03:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9521F929F for ; Thu, 30 May 2013 09:03:16 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UG2xsw003795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 16:03:00 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UG2wg2000860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 16:02:59 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UG2wdK028722; Thu, 30 May 2013 16:02:58 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 09:02:58 -0700 References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 30 May 2013 09:02:58 -0700 To: John Bradley X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:04:01 -0000 Seriously. The new dyn reg draft introduces two new tokens. The initial reg t= oken and the registration access token.=20 As for the latter, the reg access token, my understanding is it has nothing t= o do with an access token. It is issued *after* registration to allow reg up= dates. Right? I know some are confused about this.=20 Phil On 2013-05-30, at 8:52, Phil Hunt wrote: > No different issue. I was concerned about the initial client assertion bei= ng passed in as authen cred. It is a signed set of client reg metadata.=20 >=20 > See we are confused. Hence my worry. :-) >=20 > Phil >=20 > On 2013-05-30, at 8:48, John Bradley wrote: >=20 >> I think Phil also had some processing reason why a Token endpoint or RS w= ouldn't want to tale the authentication as a header, as the processing was e= asier with them as parameters as they are potentially available to different= parts of the stack. That may have been mostly around RS, but the principa= l may apply to the token endpoint as well. >>=20 >> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>=20 >>>>>>=20 >>>>>> "client_secret_post vs client_secret_basic" >>>>>> BASIC and POST are essentially the same just different ways to send t= he client secret. If an authorization server supports both, both should work= for any client. So are both methods treated differently? >>>>> I agree, and this was one of my original arguments for making this fie= ld plural (or plural-able), but there hasn't been WG support for that so far= . >>>>=20 >>>> I'm not arguing to make it plural. I think the authentication method is= just "client_secret". >>>=20 >>> That was also an option that was brought up, but in the OIDC WG the coun= ter-argument was (as I recall) that the two are syntactically separate and t= here's a desire to restrict to a single type, such as disabling client_secre= t_post. Basically, to make it unambiguous. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Thu May 30 09:08:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE56521F93FC for ; Thu, 30 May 2013 09:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, MANGLED_CREDIT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbRCoO6ibuAE for ; Thu, 30 May 2013 09:08:39 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB021F96DB for ; Thu, 30 May 2013 09:08:39 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ci6so374169qab.16 for ; Thu, 30 May 2013 09:08:38 -0700 (PDT) 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=NO4pA9NRTkRFYgex+8uY20b8NFqxcVbLy2bamqGahtY=; b=iNUHQkdm/5c/jCib6AXHw0cW9BA4HtTNiz1ka78dClMSWHZcl4wbDC9VDR9eMrPRN/ EneX6e+AHjz0A59KBiWdMp7GZ50FJiwwCoKUcPwhj6RvOq+lpU+nr8HTXolCkbr80fxZ lbyXYJDSJ8lMStcSArUmkUhRpBVf5C1crza+jRlmvOcOJDqJId6hlKGFOTemT1c1kbTD VCM5/7o0m0CqYpKt0iti9NzphvgE62wDfBfAiXeiU+PNC4VAinA02nfwpBSN1SM3iA2F cpr5GW5lU5RLnJoju0PdKc/5fF+lET0X1E1h0CXIACjWY/VBdUn5os7sIh5c95phAoTP 6MvA== X-Received: by 10.224.201.198 with SMTP id fb6mr7027751qab.68.1369930118662; Thu, 30 May 2013 09:08:38 -0700 (PDT) Received: from [192.168.1.36] (190-20-30-2.baf.movistar.cl. [190.20.30.2]) by mx.google.com with ESMTPSA id y1sm37357538qad.5.2013.05.30.09.08.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 09:08:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FAB5E552-4506-4214-B8B6-2FF21CBC1051"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> Date: Thu, 30 May 2013 12:08:32 -0400 Message-Id: <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm9anH5b2NrmC9ZYw9Oa1Do/BJR4Sk1a4zMTjKEu/xCqU+4QQ0HubxEYdh6pfkqaTanltwQ Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:08:40 -0000 --Apple-Mail=_FAB5E552-4506-4214-B8B6-2FF21CBC1051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The initial access token is a OAuth bearer Access token (Authz). Like = any bearer token it can be structured or not. Your concern is I think = around some work BB+ has done to profile a structured token for this = particular RS use. That is out of scope for the core of dynamic = registration, as it is out of scope for OAuth core. So http basic vs parameters makes no difference to you. The assertion = profile only uses POST parameters for the assertion rather than headers = so that should not be an issue for that authentication method. John B. On 2013-05-30, at 11:52 AM, Phil Hunt wrote: > No different issue. I was concerned about the initial client assertion = being passed in as authen cred. It is a signed set of client reg = metadata.=20 >=20 > See we are confused. Hence my worry. :-) >=20 > Phil >=20 > On 2013-05-30, at 8:48, John Bradley wrote: >=20 >> I think Phil also had some processing reason why a Token endpoint or = RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>=20 >> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>=20 >>>>>>=20 >>>>>> "client_secret_post vs client_secret_basic" >>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>> I agree, and this was one of my original arguments for making this = field plural (or plural-able), but there hasn't been WG support for that = so far. >>>>=20 >>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>=20 >>> That was also an option that was brought up, but in the OIDC WG the = counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FAB5E552-4506-4214-B8B6-2FF21CBC1051 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTYwODMzWjAjBgkqhkiG9w0BCQQxFgQUodWdaejn 3JfyzUOykXGahbydA3IwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAh/YdjffDKicovXB9t8B5AXnC9bw/+F/3RE59wmfX DNOkBE4dBXWAFuSfqS9O5H7KopRIm5cRQ8b6YjyUd8fmrds+ntnii+yTt3F6Go8M4ELhqI7TPoSd TO0J7mQdEL3RP2VW9QtzEjtgbxP0SNoom0FE9B86PzcA65thKn65V/yK6/7IWp/sdxTQ+KspZRUp WzF6NJ9HaGVTHP0EKX9lEtOPsHQwygSWsNsHiHUWbM8qWpK3iLlY0R2vEnJ7OghBUgHopyw4DZXC eBuBaDcV9IwSOiFdXkqvAEsf+R8/YpP/t90FkKbntvgRrWMWz7kODu4tUjZauOUgXINh8yar7AAA AAAAAA== --Apple-Mail=_FAB5E552-4506-4214-B8B6-2FF21CBC1051-- From jricher@mitre.org Thu May 30 09:24:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3021F9766 for ; Thu, 30 May 2013 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.315 X-Spam-Level: X-Spam-Status: No, score=-5.315 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkzbtKk8+KSj for ; Thu, 30 May 2013 09:24:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED6CC21F91B2 for ; Thu, 30 May 2013 09:24:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7491922600CB; Thu, 30 May 2013 12:24:40 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5D880226005B; Thu, 30 May 2013 12:24:40 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 12:24:40 -0400 Message-ID: <51A77D1F.4070707@mitre.org> Date: Thu, 30 May 2013 12:23:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> In-Reply-To: <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:24:53 -0000 These were not introduced in the new draft, they were just explained better. The Client Registration Endpoint has been (optionally) OAuth protected all along. The Initial Registration Token is an authorization token (not authentication) used to access that protected resource. The Client Configuration Endpoint has been fully OAuth protected all along. The Registration Access Token is (and has been) an authorization token (not authentication) that is used to access that protected resource. The fact that extensions and profiles of the DynReg spec are also doing other things with it in addition to the authorization is completely out of scope for the base. -- Justin On 05/30/2013 12:02 PM, Phil Hunt wrote: > Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. > > As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates. Right? I know some are confused about this. > > Phil > > On 2013-05-30, at 8:52, Phil Hunt wrote: > >> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. >> >> See we are confused. Hence my worry. :-) >> >> Phil >> >> On 2013-05-30, at 8:48, John Bradley wrote: >> >>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack. That may have been mostly around RS, but the principal may apply to the token endpoint as well. >>> >>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>> >>>>>>> "client_secret_post vs client_secret_basic" >>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? >>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. >>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret". >>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. >>> _______________________________________________ >>> OAuth mailing 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 phil.hunt@oracle.com Thu May 30 09:37:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7F21F9051 for ; Thu, 30 May 2013 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GlNADhhf0dQ for ; Thu, 30 May 2013 09:37:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF0EC21F901B for ; Thu, 30 May 2013 09:37:01 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UGaxwY010880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 16:37:00 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UGawCq009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 16:36:59 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UGaw5d009147; Thu, 30 May 2013 16:36:58 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 09:36:58 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> Date: Thu, 30 May 2013 09:36:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:37:07 -0000 In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an = access token to an anonymous client to begin the registration process = (just not sure the value of it). I'm not ok with what is happening in 1.4.2 (Protected Registration).=20 I think we should make it clear that it is for Protected *Local* = Registration. In this case it makes sense that the local OOB = registration process could reasonably issue a local access token. A new option (1.4.3), Protected 3rd Party Registration would proceed = differently (the BB+ case)=85. It opens the door for a scenarios such as where a certifying entity, = e.g. the publisher of a REST API issues the developer a client = application assertion that includes some defined application metadata. = We should specify what claims are typically present and what is = minimally required. Because this assertion is not an AuthN statement (technically), my = preference is that this assertion then be presented as the software_id = because it is identifying the software and represents assertions about = client metadata. =20 IMPORTANT: By NOT presenting the 3rd party assertion as the initial = access token, it is possible for an administrator to then take that = assertion and locally register the application --> converting the client = application registration to a 1.4.2 local registration. The client = would still present the 3rd party assertion as the software_id AND the = initial access token from the manual registration. OR,=20 The client registers *anonymously* but presents the signed 3rd party = assertion in software_id. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-30, at 9:08 AM, John Bradley wrote: > The initial access token is a OAuth bearer Access token (Authz). = Like any bearer token it can be structured or not. Your concern is I = think around some work BB+ has done to profile a structured token for = this particular RS use. That is out of scope for the core of dynamic = registration, as it is out of scope for OAuth core. >=20 > So http basic vs parameters makes no difference to you. The assertion = profile only uses POST parameters for the assertion rather than headers = so that should not be an issue for that authentication method. >=20 > John B. >=20 > On 2013-05-30, at 11:52 AM, Phil Hunt wrote: >=20 >> No different issue. I was concerned about the initial client = assertion being passed in as authen cred. It is a signed set of client = reg metadata.=20 >>=20 >> See we are confused. Hence my worry. :-) >>=20 >> Phil >>=20 >> On 2013-05-30, at 8:48, John Bradley wrote: >>=20 >>> I think Phil also had some processing reason why a Token endpoint or = RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>>=20 >>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>=20 >>>>>>>=20 >>>>>>> "client_secret_post vs client_secret_basic" >>>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>>> I agree, and this was one of my original arguments for making = this field plural (or plural-able), but there hasn't been WG support for = that so far. >>>>>=20 >>>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>>=20 >>>> That was also an option that was brought up, but in the OIDC WG the = counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Thu May 30 09:43:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF921F972C for ; Thu, 30 May 2013 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv-ppjD78XZH for ; Thu, 30 May 2013 09:43:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA221F96FD for ; Thu, 30 May 2013 09:43:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3B711F02A2; Thu, 30 May 2013 12:43:35 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE6221F00DC; Thu, 30 May 2013 12:43:35 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 12:43:35 -0400 Message-ID: <51A7818F.1090004@mitre.org> Date: Thu, 30 May 2013 12:42:55 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com> In-Reply-To: <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 16:43:41 -0000 But OAuth says nothing about whether tokens are "local" or "3rd party", and this spec inherits that definition. The AS is free to do whatever it wants with the token. You can already do both scenarios that you're talking about below with the existing functionality (in a way that makes sense), so I just don't see the value in adding another parameter to handle that case. Yes, some registration endpoint implementations won't be able to handle external assertions as their OAuth tokens and won't have access to them at the right levels. But, that's already true for other kinds of protected resource, isn't it? As far as DynReg is concerned, I want it to just stay an OAuth protected resource. What you do with it beyond that (like what we're doing in BB+) is of no concern to the base spec. As I've said before, I'm not opposed to adding a very strictly defined, optional software_id field (if others agree), but I'm not OK with defining assertion semantics there. I'm also not OK with defining assertion semantics in the Initial Registration Token. Both of these are too implementation specific, and from the client/developer's perspective these tokens ought to remain opaque, like OAuth tokens always are. -- Justin On 05/30/2013 12:36 PM, Phil Hunt wrote: > In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access token to an anonymous client to begin the registration process (just not sure the value of it). > > I'm not ok with what is happening in 1.4.2 (Protected Registration). > > I think we should make it clear that it is for Protected *Local* Registration. In this case it makes sense that the local OOB registration process could reasonably issue a local access token. > > A new option (1.4.3), Protected 3rd Party Registration would proceed differently (the BB+ case). > > It opens the door for a scenarios such as where a certifying entity, e.g. the publisher of a REST API issues the developer a client application assertion that includes some defined application metadata. We should specify what claims are typically present and what is minimally required. > > Because this assertion is not an AuthN statement (technically), my preference is that this assertion then be presented as the software_id because it is identifying the software and represents assertions about client metadata. > > IMPORTANT: By NOT presenting the 3rd party assertion as the initial access token, it is possible for an administrator to then take that assertion and locally register the application --> converting the client application registration to a 1.4.2 local registration. The client would still present the 3rd party assertion as the software_id AND the initial access token from the manual registration. > > OR, > > The client registers *anonymously* but presents the signed 3rd party assertion in software_id. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-30, at 9:08 AM, John Bradley wrote: > >> The initial access token is a OAuth bearer Access token (Authz). Like any bearer token it can be structured or not. Your concern is I think around some work BB+ has done to profile a structured token for this particular RS use. That is out of scope for the core of dynamic registration, as it is out of scope for OAuth core. >> >> So http basic vs parameters makes no difference to you. The assertion profile only uses POST parameters for the assertion rather than headers so that should not be an issue for that authentication method. >> >> John B. >> >> On 2013-05-30, at 11:52 AM, Phil Hunt wrote: >> >>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. >>> >>> See we are confused. Hence my worry. :-) >>> >>> Phil >>> >>> On 2013-05-30, at 8:48, John Bradley wrote: >>> >>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack. That may have been mostly around RS, but the principal may apply to the token endpoint as well. >>>> >>>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>> >>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? >>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. >>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret". >>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Thu May 30 10:00:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843D21F937B for ; Thu, 30 May 2013 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.525 X-Spam-Level: X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TaUz3SKo0Dh for ; Thu, 30 May 2013 10:00:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF821F9349 for ; Thu, 30 May 2013 10:00:51 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UH0h56004295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 17:00:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UH0gsJ019202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 17:00:43 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UH0gvO020137; Thu, 30 May 2013 17:00:42 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 10:00:42 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <51A7818F.1090004@mitre.org> Date: Thu, 30 May 2013 10:00:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com> <51A7818F.1090004@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 17:00:56 -0000 Justin, You are right, 6750 does not define "local" or "3rd party". But the use = cases we are talking about are clearly very very different. You are blurring the distinction between access tokens and bearer = assertions such as defined by draft-ietf-oauth-saml2-bearer and = draft-ietf-oauth-jwt-bearer. =20 In the BB+ case, the assertion you are passing fits none of the 3 above. = It isn't a local access token (of some unspecified format), and it = isn't a JWT or SAML Bearer assertion. Saying the AS is free to do whatever it wants undermines the value of = having a standard. I propose to keep these concepts separated and clearly defined. The proposal I have outlined below allows for a piece of software (with = a signed set of metadata) to be approved by an admin and a locally = issued access token to be issued so that separate client instances can = be registered with the locally issued access token. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-30, at 9:42 AM, Justin Richer wrote: > But OAuth says nothing about whether tokens are "local" or "3rd = party", and this spec inherits that definition. The AS is free to do = whatever it wants with the token. You can already do both scenarios that = you're talking about below with the existing functionality (in a way = that makes sense), so I just don't see the value in adding another = parameter to handle that case. >=20 > Yes, some registration endpoint implementations won't be able to = handle external assertions as their OAuth tokens and won't have access = to them at the right levels. But, that's already true for other kinds of = protected resource, isn't it? As far as DynReg is concerned, I want it = to just stay an OAuth protected resource. What you do with it beyond = that (like what we're doing in BB+) is of no concern to the base spec. >=20 > As I've said before, I'm not opposed to adding a very strictly = defined, optional software_id field (if others agree), but I'm not OK = with defining assertion semantics there. I'm also not OK with defining = assertion semantics in the Initial Registration Token. Both of these are = too implementation specific, and from the client/developer's perspective = these tokens ought to remain opaque, like OAuth tokens always are. >=20 > -- Justin >=20 > On 05/30/2013 12:36 PM, Phil Hunt wrote: >> In 1.4.1 - I'm ok with this use of having the AS token endpoint issue = an access token to an anonymous client to begin the registration process = (just not sure the value of it). >>=20 >> I'm not ok with what is happening in 1.4.2 (Protected Registration). >>=20 >> I think we should make it clear that it is for Protected *Local* = Registration. In this case it makes sense that the local OOB = registration process could reasonably issue a local access token. >>=20 >> A new option (1.4.3), Protected 3rd Party Registration would proceed = differently (the BB+ case)=85. >>=20 >> It opens the door for a scenarios such as where a certifying entity, = e.g. the publisher of a REST API issues the developer a client = application assertion that includes some defined application metadata. = We should specify what claims are typically present and what is = minimally required. >>=20 >> Because this assertion is not an AuthN statement (technically), my = preference is that this assertion then be presented as the software_id = because it is identifying the software and represents assertions about = client metadata. >>=20 >> IMPORTANT: By NOT presenting the 3rd party assertion as the initial = access token, it is possible for an administrator to then take that = assertion and locally register the application --> converting the client = application registration to a 1.4.2 local registration. The client = would still present the 3rd party assertion as the software_id AND the = initial access token from the manual registration. >>=20 >> OR, >>=20 >> The client registers *anonymously* but presents the signed 3rd party = assertion in software_id. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-30, at 9:08 AM, John Bradley wrote: >>=20 >>> The initial access token is a OAuth bearer Access token (Authz). = Like any bearer token it can be structured or not. Your concern is I = think around some work BB+ has done to profile a structured token for = this particular RS use. That is out of scope for the core of dynamic = registration, as it is out of scope for OAuth core. >>>=20 >>> So http basic vs parameters makes no difference to you. The = assertion profile only uses POST parameters for the assertion rather = than headers so that should not be an issue for that authentication = method. >>>=20 >>> John B. >>>=20 >>> On 2013-05-30, at 11:52 AM, Phil Hunt wrote: >>>=20 >>>> No different issue. I was concerned about the initial client = assertion being passed in as authen cred. It is a signed set of client = reg metadata. >>>>=20 >>>> See we are confused. Hence my worry. :-) >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-05-30, at 8:48, John Bradley wrote: >>>>=20 >>>>> I think Phil also had some processing reason why a Token endpoint = or RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>>>>=20 >>>>> On 2013-05-30, at 10:21 AM, Justin Richer = wrote: >>>>>=20 >>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>>>>> I agree, and this was one of my original arguments for making = this field plural (or plural-able), but there hasn't been WG support for = that so far. >>>>>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>>>> That was also an option that was brought up, but in the OIDC WG = the counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Thu May 30 10:08:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06A21F93A3 for ; Thu, 30 May 2013 10:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, MANGLED_CREDIT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7Cl2vUzPGWR for ; Thu, 30 May 2013 10:08:42 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id F356621F93E8 for ; Thu, 30 May 2013 10:08:38 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u11so263266qcx.12 for ; Thu, 30 May 2013 10:08:38 -0700 (PDT) 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=8rxeH9/GsKxfXWRoUMGdOQSB+Mo+God8e2hTDp4zkNw=; b=OEdUyuV1CHasGl0aeNmFCk1DYTYIAlacOfKp0IDV1gjDTJzdEWq/02N8rZ4/h9TV4O cfg02swcZKMkvUsrwf7ItdZZORtWV9Z4MW1Kq6pTKvl1T2F0X5ifBMPJlG3drw5onkcO DcmN/RntYfGzuYrcHXxgLnqP2Zr90Me7TFJWg6F4d9fz5PGYyvSJIAyBEpXUJs8Nnxo3 MFRO/xpkjo/dg/Gzqm3Qz4J7k1I7y9lAFg1K4o9n31smADLwjjaXzzzLrAYYGETruQER +W2q/APTTrVlqMPgQlobNkyGDiJZ2+R1nXbqFLhLLtcIE07yIGCVX0V9pDvANoOrR7db /ZDg== X-Received: by 10.229.177.10 with SMTP id bg10mr2611249qcb.135.1369933718279; Thu, 30 May 2013 10:08:38 -0700 (PDT) Received: from [192.168.1.36] (190-20-30-2.baf.movistar.cl. [190.20.30.2]) by mx.google.com with ESMTPSA id j2sm18839990qer.1.2013.05.30.10.08.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 10:08:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8CEA4A16-FAD4-4C6E-9941-FF75C3DB189C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> Date: Thu, 30 May 2013 13:08:04 -0400 Message-Id: <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn7P9oDbZTFq66tLQaxda6u4XPds3M+3oew9u4z0ps2TcKNSKqbGiqZrq/U8VazYUdP1EMQ Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 17:08:43 -0000 --Apple-Mail=_8CEA4A16-FAD4-4C6E-9941-FF75C3DB189C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The reg access token is a OAuth bearer token that is issued as part of = the registration response and used to access the new client resource for = reads and or updates depending on the permissions. They are both oauth access tokens. On 2013-05-30, at 12:02 PM, Phil Hunt wrote: > Seriously. The new dyn reg draft introduces two new tokens. The = initial reg token and the registration access token.=20 >=20 > As for the latter, the reg access token, my understanding is it has = nothing to do with an access token. It is issued *after* registration to = allow reg updates. Right? I know some are confused about this.=20 >=20 > Phil >=20 > On 2013-05-30, at 8:52, Phil Hunt wrote: >=20 >> No different issue. I was concerned about the initial client = assertion being passed in as authen cred. It is a signed set of client = reg metadata.=20 >>=20 >> See we are confused. Hence my worry. :-) >>=20 >> Phil >>=20 >> On 2013-05-30, at 8:48, John Bradley wrote: >>=20 >>> I think Phil also had some processing reason why a Token endpoint or = RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>>=20 >>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>=20 >>>>>>>=20 >>>>>>> "client_secret_post vs client_secret_basic" >>>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>>> I agree, and this was one of my original arguments for making = this field plural (or plural-able), but there hasn't been WG support for = that so far. >>>>>=20 >>>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>>=20 >>>> That was also an option that was brought up, but in the OIDC WG the = counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8CEA4A16-FAD4-4C6E-9941-FF75C3DB189C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTcwODA0WjAjBgkqhkiG9w0BCQQxFgQUniicK57l GY90gPTZdDMZA0nbxZIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAMieUv/sJcIBNJDzLv7MtX5jmg11hZwHUcSHnD3qw fZ2NcA+4YfsfzBAoHzn+KNF+bLD1Xr3mdjGWzMK+5aftj0EJdnWzJtpaOWA98/8ue2XVkSdIzqq/ uuI9uPini69eZU2no1MIcR5mTzvKofK4Up5HRi5D8y52wixlZzZMcGiiKBxcelUf/nEvhcJYntHw dWG13qtthnoz3Yn/dBrNP4B4POF/xlasokipXRhLGv4Hp3Vd8Jsk/PfuRhLJNfgvXm3SbB/G17vv mnI0PQdC76qaE5XoZEEQefz4oHVAaXGvWj55Dk+efR4HD+G3QkPXZ5TEO6sKdppcvda+W71w/wAA AAAAAA== --Apple-Mail=_8CEA4A16-FAD4-4C6E-9941-FF75C3DB189C-- From jricher@mitre.org Thu May 30 10:11:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1221F93A3 for ; Thu, 30 May 2013 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.13 X-Spam-Level: X-Spam-Status: No, score=-5.13 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDtzb+kt8dv9 for ; Thu, 30 May 2013 10:10:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EE1E021F93F1 for ; Thu, 30 May 2013 10:10:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A1D31F041F; Thu, 30 May 2013 13:10:53 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 60E581F032D; Thu, 30 May 2013 13:10:53 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 13:10:53 -0400 Message-ID: <51A787F4.4030602@mitre.org> Date: Thu, 30 May 2013 13:10:12 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com> <51A7818F.1090004@mitre.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 17:11:02 -0000 What I don't understand is that the existing structure also allows for exactly that same use case. The difference is where the information is carried. But since we're not locking down where or how that information is specified, your application use case can do it how it makes sense. I fully agree that these things should be defined separately, which is why I want to keep it out of Dyn Reg all together. BB+ is its own application and use case. My use case there is built on top of the existing OAuth use cases. Yours is as well. I think there's absolutely value in defining interoperability both at the common-denominator level (DynReg) and the higher application level (the "other extension spec" that I suggested this be turned in to at the very beginning of this conversation). Would it be good if our two use cases could talk to each other? Probably. But I think it's even *more* important that our two use cases can be built on top of the same foundation. So I am saying: let's finish the foundation with a clear set of semantics that are useful on their own. The utility of the base DynReg spec is well established today. I think there would be value in a separate concrete extension that says things like how to pass signed assertions around -- exactly like we did with OAuth. Its absence from the core of OAuth has in no way diminished OAuth's popularity and usefulness, and I would argue that the flexibility in the right places has actually done much to encourage OAuth's adoption. -- Justin On 05/30/2013 01:00 PM, Phil Hunt wrote: > Justin, > > You are right, 6750 does not define "local" or "3rd party". But the use cases we are talking about are clearly very very different. > > You are blurring the distinction between access tokens and bearer assertions such as defined by draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer. > > In the BB+ case, the assertion you are passing fits none of the 3 above. It isn't a local access token (of some unspecified format), and it isn't a JWT or SAML Bearer assertion. > > Saying the AS is free to do whatever it wants undermines the value of having a standard. > > I propose to keep these concepts separated and clearly defined. > > The proposal I have outlined below allows for a piece of software (with a signed set of metadata) to be approved by an admin and a locally issued access token to be issued so that separate client instances can be registered with the locally issued access token. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-30, at 9:42 AM, Justin Richer wrote: > >> But OAuth says nothing about whether tokens are "local" or "3rd party", and this spec inherits that definition. The AS is free to do whatever it wants with the token. You can already do both scenarios that you're talking about below with the existing functionality (in a way that makes sense), so I just don't see the value in adding another parameter to handle that case. >> >> Yes, some registration endpoint implementations won't be able to handle external assertions as their OAuth tokens and won't have access to them at the right levels. But, that's already true for other kinds of protected resource, isn't it? As far as DynReg is concerned, I want it to just stay an OAuth protected resource. What you do with it beyond that (like what we're doing in BB+) is of no concern to the base spec. >> >> As I've said before, I'm not opposed to adding a very strictly defined, optional software_id field (if others agree), but I'm not OK with defining assertion semantics there. I'm also not OK with defining assertion semantics in the Initial Registration Token. Both of these are too implementation specific, and from the client/developer's perspective these tokens ought to remain opaque, like OAuth tokens always are. >> >> -- Justin >> >> On 05/30/2013 12:36 PM, Phil Hunt wrote: >>> In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access token to an anonymous client to begin the registration process (just not sure the value of it). >>> >>> I'm not ok with what is happening in 1.4.2 (Protected Registration). >>> >>> I think we should make it clear that it is for Protected *Local* Registration. In this case it makes sense that the local OOB registration process could reasonably issue a local access token. >>> >>> A new option (1.4.3), Protected 3rd Party Registration would proceed differently (the BB+ case). >>> >>> It opens the door for a scenarios such as where a certifying entity, e.g. the publisher of a REST API issues the developer a client application assertion that includes some defined application metadata. We should specify what claims are typically present and what is minimally required. >>> >>> Because this assertion is not an AuthN statement (technically), my preference is that this assertion then be presented as the software_id because it is identifying the software and represents assertions about client metadata. >>> >>> IMPORTANT: By NOT presenting the 3rd party assertion as the initial access token, it is possible for an administrator to then take that assertion and locally register the application --> converting the client application registration to a 1.4.2 local registration. The client would still present the 3rd party assertion as the software_id AND the initial access token from the manual registration. >>> >>> OR, >>> >>> The client registers *anonymously* but presents the signed 3rd party assertion in software_id. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-05-30, at 9:08 AM, John Bradley wrote: >>> >>>> The initial access token is a OAuth bearer Access token (Authz). Like any bearer token it can be structured or not. Your concern is I think around some work BB+ has done to profile a structured token for this particular RS use. That is out of scope for the core of dynamic registration, as it is out of scope for OAuth core. >>>> >>>> So http basic vs parameters makes no difference to you. The assertion profile only uses POST parameters for the assertion rather than headers so that should not be an issue for that authentication method. >>>> >>>> John B. >>>> >>>> On 2013-05-30, at 11:52 AM, Phil Hunt wrote: >>>> >>>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. >>>>> >>>>> See we are confused. Hence my worry. :-) >>>>> >>>>> Phil >>>>> >>>>> On 2013-05-30, at 8:48, John Bradley wrote: >>>>> >>>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack. That may have been mostly around RS, but the principal may apply to the token endpoint as well. >>>>>> >>>>>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>>>> >>>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? >>>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. >>>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret". >>>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Thu May 30 10:13:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA121F93EB for ; Thu, 30 May 2013 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwFwnNbDlfTK for ; Thu, 30 May 2013 10:12:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1530D21F94C3 for ; Thu, 30 May 2013 10:12:53 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UHCnCW028433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 17:12:50 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UHCoil020954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 17:12:51 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UHCoKG020948; Thu, 30 May 2013 17:12:50 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 10:12:50 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> Date: Thu, 30 May 2013 10:12:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 17:13:01 -0000 The issue is that it has different issuing/lifecycle than normal. E.g. = Why is it issued by the registration endpoint? Why doesn't the client just request an access token using its client = credential for the registration endpoint when it wants to update its = profile? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-30, at 10:08 AM, John Bradley wrote: > The reg access token is a OAuth bearer token that is issued as part of = the registration response and used to access the new client resource for = reads and or updates depending on the permissions. >=20 > They are both oauth access tokens. >=20 > On 2013-05-30, at 12:02 PM, Phil Hunt wrote: >=20 >> Seriously. The new dyn reg draft introduces two new tokens. The = initial reg token and the registration access token.=20 >>=20 >> As for the latter, the reg access token, my understanding is it has = nothing to do with an access token. It is issued *after* registration to = allow reg updates. Right? I know some are confused about this.=20 >>=20 >> Phil >>=20 >> On 2013-05-30, at 8:52, Phil Hunt wrote: >>=20 >>> No different issue. I was concerned about the initial client = assertion being passed in as authen cred. It is a signed set of client = reg metadata.=20 >>>=20 >>> See we are confused. Hence my worry. :-) >>>=20 >>> Phil >>>=20 >>> On 2013-05-30, at 8:48, John Bradley wrote: >>>=20 >>>> I think Phil also had some processing reason why a Token endpoint = or RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>>>=20 >>>> On 2013-05-30, at 10:21 AM, Justin Richer = wrote: >>>>=20 >>>>>>>>=20 >>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>>>> I agree, and this was one of my original arguments for making = this field plural (or plural-able), but there hasn't been WG support for = that so far. >>>>>>=20 >>>>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>>>=20 >>>>> That was also an option that was brought up, but in the OIDC WG = the counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From phil.hunt@oracle.com Thu May 30 10:55:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4821F9607 for ; Thu, 30 May 2013 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.468 X-Spam-Level: X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRM2xSZ3y1TR for ; Thu, 30 May 2013 10:55:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D687421F946F for ; Thu, 30 May 2013 10:55:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UHtfLo010951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 17:55:42 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UHtgQ2028210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 17:55:42 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UHtgfe028796; Thu, 30 May 2013 17:55:42 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 10:55:42 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> Date: Thu, 30 May 2013 10:55:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 17:55:56 -0000 I see what is happening. I think the reason why I find this spec sooo confusing is that the terms = imply new token types when they don't. For example when you say "Registration Access Token" and "Initial Access = Token" it implies to me that it is a totally new token type (and in one = case it sorta is). When you read the spec (particularly draft 10) it is = easy to assume something very different is going on. Hence my push back. It is now clear to me that what you mean to say is *Access Token used = for initial access* and *Access Token used for registration*. Why not write the draft to make clear that the registration end point is = just a NORMAL OAuth2 Enabled REST endpoint? That way you can eliminate = all of the terminology and lifecycle around access tokens except to say = the endpoint is accessed by tokens issued based on the scope = "oauth2:registration". That only brings issues with the registration token. The "Access Token = used for registration" seems to have special lifecycle differences. 1. Issed by reg endpoint as part of successful registration 2. Has a different lifetime than the client credential (whatever it = is). Why not again simplify and follow normal OAuth2 pattern and have the = access token issued for registration be *short* lived. Each time the = client wants to either initially register or update its profile it must = request a normal access token with scope "oauth2:registration".=20 As for client credential expiry, why not simply require the client to = update its registration before it expires? Why have a long-lived = "registration access token" that has to be managed as well? Maybe now I am completely confused? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-30, at 10:12 AM, Phil Hunt wrote: > The issue is that it has different issuing/lifecycle than normal. E.g. = Why is it issued by the registration endpoint? >=20 > Why doesn't the client just request an access token using its client = credential for the registration endpoint when it wants to update its = profile? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-30, at 10:08 AM, John Bradley wrote: >=20 >> The reg access token is a OAuth bearer token that is issued as part = of the registration response and used to access the new client resource = for reads and or updates depending on the permissions. >>=20 >> They are both oauth access tokens. >>=20 >> On 2013-05-30, at 12:02 PM, Phil Hunt wrote: >>=20 >>> Seriously. The new dyn reg draft introduces two new tokens. The = initial reg token and the registration access token.=20 >>>=20 >>> As for the latter, the reg access token, my understanding is it has = nothing to do with an access token. It is issued *after* registration to = allow reg updates. Right? I know some are confused about this.=20 >>>=20 >>> Phil >>>=20 >>> On 2013-05-30, at 8:52, Phil Hunt wrote: >>>=20 >>>> No different issue. I was concerned about the initial client = assertion being passed in as authen cred. It is a signed set of client = reg metadata.=20 >>>>=20 >>>> See we are confused. Hence my worry. :-) >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-05-30, at 8:48, John Bradley wrote: >>>>=20 >>>>> I think Phil also had some processing reason why a Token endpoint = or RS wouldn't want to tale the authentication as a header, as the = processing was easier with them as parameters as they are potentially = available to different parts of the stack. That may have been mostly = around RS, but the principal may apply to the token endpoint as well. >>>>>=20 >>>>> On 2013-05-30, at 10:21 AM, Justin Richer = wrote: >>>>>=20 >>>>>>>>>=20 >>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>> BASIC and POST are essentially the same just different ways to = send the client secret. If an authorization server supports both, both = should work for any client. So are both methods treated differently? >>>>>>>> I agree, and this was one of my original arguments for making = this field plural (or plural-able), but there hasn't been WG support for = that so far. >>>>>>>=20 >>>>>>> I'm not arguing to make it plural. I think the authentication = method is just "client_secret". >>>>>>=20 >>>>>> That was also an option that was brought up, but in the OIDC WG = the counter-argument was (as I recall) that the two are syntactically = separate and there's a desire to restrict to a single type, such as = disabling client_secret_post. Basically, to make it unambiguous. >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu May 30 11:34:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12C21F9017 for ; Thu, 30 May 2013 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.06 X-Spam-Level: X-Spam-Status: No, score=-5.06 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHjzSm1dUd5m for ; Thu, 30 May 2013 11:33:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA921F8EAD for ; Thu, 30 May 2013 11:33:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C9981F069D; Thu, 30 May 2013 14:33:54 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EF4F31F0688; Thu, 30 May 2013 14:33:53 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 14:33:53 -0400 Message-ID: <51A79B69.9090702@mitre.org> Date: Thu, 30 May 2013 14:33:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> In-Reply-To: <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> Content-Type: multipart/alternative; boundary="------------020009010303000308070408" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 18:34:00 -0000 --------------020009010303000308070408 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thanks for clearing up where the confusion was taking place. I had tried to make it clear that these were absolutely standard, opaque OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, but if that's not clear that needs to be updated. This is what the text says right now: The Client Registration Endpoint MAY accept an Initial Access Token in the form of an OAuth 2.0 [RFC6749] access token to limit registration to only previously authorized parties. The method by which the Initial Access Token is obtained by the registrant is generally out-of-band and is out of scope of this specification. And: The Client Configuration Endpoint is an OAuth 2.0 protected resource that is provisioned by the server for a specific client to be able to view and update its registered information. The location of this endpoint is communicated to the Client through the registration_client_uri member of the Client Information Response [client-info-response]. The Client MUST use its Registration Access Token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750]. Along with the definitions in the introduction: Registration Access Token OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint that is used to authenticate the caller when accessing the Client's registration information at the Client Configuration Endpoint. This Access Token is associated with a particular registered Client. Initial Access Token An OAuth 2.0 Access Token optionally issued by an Authorization Server granting access to its Client Registration Endpoint. I'd welcome any proposed changes to the text to make this clearer. As to the other suggestion, what you're saying is to use the client credentials to get an access token to get the client credentials ... ? I can see the argument for using the oauth client credentials flow, but I think that's far more complicated than an endpoint saying "here's a token, go use it", personally. Besides, not all clients have credentials at the token endpoint, so it's a bit of a non-starter for a large class of clients. -- Justin On 05/30/2013 01:55 PM, Phil Hunt wrote: > I see what is happening. > > I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't. > > For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back. > > It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*. > > Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint? That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration". > > That only brings issues with the registration token. The "Access Token used for registration" seems to have special lifecycle differences. > 1. Issed by reg endpoint as part of successful registration > 2. Has a different lifetime than the client credential (whatever it is). > > Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived. Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". > > As for client credential expiry, why not simply require the client to update its registration before it expires? Why have a long-lived "registration access token" that has to be managed as well? > > Maybe now I am completely confused? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-05-30, at 10:12 AM, Phil Hunt wrote: > >> The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint? >> >> Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2013-05-30, at 10:08 AM, John Bradley wrote: >> >>> The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions. >>> >>> They are both oauth access tokens. >>> >>> On 2013-05-30, at 12:02 PM, Phil Hunt wrote: >>> >>>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. >>>> >>>> As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates. Right? I know some are confused about this. >>>> >>>> Phil >>>> >>>> On 2013-05-30, at 8:52, Phil Hunt wrote: >>>> >>>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. >>>>> >>>>> See we are confused. Hence my worry. :-) >>>>> >>>>> Phil >>>>> >>>>> On 2013-05-30, at 8:48, John Bradley wrote: >>>>> >>>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack. That may have been mostly around RS, but the principal may apply to the token endpoint as well. >>>>>> >>>>>> On 2013-05-30, at 10:21 AM, Justin Richer wrote: >>>>>> >>>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently? >>>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far. >>>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret". >>>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous. >>>>>> _______________________________________________ >>>>>> OAuth mailing 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 --------------020009010303000308070408 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thanks for clearing up where the confusion was taking place. I had tried to make it clear that these were absolutely standard, opaque OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, but if that's not clear that needs to be updated. This is what the text says right now:

The Client Registration Endpoint MAY accept an Initial Access Token in the form of an OAuth 2.0 [RFC6749] access token to limit registration to only previously authorized parties. The method by which the Initial Access Token is obtained by the registrant is generally out-of-band and is out of scope of this specification.

And:

The Client Configuration Endpoint is an OAuth 2.0 protected resource that is provisioned by the server for a specific client to be able to view and update its registered information. The location of this endpoint is communicated to the Client through the registration_client_uri member of the Client Information Response [client-info-response]. The Client MUST use its Registration Access Token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].

Along with the definitions in the introduction:
Registration Access Token
OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint that is used to authenticate the caller when accessing the Client's registration information at the Client Configuration Endpoint. This Access Token is associated with a particular registered Client.
Initial Access Token
An OAuth 2.0 Access Token optionally issued by an Authorization Server granting access to its Client Registration Endpoint.

I'd welcome any proposed changes to the text to make this clearer.

As to the other suggestion, what you're saying is to use the client credentials to get an access token to get the client credentials ... ? I can see the argument for using the oauth client credentials flow, but I think that's far more complicated than an endpoint saying "here's a token, go use it", personally. Besides, not all clients have credentials at the token endpoint, so it's a bit of a non-starter for a large class of clients.

 -- Justin


On 05/30/2013 01:55 PM, Phil Hunt wrote:
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".

That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it is).

Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". 

As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:


The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?

Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:


The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> wrote:


Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. 

As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this. 

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> wrote:


No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:


I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:


"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?

I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.

I'm not arguing to make it plural. I think the authentication method is just "client_secret".

That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.

_______________________________________________
OAuth mailing 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


    

    

  


--------------020009010303000308070408--

From phil.hunt@oracle.com  Thu May 30 11:57:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9160621F8EAF for ; Thu, 30 May 2013 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.449
X-Spam-Level: 
X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWm8faopSH3N for ; Thu, 30 May 2013 11:57:06 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 936E721F8808 for ; Thu, 30 May 2013 11:56:47 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UIufqj012710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 18:56:42 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UIugj7011807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 18:56:43 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UIugNn018026; Thu, 30 May 2013 18:56:42 GMT
Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 11:56:42 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A4220DC0-E124-40F1-9875-FBC4404B8A5B"
From: Phil Hunt 
In-Reply-To: <51A79B69.9090702@mitre.org>
Date: Thu, 30 May 2013 11:56:40 -0700
Message-Id: <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 18:57:11 -0000

--Apple-Mail=_A4220DC0-E124-40F1-9875-FBC4404B8A5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

It's hard to say what the best solution here is regarding clarifications =
until we get clarity on the issue of registration access token.

I don't think using a client credential flow to obtain an access token =
to the registration endpoint is complex. It's the normal flow. =20

I concede that you are looking at it as using Client Credential to get =
an access token to get a new Client Credential. But that's not really =
what is happening in terms of protocol here. =20

If you take the perspective that the client needs to occasionally update =
registration (e.g. because of a pending credential expiry), then it is =
still simple. You use client credential flow to obtain an access token =
to update registration. Then, from the context of the REST API, the =
client credential is just another piece of JSON data.

IOW from the REST perspective, it is the registration endpoint that is =
being updated, not the client credential.  The client credential is just =
data in the perspective of REST.

I think you may be inferring complexity where there really is none.

Phil

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





On 2013-05-30, at 11:33 AM, Justin Richer wrote:

> Thanks for clearing up where the confusion was taking place. I had =
tried to make it clear that these were absolutely standard, opaque =
OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, =
but if that's not clear that needs to be updated. This is what the text =
says right now:
>=20
> The Client Registration Endpoint MAY accept an Initial Access Token in =
the form of an OAuth 2.0 [RFC6749] access token to limit registration to =
only previously authorized parties. The method by which the Initial =
Access Token is obtained by the registrant is generally out-of-band and =
is out of scope of this specification.
>=20
> And:
>=20
> The Client Configuration Endpoint is an OAuth 2.0 protected resource =
that is provisioned by the server for a specific client to be able to =
view and update its registered information. The location of this =
endpoint is communicated to the Client through the =
registration_client_uri member of the Client Information Response =
[client-info-response]. The Client MUST use its Registration Access =
Token in all calls to this endpoint as an OAuth 2.0 Bearer Token =
[RFC6750].
>=20
> Along with the definitions in the introduction:
> Registration Access Token
> OAuth 2.0 Bearer Token issued by the Authorization Server through the =
Client Registration Endpoint that is used to authenticate the caller =
when accessing the Client's registration information at the Client =
Configuration Endpoint. This Access Token is associated with a =
particular registered Client.
> Initial Access Token
> An OAuth 2.0 Access Token optionally issued by an Authorization Server =
granting access to its Client Registration Endpoint.
>=20
> I'd welcome any proposed changes to the text to make this clearer.
>=20
> As to the other suggestion, what you're saying is to use the client =
credentials to get an access token to get the client credentials ... ? I =
can see the argument for using the oauth client credentials flow, but I =
think that's far more complicated than an endpoint saying "here's a =
token, go use it", personally. Besides, not all clients have credentials =
at the token endpoint, so it's a bit of a non-starter for a large class =
of clients.
>=20
>  -- Justin
>=20
>=20
> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>> I see what is happening.
>>=20
>> I think the reason why I find this spec sooo confusing is that the =
terms imply new token types when they don't.
>>=20
>> For example when you say "Registration Access Token" and "Initial =
Access Token" it implies to me that it is a totally new token type (and =
in one case it sorta is). When you read the spec (particularly draft 10) =
it is easy to assume something very different is going on. Hence my push =
back.
>>=20
>> It is now clear to me that what you mean to say is *Access Token used =
for initial access* and *Access Token used for registration*.
>>=20
>> Why not write the draft to make clear that the registration end point =
is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can =
eliminate all of the terminology and lifecycle around access tokens =
except to say the endpoint is accessed by tokens issued based on the =
scope "oauth2:registration".
>>=20
>> That only brings issues with the registration token.  The "Access =
Token used for registration" seems to have special lifecycle =
differences.
>> 1.  Issed by reg endpoint as part of successful registration
>> 2.  Has a different lifetime than the client credential (whatever it =
is).
>>=20
>> Why not again simplify and follow normal OAuth2 pattern and have the =
access token issued for registration be *short* lived.  Each time the =
client wants to either initially register or update its profile it must =
request a normal access token with scope "oauth2:registration".=20
>>=20
>> As for client credential expiry, why not simply require the client to =
update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?
>>=20
>> Maybe now I am completely confused?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>=20
>>> The issue is that it has different issuing/lifecycle than normal. =
E.g. Why is it issued by the registration endpoint?
>>>=20
>>> Why doesn't the client just request an access token using its client =
credential for the registration endpoint when it wants to update its =
profile?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>=20
>>>> The reg access token is a OAuth bearer token that is issued as part =
of the registration response and used to access the new client resource =
for reads and or updates depending on the permissions.
>>>>=20
>>>> They are both oauth access tokens.
>>>>=20
>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  wrote:
>>>>=20
>>>>> Seriously. The new dyn reg draft introduces two new tokens. The =
initial reg token and the registration access token.=20
>>>>>=20
>>>>> As for the latter, the reg access token, my understanding is it =
has nothing to do with an access token. It is issued *after* =
registration to allow reg updates.  Right? I know some are confused =
about this.=20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> On 2013-05-30, at 8:52, Phil Hunt  wrote:
>>>>>=20
>>>>>> No different issue. I was concerned about the initial client =
assertion being passed in as authen cred. It is a signed set of client =
reg metadata.=20
>>>>>>=20
>>>>>> See we are confused. Hence my worry. :-)
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On 2013-05-30, at 8:48, John Bradley  wrote:
>>>>>>=20
>>>>>>> I think Phil also had some processing reason why a Token =
endpoint or RS wouldn't want to tale the authentication as a header, as =
the processing was easier with them as parameters as they are =
potentially available to different parts of the stack.   That may have =
been mostly around RS, but the principal may apply to the token endpoint =
as well.
>>>>>>>=20
>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer  =
wrote:
>>>>>>>=20
>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>> BASIC and POST are essentially the same just different ways =
to send the client secret. If an authorization server supports both, =
both should work for any client. So are both methods treated =
differently?
>>>>>>>>>> I agree, and this was one of my original arguments for making =
this field plural (or plural-able), but there hasn't been WG support for =
that so far.
>>>>>>>>> I'm not arguing to make it plural. I think the authentication =
method is just "client_secret".
>>>>>>>> That was also an option that was brought up, but in the OIDC WG =
the counter-argument was (as I recall) that the two are syntactically =
separate and there's a desire to restrict to a single type, such as =
disabling client_secret_post. Basically, to make it unambiguous.
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing 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


--Apple-Mail=_A4220DC0-E124-40F1-9875-FBC4404B8A5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

It's =
hard to say what the best solution here is regarding clarifications =
until we get clarity on the issue of registration access =
token.

I don't think using a client credential flow =
to obtain an access token to the registration endpoint is complex. It's =
the normal flow.  

I concede that you are =
looking at it as using Client Credential to get an access token to get a =
new Client Credential. But that's not really what is happening in terms =
of protocol here.  

If you take the =
perspective that the client needs to occasionally update registration =
(e.g. because of a pending credential expiry), then it is still simple. =
You use client credential flow to obtain an access token to update =
registration. Then, from the context of the REST API, the client =
credential is just another piece of JSON =
data.

IOW from the REST perspective, it is the =
registration endpoint that is being updated, not the client credential. =
 The client credential is just data in the perspective of =
REST.

I think you may be inferring complexity =
where there really is none.



Phil

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








On 2013-05-30, at 11:33 AM, Justin Richer wrote:


 =20
    
 =20
  

    Thanks for clearing up where the confusion was taking place. I had
    tried to make it clear that these were absolutely standard, opaque
    OAuth2 bearer tokens and absolutely standard OAuth2-protected
    endpoints, but if that's not clear that needs to be updated. This is
    what the text says right now:

    

    
The Client Registration Endpoint MAY accept an Initial
      Access Token in the form of an OAuth
        2.0  [RFC6749] access token to
      limit registration to only previously authorized parties. The
      method by which the Initial Access Token is obtained by the
      registrant is generally out-of-band and is out of scope of this
      specification.

    

    

    And:

    

    
The Client Configuration Endpoint is an OAuth 2.0
      protected resource that is provisioned by the server for a
      specific client to be able to view and update its registered
      information. The location of this endpoint is communicated to the
      Client through the registration_client_uri member of
      the Client
        Information Response [client-info-response].
      The Client MUST use its Registration Access Token in all calls to
      this endpoint as an OAuth
        2.0 Bearer Token [RFC6750].

    

    

    Along with the definitions in the introduction:

    

      

        
Registration Access Token

        
OAuth 2.0 Bearer Token issued by =
the
          Authorization Server through the Client Registration Endpoint
          that is used to authenticate the caller when accessing the
          Client's registration information at the Client Configuration
          Endpoint. This Access Token is associated with a particular
          registered Client.

        
Initial Access Token

        
An OAuth 2.0 Access Token =
optionally
          issued by an Authorization Server granting access to its
          Client Registration Endpoint.

      

    

    

    I'd welcome any proposed changes to the text to make this =
clearer.

    

    As to the other suggestion, what you're saying is to use the client
    credentials to get an access token to get the client credentials ...
    ? I can see the argument for using the oauth client credentials
    flow, but I think that's far more complicated than an endpoint
    saying "here's a token, go use it", personally. Besides, not all
    clients have credentials at the token endpoint, so it's a bit of a
    non-starter for a large class of clients.

    

     -- Justin

    

    

    
On 05/30/2013 01:55 PM, Phil Hunt
      wrote:

    

    

      
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms =
imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access =
Token" it implies to me that it is a totally new token type (and in one =
case it sorta is). When you read the spec (particularly draft 10) it is =
easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used =
for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is =
just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate =
all of the terminology and lifecycle around access tokens except to say =
the endpoint is accessed by tokens issued based on the scope =
"oauth2:registration".

That only brings issues with the registration token.  The "Access Token =
used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it =
is).

Why not again simplify and follow normal OAuth2 pattern and have the =
access token issued for registration be *short* lived.  Each time the =
client wants to either initially register or update its profile it must =
request a normal access token with scope "oauth2:registration".=20

As for client credential expiry, why not simply require the client to =
update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



      

        
The issue is that it has different =
issuing/lifecycle than normal. E.g. Why is it issued by the registration =
endpoint?

Why doesn't the client just request an access token using its client =
credential for the registration endpoint when it wants to update its =
profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



        

          
The reg access token is a OAuth bearer token =
that is issued as part of the registration response and used to access =
the new client resource for reads and or updates depending on the =
permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:



          

            
Seriously. The new dyn reg draft introduces =
two new tokens. The initial reg token and the registration access token.=20=


As for the latter, the reg access token, my understanding is it has =
nothing to do with an access token. It is issued *after* registration to =
allow reg updates.  Right? I know some are confused about this.=20

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> =
wrote:



            

              
No different issue. I was concerned about =
the initial client assertion being passed in as authen cred. It is a =
signed set of client reg metadata.=20

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



              

                
I think Phil also had some processing =
reason why a Token endpoint or RS wouldn't want to tale the =
authentication as a header, as the processing was easier with them as =
parameters as they are potentially available to different parts of the =
stack.   That may have been mostly around RS, but the principal may =
apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                

                  

                    

                      

                        
"client_secret_post vs =
client_secret_basic"
BASIC and POST are essentially the same just different ways to send the =
client secret. If an authorization server supports both, both should =
work for any client. So are both methods treated differently?


                      

                      
I agree, and this was one of my =
original arguments for making this field plural (or plural-able), but =
there hasn't been WG support for that so far.


                    

                    
I'm not arguing to make it plural. I =
think the authentication method is just "client_secret".


                  

                  
That was also an option that was =
brought up, but in the OIDC WG the counter-argument was (as I recall) =
that the two are syntactically separate and there's a desire to restrict =
to a single type, such as disabling client_secret_post. Basically, to =
make it unambiguous.


                

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


              

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


            

          

          

        

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


      

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


    

    

  




=

--Apple-Mail=_A4220DC0-E124-40F1-9875-FBC4404B8A5B--

From jricher@mitre.org  Thu May 30 12:00:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719CE21F9457 for ; Thu, 30 May 2013 12:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level: 
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64HSEBMsMoWL for ; Thu, 30 May 2013 12:00:09 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CFA1A21F939E for ; Thu, 30 May 2013 12:00:08 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 67EEE1F0331; Thu, 30 May 2013 15:00:08 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 56BF91F06B4; Thu, 30 May 2013 15:00:08 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 15:00:08 -0400
Message-ID: <51A7A18F.1040104@mitre.org>
Date: Thu, 30 May 2013 14:59:27 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com>
In-Reply-To: <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com>
Content-Type: multipart/alternative; boundary="------------060403070006030306090804"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 19:00:15 -0000

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

But this still doesn't address clients who don't have a client_secret. 
Do they now need one in order to talk to the registration endpoint? What 
you're suggesting is that a client use one set of credentials to get 
access tokens and another set of credentials to get registrations. This 
is certainly no simpler.

And this exact functionality was tried, implemented, and rejected as too 
complicated by the OpenID Connect community. I don't see why it'd be any 
different the second time around.

I really don't see any reason to change it.

  -- Justin

On 05/30/2013 02:56 PM, Phil Hunt wrote:
> It's hard to say what the best solution here is regarding 
> clarifications until we get clarity on the issue of registration 
> access token.
>
> I don't think using a client credential flow to obtain an access token 
> to the registration endpoint is complex. It's the normal flow.
>
> I concede that you are looking at it as using Client Credential to get 
> an access token to get a new Client Credential. But that's not really 
> what is happening in terms of protocol here.
>
> If you take the perspective that the client needs to occasionally 
> update registration (e.g. because of a pending credential expiry), 
> then it is still simple. You use client credential flow to obtain an 
> access token to update registration. Then, from the context of the 
> REST API, the client credential is just another piece of JSON data.
>
> IOW from the REST perspective, it is the registration endpoint that is 
> being updated, not the client credential.  The client credential is 
> just data in the perspective of REST.
>
> I think you may be inferring complexity where there really is none.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>
>> Thanks for clearing up where the confusion was taking place. I had 
>> tried to make it clear that these were absolutely standard, opaque 
>> OAuth2 bearer tokens and absolutely standard OAuth2-protected 
>> endpoints, but if that's not clear that needs to be updated. This is 
>> what the text says right now:
>>
>>     The Client Registration Endpoint MAY accept an Initial Access
>>     Token in the form of an OAuth 2.0
>>     
>>     [RFC6749] access token to limit registration to only previously
>>     authorized parties. The method by which the Initial Access Token
>>     is obtained by the registrant is generally out-of-band and is out
>>     of scope of this specification.
>>
>>
>> And:
>>
>>     The Client Configuration Endpoint is an OAuth 2.0 protected
>>     resource that is provisioned by the server for a specific client
>>     to be able to view and update its registered information. The
>>     location of this endpoint is communicated to the Client through
>>     the registration_client_uri member of the Client Information
>>     Response
>>     
>>     [client-info-response]. The Client MUST use its Registration
>>     Access Token in all calls to this endpoint as an OAuth 2.0 Bearer
>>     Token
>>     
>>     [RFC6750].
>>
>>
>> Along with the definitions in the introduction:
>>
>>     Registration Access Token
>>         OAuth 2.0 Bearer Token issued by the Authorization Server
>>         through the Client Registration Endpoint that is used to
>>         authenticate the caller when accessing the Client's
>>         registration information at the Client Configuration
>>         Endpoint. This Access Token is associated with a particular
>>         registered Client.
>>     Initial Access Token
>>         An OAuth 2.0 Access Token optionally issued by an
>>         Authorization Server granting access to its Client
>>         Registration Endpoint.
>>
>>
>> I'd welcome any proposed changes to the text to make this clearer.
>>
>> As to the other suggestion, what you're saying is to use the client 
>> credentials to get an access token to get the client credentials ... 
>> ? I can see the argument for using the oauth client credentials flow, 
>> but I think that's far more complicated than an endpoint saying 
>> "here's a token, go use it", personally. Besides, not all clients 
>> have credentials at the token endpoint, so it's a bit of a 
>> non-starter for a large class of clients.
>>
>>  -- Justin
>>
>>
>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>> I see what is happening.
>>>
>>> I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.
>>>
>>> For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.
>>>
>>> It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.
>>>
>>> Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".
>>>
>>> That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
>>> 1.  Issed by reg endpoint as part of successful registration
>>> 2.  Has a different lifetime than the client credential (whatever it is).
>>>
>>> Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration".
>>>
>>> As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?
>>>
>>> Maybe now I am completely confused?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>
>>>> The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?
>>>>
>>>> Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>
>>>>> The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.
>>>>>
>>>>> They are both oauth access tokens.
>>>>>
>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  wrote:
>>>>>
>>>>>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token.
>>>>>>
>>>>>> As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On 2013-05-30, at 8:52, Phil Hunt  wrote:
>>>>>>
>>>>>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata.
>>>>>>>
>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On 2013-05-30, at 8:48, John Bradley  wrote:
>>>>>>>
>>>>>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.
>>>>>>>>
>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer  wrote:
>>>>>>>>
>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?
>>>>>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.
>>>>>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret".
>>>>>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing 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
>>
>


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


  
    
  
  
    But this still doesn't address clients who don't have a
    client_secret. Do they now need one in order to talk to the
    registration endpoint? What you're suggesting is that a client use
    one set of credentials to get access tokens and another set of
    credentials to get registrations. This is certainly no simpler.

    

    And this exact functionality was tried, implemented, and rejected as
    too complicated by the OpenID Connect community. I don't see why
    it'd be any different the second time around.

    

    I really don't see any reason to change it. 

    

     -- Justin

    

    
On 05/30/2013 02:56 PM, Phil Hunt
      wrote:

    

    

      
      It's hard to say what the best solution here is regarding
      clarifications until we get clarity on the issue of registration
      access token.
      


      

      
I don't think using a client credential flow to obtain an
        access token to the registration endpoint is complex. It's the
        normal flow.  

      


      

      
I concede that you are looking at it as using Client
        Credential to get an access token to get a new Client
        Credential. But that's not really what is happening in terms of
        protocol here.  

      


      

      
If you take the perspective that the client needs to
        occasionally update registration (e.g. because of a pending
        credential expiry), then it is still simple. You use client
        credential flow to obtain an access token to update
        registration. Then, from the context of the REST API, the client
        credential is just another piece of JSON data.

      


      

      
IOW from the REST perspective, it is the registration
        endpoint that is being updated, not the client credential.  The
        client credential is just data in the perspective of REST.

      


      

      
I think you may be inferring complexity where there really is
        none.

      


      

      

        
        

        

          
On 2013-05-30, at 11:33 AM, Justin Richer wrote:

          

          

            
 Thanks for clearing
              up where the confusion was taking place. I had tried to
              make it clear that these were absolutely standard, opaque
              OAuth2 bearer tokens and absolutely standard
              OAuth2-protected endpoints, but if that's not clear that
              needs to be updated. This is what the text says right now:

              

              
The Client Registration Endpoint MAY accept an
                Initial Access Token in the form of an OAuth

                  2.0  [RFC6749] access
                token to limit registration to only previously
                authorized parties. The method by which the Initial
                Access Token is obtained by the registrant is generally
                out-of-band and is out of scope of this specification.

              

              

              And:

              

              
The Client Configuration Endpoint is an OAuth
                2.0 protected resource that is provisioned by the server
                for a specific client to be able to view and update its
                registered information. The location of this endpoint is
                communicated to the Client through the registration_client_uri
                member of the Client

                  Information Response [client-info-response].
                The Client MUST use its Registration Access Token in all
                calls to this endpoint as an OAuth

                  2.0 Bearer Token [RFC6750].

              

              

              Along with the definitions in the introduction:

              

                

                  
Registration Access Token

                  
OAuth 2.0 Bearer Token
                    issued by the Authorization Server through the
                    Client Registration Endpoint that is used to
                    authenticate the caller when accessing the Client's
                    registration information at the Client Configuration
                    Endpoint. This Access Token is associated with a
                    particular registered Client.

                  
Initial Access Token

                  
An OAuth 2.0 Access Token
                    optionally issued by an Authorization Server
                    granting access to its Client Registration Endpoint.

                

              

              

              I'd welcome any proposed changes to the text to make this
              clearer.

              

              As to the other suggestion, what you're saying is to use
              the client credentials to get an access token to get the
              client credentials ... ? I can see the argument for using
              the oauth client credentials flow, but I think that's far
              more complicated than an endpoint saying "here's a token,
              go use it", personally. Besides, not all clients have
              credentials at the token endpoint, so it's a bit of a
              non-starter for a large class of clients.

              

               -- Justin

              

              

              
On 05/30/2013 01:55 PM, Phil
                Hunt wrote:

              

              

                
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".

That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it is).

Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". 

As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                

                  
The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?

Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                  

                    
The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



                    

                      
Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. 

As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this. 

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> wrote:



                      

                        
No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                        

                          
I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                          

                            

                              

                                

                                  
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?


                                

                                
I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.


                              

                              
I'm not arguing to make it plural. I think the authentication method is just "client_secret".


                            

                            
That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.


                          

                          
_______________________________________________
OAuth mailing 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


              

              

            

          

        

        

      

    

    

  


--------------060403070006030306090804--

From phil.hunt@oracle.com  Thu May 30 12:31:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0021F915C for ; Thu, 30 May 2013 12:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.434
X-Spam-Level: 
X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdLRER7zBam7 for ; Thu, 30 May 2013 12:31:09 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F3E0A21F91B2 for ; Thu, 30 May 2013 12:31:08 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UJV5bV030322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 19:31:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UJV45L002776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 19:31:04 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UJV3vK002755; Thu, 30 May 2013 19:31:03 GMT
Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 12:31:03 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E272D87D-9546-4974-B9E6-163198E613F9"
From: Phil Hunt 
In-Reply-To: <51A7A18F.1040104@mitre.org>
Date: Thu, 30 May 2013 12:31:01 -0700
Message-Id: <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 19:31:14 -0000

--Apple-Mail=_E272D87D-9546-4974-B9E6-163198E613F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

For this, I would suggest:

Anonymous, user assisted registration - client registers using the =
client credential flow but may use an administrator (in the case of web =
app) or end-user (uid/password) .  Since resource owner would still =
require separate credential, then the client flow could be used even =
though we are passing end-user creds. Client obtains access token =
limited to registering the new entity.

Anonymous unassisted registration (no user present) - the only solution =
I can come up with is the client self asserted client_id (e.g. UUID) =
that the token endpoint chooses to accept if scope equals "registration" =
(or whatever the scope is to be for registration).   IMHO this should be =
avoided.

3rd Party Assertion - client presents signed assertion in the form of =
JWT or SAML Bearer assertion and exchanges for an access token. Access =
is limited to registering a new entity.

The value of the access token being short lived or potentially even =
single-use (or limited use, like 3 tries), would be to prevent abuse of =
the registration end-point.

Phil

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





On 2013-05-30, at 11:59 AM, Justin Richer wrote:

> But this still doesn't address clients who don't have a client_secret. =
Do they now need one in order to talk to the registration endpoint? What =
you're suggesting is that a client use one set of credentials to get =
access tokens and another set of credentials to get registrations. This =
is certainly no simpler.
>=20
> And this exact functionality was tried, implemented, and rejected as =
too complicated by the OpenID Connect community. I don't see why it'd be =
any different the second time around.
>=20
> I really don't see any reason to change it.=20
>=20
>  -- Justin
>=20
> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>> It's hard to say what the best solution here is regarding =
clarifications until we get clarity on the issue of registration access =
token.
>>=20
>> I don't think using a client credential flow to obtain an access =
token to the registration endpoint is complex. It's the normal flow. =20
>>=20
>> I concede that you are looking at it as using Client Credential to =
get an access token to get a new Client Credential. But that's not =
really what is happening in terms of protocol here. =20
>>=20
>> If you take the perspective that the client needs to occasionally =
update registration (e.g. because of a pending credential expiry), then =
it is still simple. You use client credential flow to obtain an access =
token to update registration. Then, from the context of the REST API, =
the client credential is just another piece of JSON data.
>>=20
>> IOW from the REST perspective, it is the registration endpoint that =
is being updated, not the client credential.  The client credential is =
just data in the perspective of REST.
>>=20
>> I think you may be inferring complexity where there really is none.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>>=20
>>> Thanks for clearing up where the confusion was taking place. I had =
tried to make it clear that these were absolutely standard, opaque =
OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, =
but if that's not clear that needs to be updated. This is what the text =
says right now:
>>>=20
>>> The Client Registration Endpoint MAY accept an Initial Access Token =
in the form of an OAuth 2.0 [RFC6749] access token to limit registration =
to only previously authorized parties. The method by which the Initial =
Access Token is obtained by the registrant is generally out-of-band and =
is out of scope of this specification.
>>>=20
>>> And:
>>>=20
>>> The Client Configuration Endpoint is an OAuth 2.0 protected resource =
that is provisioned by the server for a specific client to be able to =
view and update its registered information. The location of this =
endpoint is communicated to the Client through the =
registration_client_uri member of the Client Information Response =
[client-info-response]. The Client MUST use its Registration Access =
Token in all calls to this endpoint as an OAuth 2.0 Bearer Token =
[RFC6750].
>>>=20
>>> Along with the definitions in the introduction:
>>> Registration Access Token
>>> OAuth 2.0 Bearer Token issued by the Authorization Server through =
the Client Registration Endpoint that is used to authenticate the caller =
when accessing the Client's registration information at the Client =
Configuration Endpoint. This Access Token is associated with a =
particular registered Client.
>>> Initial Access Token
>>> An OAuth 2.0 Access Token optionally issued by an Authorization =
Server granting access to its Client Registration Endpoint.
>>>=20
>>> I'd welcome any proposed changes to the text to make this clearer.
>>>=20
>>> As to the other suggestion, what you're saying is to use the client =
credentials to get an access token to get the client credentials ... ? I =
can see the argument for using the oauth client credentials flow, but I =
think that's far more complicated than an endpoint saying "here's a =
token, go use it", personally. Besides, not all clients have credentials =
at the token endpoint, so it's a bit of a non-starter for a large class =
of clients.
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>>> I see what is happening.
>>>>=20
>>>> I think the reason why I find this spec sooo confusing is that the =
terms imply new token types when they don't.
>>>>=20
>>>> For example when you say "Registration Access Token" and "Initial =
Access Token" it implies to me that it is a totally new token type (and =
in one case it sorta is). When you read the spec (particularly draft 10) =
it is easy to assume something very different is going on. Hence my push =
back.
>>>>=20
>>>> It is now clear to me that what you mean to say is *Access Token =
used for initial access* and *Access Token used for registration*.
>>>>=20
>>>> Why not write the draft to make clear that the registration end =
point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can =
eliminate all of the terminology and lifecycle around access tokens =
except to say the endpoint is accessed by tokens issued based on the =
scope "oauth2:registration".
>>>>=20
>>>> That only brings issues with the registration token.  The "Access =
Token used for registration" seems to have special lifecycle =
differences.
>>>> 1.  Issed by reg endpoint as part of successful registration
>>>> 2.  Has a different lifetime than the client credential (whatever =
it is).
>>>>=20
>>>> Why not again simplify and follow normal OAuth2 pattern and have =
the access token issued for registration be *short* lived.  Each time =
the client wants to either initially register or update its profile it =
must request a normal access token with scope "oauth2:registration".=20
>>>>=20
>>>> As for client credential expiry, why not simply require the client =
to update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?
>>>>=20
>>>> Maybe now I am completely confused?
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>>=20
>>>>> The issue is that it has different issuing/lifecycle than normal. =
E.g. Why is it issued by the registration endpoint?
>>>>>=20
>>>>> Why doesn't the client just request an access token using its =
client credential for the registration endpoint when it wants to update =
its profile?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>>=20
>>>>>> The reg access token is a OAuth bearer token that is issued as =
part of the registration response and used to access the new client =
resource for reads and or updates depending on the permissions.
>>>>>>=20
>>>>>> They are both oauth access tokens.
>>>>>>=20
>>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  =
wrote:
>>>>>>=20
>>>>>>> Seriously. The new dyn reg draft introduces two new tokens. The =
initial reg token and the registration access token.=20
>>>>>>>=20
>>>>>>> As for the latter, the reg access token, my understanding is it =
has nothing to do with an access token. It is issued *after* =
registration to allow reg updates.  Right? I know some are confused =
about this.=20
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> On 2013-05-30, at 8:52, Phil Hunt  wrote:
>>>>>>>=20
>>>>>>>> No different issue. I was concerned about the initial client =
assertion being passed in as authen cred. It is a signed set of client =
reg metadata.=20
>>>>>>>>=20
>>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> On 2013-05-30, at 8:48, John Bradley  wrote:
>>>>>>>>=20
>>>>>>>>> I think Phil also had some processing reason why a Token =
endpoint or RS wouldn't want to tale the authentication as a header, as =
the processing was easier with them as parameters as they are =
potentially available to different parts of the stack.   That may have =
been mostly around RS, but the principal may apply to the token endpoint =
as well.
>>>>>>>>>=20
>>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer  =
wrote:
>>>>>>>>>=20
>>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>>> BASIC and POST are essentially the same just different =
ways to send the client secret. If an authorization server supports =
both, both should work for any client. So are both methods treated =
differently?
>>>>>>>>>>>> I agree, and this was one of my original arguments for =
making this field plural (or plural-able), but there hasn't been WG =
support for that so far.
>>>>>>>>>>> I'm not arguing to make it plural. I think the =
authentication method is just "client_secret".
>>>>>>>>>> That was also an option that was brought up, but in the OIDC =
WG the counter-argument was (as I recall) that the two are syntactically =
separate and there's a desire to restrict to a single type, such as =
disabling client_secret_post. Basically, to make it unambiguous.
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20


--Apple-Mail=_E272D87D-9546-4974-B9E6-163198E613F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

For =
this, I would suggest:

Anonymous, user assisted =
registration - client registers using the client credential flow but may =
use an administrator (in the case of web app) or end-user (uid/password) =
.  Since resource owner would still require separate credential, =
then the client flow could be used even though we are passing end-user =
creds. Client obtains access token limited to registering the new =
entity.

Anonymous unassisted registration (no =
user present) - the only solution I can come up with is the client self =
asserted client_id (e.g. UUID) that the token endpoint chooses to accept =
if scope equals "registration" (or whatever the scope is to be for =
registration).   IMHO this should be =
avoided.

3rd Party Assertion - client presents =
signed assertion in the form of JWT or SAML Bearer assertion and =
exchanges for an access token. Access is limited to registering a new =
entity.

The value of the access token being =
short lived or potentially even single-use (or limited use, like 3 =
tries), would be to prevent abuse of the registration =
end-point.



Phil

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








On 2013-05-30, at 11:59 AM, Justin Richer wrote:


 =20
    
 =20
  

    But this still doesn't address clients who don't have a
    client_secret. Do they now need one in order to talk to the
    registration endpoint? What you're suggesting is that a client use
    one set of credentials to get access tokens and another set of
    credentials to get registrations. This is certainly no simpler.

    

    And this exact functionality was tried, implemented, and rejected as
    too complicated by the OpenID Connect community. I don't see why
    it'd be any different the second time around.

    

    I really don't see any reason to change it. 

    

     -- Justin

    

    
On 05/30/2013 02:56 PM, Phil Hunt
      wrote:

    

    

      
      It's hard to say what the best solution here is regarding
      clarifications until we get clarity on the issue of registration
      access token.
      


      

      
I don't think using a client credential flow to obtain an
        access token to the registration endpoint is complex. It's the
        normal flow.  

      


      

      
I concede that you are looking at it as using Client
        Credential to get an access token to get a new Client
        Credential. But that's not really what is happening in terms of
        protocol here.  

      


      

      
If you take the perspective that the client needs to
        occasionally update registration (e.g. because of a pending
        credential expiry), then it is still simple. You use client
        credential flow to obtain an access token to update
        registration. Then, from the context of the REST API, the client
        credential is just another piece of JSON data.

      


      

      
IOW from the REST perspective, it is the registration
        endpoint that is being updated, not the client credential. =
 The
        client credential is just data in the perspective of REST.

      


      

      
I think you may be inferring complexity where there really is
        none.

      


      

      

        
        

        

          
On 2013-05-30, at 11:33 AM, Justin Richer wrote:

          

          

            
 Thanks for =
clearing
              up where the confusion was taking place. I had tried to
              make it clear that these were absolutely standard, opaque
              OAuth2 bearer tokens and absolutely standard
              OAuth2-protected endpoints, but if that's not clear that
              needs to be updated. This is what the text says right =
now:

              

              
The Client Registration Endpoint MAY accept an
                Initial Access Token in the form of an OAuth

                  2.0  [RFC6749] access
                token to limit registration to only previously
                authorized parties. The method by which the Initial
                Access Token is obtained by the registrant is generally
                out-of-band and is out of scope of this =
specification.

              

              

              And:

              

              
The Client Configuration Endpoint is an OAuth
                2.0 protected resource that is provisioned by the server
                for a specific client to be able to view and update its
                registered information. The location of this endpoint is
                communicated to the Client through the =
registration_client_uri
                member of the Client

                  Information Response [client-info-response].
                The Client MUST use its Registration Access Token in all
                calls to this endpoint as an OAuth

                  2.0 Bearer Token [RFC6750].

              

              

              Along with the definitions in the introduction:

              

                

                  
Registration Access Token

                  
OAuth 2.0 Bearer Token
                    issued by the Authorization Server through the
                    Client Registration Endpoint that is used to
                    authenticate the caller when accessing the Client's
                    registration information at the Client Configuration
                    Endpoint. This Access Token is associated with a
                    particular registered Client.

                  
Initial Access Token

                  
An OAuth 2.0 Access Token
                    optionally issued by an Authorization Server
                    granting access to its Client Registration =
Endpoint.

                

              

              

              I'd welcome any proposed changes to the text to make this
              clearer.

              

              As to the other suggestion, what you're saying is to use
              the client credentials to get an access token to get the
              client credentials ... ? I can see the argument for using
              the oauth client credentials flow, but I think that's far
              more complicated than an endpoint saying "here's a token,
              go use it", personally. Besides, not all clients have
              credentials at the token endpoint, so it's a bit of a
              non-starter for a large class of clients.

              

               -- Justin

              

              

              
On 05/30/2013 01:55 PM, =
Phil
                Hunt wrote:

              

              

                
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms =
imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access =
Token" it implies to me that it is a totally new token type (and in one =
case it sorta is). When you read the spec (particularly draft 10) it is =
easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used =
for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is =
just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate =
all of the terminology and lifecycle around access tokens except to say =
the endpoint is accessed by tokens issued based on the scope =
"oauth2:registration".

That only brings issues with the registration token.  The "Access Token =
used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it =
is).

Why not again simplify and follow normal OAuth2 pattern and have the =
access token issued for registration be *short* lived.  Each time the =
client wants to either initially register or update its profile it must =
request a normal access token with scope "oauth2:registration".=20

As for client credential expiry, why not simply require the client to =
update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                

                  
The issue is that it has different =
issuing/lifecycle than normal. E.g. Why is it issued by the registration =
endpoint?

Why doesn't the client just request an access token using its client =
credential for the registration endpoint when it wants to update its =
profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                  

                    
The reg access token is a OAuth =
bearer token that is issued as part of the registration response and =
used to access the new client resource for reads and or updates =
depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                    

                      
Seriously. The new dyn reg draft =
introduces two new tokens. The initial reg token and the registration =
access token.=20

As for the latter, the reg access token, my understanding is it has =
nothing to do with an access token. It is issued *after* registration to =
allow reg updates.  Right? I know some are confused about this.=20

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                      

                        
No different issue. I was =
concerned about the initial client assertion being passed in as authen =
cred. It is a signed set of client reg metadata.=20

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                        

                          
I think Phil also had some =
processing reason why a Token endpoint or RS wouldn't want to tale the =
authentication as a header, as the processing was easier with them as =
parameters as they are potentially available to different parts of the =
stack.   That may have been mostly around RS, but the principal may =
apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                          

                            

                              

                                

                                  
"client_secret_post vs =
client_secret_basic"
BASIC and POST are essentially the same just different ways to send the =
client secret. If an authorization server supports both, both should =
work for any client. So are both methods treated differently?


                                

                                
I agree, and this was one =
of my original arguments for making this field plural (or plural-able), =
but there hasn't been WG support for that so far.


                              

                              
I'm not arguing to make it =
plural. I think the authentication method is just "client_secret".


                            

                            
That was also an option that =
was brought up, but in the OIDC WG the counter-argument was (as I =
recall) that the two are syntactically separate and there's a desire to =
restrict to a single type, such as disabling client_secret_post. =
Basically, to make it unambiguous.


                          

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


                        

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


                      

                    

                  

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


                

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


              

              

            

          

        

        

      

    

    

  




=

--Apple-Mail=_E272D87D-9546-4974-B9E6-163198E613F9--

From jricher@mitre.org  Thu May 30 12:52:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877BB21F87E0 for ; Thu, 30 May 2013 12:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.951
X-Spam-Level: 
X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GC805CViFY3 for ; Thu, 30 May 2013 12:51:52 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC521F87BB for ; Thu, 30 May 2013 12:51:51 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 107AA1F0836; Thu, 30 May 2013 15:51:51 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E2E5F1F081C; Thu, 30 May 2013 15:51:50 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 15:51:50 -0400
Message-ID: <51A7ADAE.4070005@mitre.org>
Date: Thu, 30 May 2013 15:51:10 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com>
In-Reply-To: <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com>
Content-Type: multipart/alternative; boundary="------------070903030902090607060606"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 19:52:02 -0000

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

I don't understand which access token is being talked about here -- is 
this the Initial Registration Token? Because you can already do 
everything below. How you get the Initial Registration token is out of 
scope precisely so that the AS can decide what that means. We can add 
language in the lifecycle discussions to bring up the fact that you can 
get this token from an OAuth flow, if you think that'll help clear 
things up.

However, the client doesn't register using the client credential flow at 
all -- it registers using a POST to the registration endpoint, and that 
POST might have an OAuth token attached to it. How the client got that 
OAuth token is, again, out of scope. The client could have done some 
other OAuth flow (any OAuth flow) to get a hold of the token, but how is 
it supposed to get an OAuth token at an AS it hasn't been registered with?

Now, if you're talking about the Registration Access Token, though, that 
makes less sense to me. The client *has* to register first before it can 
get *anything* from the token endpoint. What you're suggesting is that 
all clients be given access to the token endpoint with the client 
credentials flow for the purposes of retrieving the Registration Access 
Token, unless I misread things. You probably don't want the client 
getting other scopes from the token endpoint using the client 
credentials flow, as it'd be an enormous security risk. Thing is, I 
don't think I can implement that level of separation in my app stack, 
and I haven't seen any others that do that. Separating access to 
different endpoints based on OAuth tokens (and the scopes attached) is 
par for the course, though.

Let me run down how it works in our own setup. When a client registers, 
we create a new token (using a TokenServices class) that has a special 
scope, "registration-token". This token is tied to the client_id to 
which it was issued. Clients cannot get tokens with this scope through 
the usual Token Endpoint means, by design. All of the Client 
Configuration Endpoint URLs are protected such that they require access 
from a valid token with the scope "registration-token", and the 
client_id tied to that token MUST match the client_id in the URL. Each 
client is limited to the OAuth flows (grant_types and response_types) 
that it's allowed to call from the token endpoint. All of this is 
specific to our implementation, but I can speak with some authority that 
it's at least implementable this way. This method lets us do public 
clients, confidential clients, public-key clients (that use JWT 
assertions to call the token endpoint), and all different OAuth flows.

If we were to switch things to what you're recommending (using client 
credentials to get the equivalent of the Registration Access Token), I 
would need to issue some form of client credentials to all clients 
(including public clients) and allow all dynamically registered clients 
access to the client_credentials flow at the token endpoint but only if 
they're asking for a registration-token scope, a scope value which 
hasn't been standardized either. I don't think this is even possible in 
my architecture, and it's certainly not desirable.

If we were to switch to having the client credentials used directly on 
the registration endpoint, then you get back into the situation that 
OIDC has already tried, and which failed. I see no reason to try the 
same thing again and expect different results.

I will admit that it was a little strange when I first pulled the 
TokenServices reference into our RegistrationEndpoint class, but doing 
so greatly simplified everything else. I can see the desire to have an 
ideological purity of "all tokens come from the token endpoint", but 
such purity just doesn't help in this case.

  -- Justin

On 05/30/2013 03:31 PM, Phil Hunt wrote:
> For this, I would suggest:
>
> Anonymous, user assisted registration - client registers using the 
> client credential flow but may use an administrator (in the case of 
> web app) or end-user (uid/password) .  Since resource owner would 
> still require separate credential, then the client flow could be used 
> even though we are passing end-user creds. Client obtains access token 
> limited to registering the new entity.
>
> Anonymous unassisted registration (no user present) - the only 
> solution I can come up with is the client self asserted client_id 
> (e.g. UUID) that the token endpoint chooses to accept if scope equals 
> "registration" (or whatever the scope is to be for registration).   
> IMHO this should be avoided.
>
> 3rd Party Assertion - client presents signed assertion in the form of 
> JWT or SAML Bearer assertion and exchanges for an access token. Access 
> is limited to registering a new entity.
>
> The value of the access token being short lived or potentially even 
> single-use (or limited use, like 3 tries), would be to prevent abuse 
> of the registration end-point.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-05-30, at 11:59 AM, Justin Richer wrote:
>
>> But this still doesn't address clients who don't have a 
>> client_secret. Do they now need one in order to talk to the 
>> registration endpoint? What you're suggesting is that a client use 
>> one set of credentials to get access tokens and another set of 
>> credentials to get registrations. This is certainly no simpler.
>>
>> And this exact functionality was tried, implemented, and rejected as 
>> too complicated by the OpenID Connect community. I don't see why it'd 
>> be any different the second time around.
>>
>> I really don't see any reason to change it.
>>
>>  -- Justin
>>
>> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>>> It's hard to say what the best solution here is regarding 
>>> clarifications until we get clarity on the issue of registration 
>>> access token.
>>>
>>> I don't think using a client credential flow to obtain an access 
>>> token to the registration endpoint is complex. It's the normal flow.
>>>
>>> I concede that you are looking at it as using Client Credential to 
>>> get an access token to get a new Client Credential. But that's not 
>>> really what is happening in terms of protocol here.
>>>
>>> If you take the perspective that the client needs to occasionally 
>>> update registration (e.g. because of a pending credential expiry), 
>>> then it is still simple. You use client credential flow to obtain an 
>>> access token to update registration. Then, from the context of the 
>>> REST API, the client credential is just another piece of JSON data.
>>>
>>> IOW from the REST perspective, it is the registration endpoint that 
>>> is being updated, not the client credential.  The client credential 
>>> is just data in the perspective of REST.
>>>
>>> I think you may be inferring complexity where there really is none.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>>>
>>>> Thanks for clearing up where the confusion was taking place. I had 
>>>> tried to make it clear that these were absolutely standard, opaque 
>>>> OAuth2 bearer tokens and absolutely standard OAuth2-protected 
>>>> endpoints, but if that's not clear that needs to be updated. This 
>>>> is what the text says right now:
>>>>
>>>>     The Client Registration Endpoint MAY accept an Initial Access
>>>>     Token in the form of an OAuth 2.0
>>>>     
>>>>     [RFC6749] access token to limit registration to only previously
>>>>     authorized parties. The method by which the Initial Access
>>>>     Token is obtained by the registrant is generally out-of-band
>>>>     and is out of scope of this specification.
>>>>
>>>>
>>>> And:
>>>>
>>>>     The Client Configuration Endpoint is an OAuth 2.0 protected
>>>>     resource that is provisioned by the server for a specific
>>>>     client to be able to view and update its registered
>>>>     information. The location of this endpoint is communicated to
>>>>     the Client through the registration_client_uri member of the
>>>>     Client Information Response
>>>>     
>>>>     [client-info-response]. The Client MUST use its Registration
>>>>     Access Token in all calls to this endpoint as an OAuth 2.0
>>>>     Bearer Token
>>>>     
>>>>     [RFC6750].
>>>>
>>>>
>>>> Along with the definitions in the introduction:
>>>>
>>>>     Registration Access Token
>>>>         OAuth 2.0 Bearer Token issued by the Authorization Server
>>>>         through the Client Registration Endpoint that is used to
>>>>         authenticate the caller when accessing the Client's
>>>>         registration information at the Client Configuration
>>>>         Endpoint. This Access Token is associated with a particular
>>>>         registered Client.
>>>>     Initial Access Token
>>>>         An OAuth 2.0 Access Token optionally issued by an
>>>>         Authorization Server granting access to its Client
>>>>         Registration Endpoint.
>>>>
>>>>
>>>> I'd welcome any proposed changes to the text to make this clearer.
>>>>
>>>> As to the other suggestion, what you're saying is to use the client 
>>>> credentials to get an access token to get the client credentials 
>>>> ... ? I can see the argument for using the oauth client credentials 
>>>> flow, but I think that's far more complicated than an endpoint 
>>>> saying "here's a token, go use it", personally. Besides, not all 
>>>> clients have credentials at the token endpoint, so it's a bit of a 
>>>> non-starter for a large class of clients.
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>>>> I see what is happening.
>>>>>
>>>>> I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.
>>>>>
>>>>> For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.
>>>>>
>>>>> It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.
>>>>>
>>>>> Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".
>>>>>
>>>>> That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
>>>>> 1.  Issed by reg endpoint as part of successful registration
>>>>> 2.  Has a different lifetime than the client credential (whatever it is).
>>>>>
>>>>> Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration".
>>>>>
>>>>> As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?
>>>>>
>>>>> Maybe now I am completely confused?
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>>>
>>>>>> The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?
>>>>>>
>>>>>> Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>>>
>>>>>>> The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.
>>>>>>>
>>>>>>> They are both oauth access tokens.
>>>>>>>
>>>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  wrote:
>>>>>>>
>>>>>>>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token.
>>>>>>>>
>>>>>>>> As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On 2013-05-30, at 8:52, Phil Hunt  wrote:
>>>>>>>>
>>>>>>>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata.
>>>>>>>>>
>>>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> On 2013-05-30, at 8:48, John Bradley  wrote:
>>>>>>>>>
>>>>>>>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.
>>>>>>>>>>
>>>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer  wrote:
>>>>>>>>>>
>>>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?
>>>>>>>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.
>>>>>>>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret".
>>>>>>>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing 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
>>>>
>>>
>>
>


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


  
    
  
  
    I don't understand which access token is being talked about here --
    is this the Initial Registration Token? Because you can already do
    everything below. How you get the Initial Registration token is out
    of scope precisely so that the AS can decide what that means. We can
    add language in the lifecycle discussions to bring up the fact that
    you can get this token from an OAuth flow, if you think that'll help
    clear things up.

    

    However, the client doesn't register using the client credential
    flow at all -- it registers using a POST to the registration
    endpoint, and that POST might have an OAuth token attached to it.
    How the client got that OAuth token is, again, out of scope. The
    client could have done some other OAuth flow (any OAuth flow) to get
    a hold of the token, but how is it supposed to get an OAuth token at
    an AS it hasn't been registered with? 

    

    Now, if you're talking about the Registration Access Token, though,
    that makes less sense to me. The client *has* to register first
    before it can get *anything* from the token endpoint. What you're
    suggesting is that all clients be given access to the token endpoint
    with the client credentials flow for the purposes of retrieving the
    Registration Access Token, unless I misread things. You probably
    don't want the client getting other scopes from the token endpoint
    using the client credentials flow, as it'd be an enormous security
    risk. Thing is, I don't think I can implement that level of
    separation in my app stack, and I haven't seen any others that do
    that. Separating access to different endpoints based on OAuth tokens
    (and the scopes attached) is par for the course, though.

    

    Let me run down how it works in our own setup. When a client
    registers, we create a new token (using a TokenServices class) that
    has a special scope, "registration-token". This token is tied to the
    client_id to which it was issued. Clients cannot get tokens with
    this scope through the usual Token Endpoint means, by design. All of
    the Client Configuration Endpoint URLs are protected such that they
    require access from a valid token with the scope
    "registration-token", and the client_id tied to that token MUST
    match the client_id in the URL. Each client is limited to the OAuth
    flows (grant_types and response_types) that it's allowed to call
    from the token endpoint. All of this is specific to our
    implementation, but I can speak with some authority that it's at
    least implementable this way. This method lets us do public clients,
    confidential clients, public-key clients (that use JWT assertions to
    call the token endpoint), and all different OAuth flows. 

    

    If we were to switch things to what you're recommending (using
    client credentials to get the equivalent of the Registration Access
    Token), I would need to issue some form of client credentials to all
    clients (including public clients) and allow all dynamically
    registered clients access to the client_credentials flow at the
    token endpoint but only if they're asking for a registration-token
    scope, a scope value which hasn't been standardized either. I don't
    think this is even possible in my architecture, and it's certainly
    not desirable. 

    

    If we were to switch to having the client credentials used directly
    on the registration endpoint, then you get back into the situation
    that OIDC has already tried, and which failed. I see no reason to
    try the same thing again and expect different results.

    

    I will admit that it was a little strange when I first pulled the
    TokenServices reference into our RegistrationEndpoint class, but
    doing so greatly simplified everything else. I can see the desire to
    have an ideological purity of "all tokens come from the token
    endpoint", but such purity just doesn't help in this case. 

    

     -- Justin

    

    
On 05/30/2013 03:31 PM, Phil Hunt
      wrote:

    

    

      
      For this, I would suggest:
      


      

      
Anonymous, user assisted registration - client registers
        using the client credential flow but may use an administrator
        (in the case of web app) or end-user (uid/password) .  Since
        resource owner would still require separate credential, then the
        client flow could be used even though we are passing end-user
        creds. Client obtains access token limited to registering the
        new entity.

      


      

      
Anonymous unassisted registration (no user present) - the
        only solution I can come up with is the client self asserted
        client_id (e.g. UUID) that the token endpoint chooses to accept
        if scope equals "registration" (or whatever the scope is to be
        for registration).   IMHO this should be avoided.

      


      

      
3rd Party Assertion - client presents signed assertion in the
        form of JWT or SAML Bearer assertion and exchanges for an access
        token. Access is limited to registering a new entity.

      


      

      
The value of the access token being short lived or
        potentially even single-use (or limited use, like 3 tries),
        would be to prevent abuse of the registration end-point.

      


        
        

        

          
On 2013-05-30, at 11:59 AM, Justin Richer wrote:

          

          

            
 But this still
              doesn't address clients who don't have a client_secret. Do
              they now need one in order to talk to the registration
              endpoint? What you're suggesting is that a client use one
              set of credentials to get access tokens and another set of
              credentials to get registrations. This is certainly no
              simpler.

              

              And this exact functionality was tried, implemented, and
              rejected as too complicated by the OpenID Connect
              community. I don't see why it'd be any different the
              second time around.

              

              I really don't see any reason to change it. 

              

               -- Justin

              

              
On 05/30/2013 02:56 PM, Phil
                Hunt wrote:

              

              
 It's hard to say what the best solution
                here is regarding clarifications until we get clarity on
                the issue of registration access token.
                


                

                
I don't think using a client credential flow to
                  obtain an access token to the registration endpoint is
                  complex. It's the normal flow.  

                


                

                
I concede that you are looking at it as using
                  Client Credential to get an access token to get a new
                  Client Credential. But that's not really what is
                  happening in terms of protocol here.  

                


                

                
If you take the perspective that the client needs
                  to occasionally update registration (e.g. because of a
                  pending credential expiry), then it is still simple.
                  You use client credential flow to obtain an access
                  token to update registration. Then, from the context
                  of the REST API, the client credential is just another
                  piece of JSON data.

                


                

                
IOW from the REST perspective, it is the
                  registration endpoint that is being updated, not the
                  client credential.  The client credential is just data
                  in the perspective of REST.

                


                

                
I think you may be inferring complexity where there
                  really is none.

                


                

                

                  
                  

                  

                    
On 2013-05-30, at 11:33 AM, Justin Richer
                      wrote:

                    

                    

                      
 Thanks for
                        clearing up where the confusion was taking
                        place. I had tried to make it clear that these
                        were absolutely standard, opaque OAuth2 bearer
                        tokens and absolutely standard OAuth2-protected
                        endpoints, but if that's not clear that needs to
                        be updated. This is what the text says right
                        now:

                        

                        
The Client Registration Endpoint MAY
                          accept an Initial Access Token in the form of
                          an OAuth


                            2.0  [RFC6749]
                          access token to limit registration to only
                          previously authorized parties. The method by
                          which the Initial Access Token is obtained by
                          the registrant is generally out-of-band and is
                          out of scope of this specification.

                        

                        

                        And:

                        

                        
The Client Configuration Endpoint is
                          an OAuth 2.0 protected resource that is
                          provisioned by the server for a specific
                          client to be able to view and update its
                          registered information. The location of this
                          endpoint is communicated to the Client through
                          the registration_client_uri
                          member of the Client


                            Information Response [client-info-response].
                          The Client MUST use its Registration Access
                          Token in all calls to this endpoint as an OAuth


                            2.0 Bearer Token [RFC6750].

                        

                        

                        Along with the definitions in the introduction:

                        

                          

                            
Registration Access Token

                            
OAuth 2.0 Bearer
                              Token issued by the Authorization Server
                              through the Client Registration Endpoint
                              that is used to authenticate the caller
                              when accessing the Client's registration
                              information at the Client Configuration
                              Endpoint. This Access Token is associated
                              with a particular registered Client.

                            
Initial Access Token

                            
An OAuth 2.0
                              Access Token optionally issued by an
                              Authorization Server granting access to
                              its Client Registration Endpoint.

                          

                        

                        

                        I'd welcome any proposed changes to the text to
                        make this clearer.

                        

                        As to the other suggestion, what you're saying
                        is to use the client credentials to get an
                        access token to get the client credentials ... ?
                        I can see the argument for using the oauth
                        client credentials flow, but I think that's far
                        more complicated than an endpoint saying "here's
                        a token, go use it", personally. Besides, not
                        all clients have credentials at the token
                        endpoint, so it's a bit of a non-starter for a
                        large class of clients.

                        

                         -- Justin

                        

                        

                        
On 05/30/2013 01:55
                          PM, Phil Hunt wrote:

                        

                        

                          
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".

That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it is).

Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". 

As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                          

                            
The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?

Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                            

                              
The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



                              

                                
Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. 

As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this. 

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> wrote:



                                

                                  
No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                                  

                                    
I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                                    

                                      

                                        

                                          

                                            
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?


                                          

                                          
I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.


                                        

                                        
I'm not arguing to make it plural. I think the authentication method is just "client_secret".


                                      

                                      
That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.


                                    

                                    
_______________________________________________
OAuth mailing 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


                        

                        

                      

                    

                  

                  

                

              

              

            

          

        

        

      

    

    

  


--------------070903030902090607060606--

From phil.hunt@oracle.com  Thu May 30 12:55:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DC21F9273 for ; Thu, 30 May 2013 12:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.422
X-Spam-Level: 
X-Spam-Status: No, score=-4.422 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ffjKOblOh7 for ; Thu, 30 May 2013 12:55:19 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9821F881C for ; Thu, 30 May 2013 12:54:59 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UJsued009648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 19:54:56 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UJsvAQ022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 19:54:57 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UJsucD015911; Thu, 30 May 2013 19:54:56 GMT
Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 12:54:55 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_71CE01DD-5735-4B17-8571-67A1D606441A"
From: Phil Hunt 
In-Reply-To: <51A7ADAE.4070005@mitre.org>
Date: Thu, 30 May 2013 12:54:54 -0700
Message-Id: <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 19:55:38 -0000

--Apple-Mail=_71CE01DD-5735-4B17-8571-67A1D606441A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Justin,

So far, every time an OAuth server has accepted a 3rd party token it has =
been a bearer assertion. The common pattern is to exchange that =
assertion for a an access token issued by the local server for the local =
resource endpoint.

That's the pattern I am trying to follow.

Going this way means we do not have to define the initial registration =
token.

If however, you really want to use the initial registration token AS an =
access token, you are taking us into the question of using federated =
access tokens.  I prefer not to do that here.

Phil

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





On 2013-05-30, at 12:51 PM, Justin Richer wrote:

> I don't understand which access token is being talked about here -- is =
this the Initial Registration Token? Because you can already do =
everything below. How you get the Initial Registration token is out of =
scope precisely so that the AS can decide what that means. We can add =
language in the lifecycle discussions to bring up the fact that you can =
get this token from an OAuth flow, if you think that'll help clear =
things up.
>=20
> However, the client doesn't register using the client credential flow =
at all -- it registers using a POST to the registration endpoint, and =
that POST might have an OAuth token attached to it. How the client got =
that OAuth token is, again, out of scope. The client could have done =
some other OAuth flow (any OAuth flow) to get a hold of the token, but =
how is it supposed to get an OAuth token at an AS it hasn't been =
registered with?=20
>=20
> Now, if you're talking about the Registration Access Token, though, =
that makes less sense to me. The client *has* to register first before =
it can get *anything* from the token endpoint. What you're suggesting is =
that all clients be given access to the token endpoint with the client =
credentials flow for the purposes of retrieving the Registration Access =
Token, unless I misread things. You probably don't want the client =
getting other scopes from the token endpoint using the client =
credentials flow, as it'd be an enormous security risk. Thing is, I =
don't think I can implement that level of separation in my app stack, =
and I haven't seen any others that do that. Separating access to =
different endpoints based on OAuth tokens (and the scopes attached) is =
par for the course, though.
>=20
> Let me run down how it works in our own setup. When a client =
registers, we create a new token (using a TokenServices class) that has =
a special scope, "registration-token". This token is tied to the =
client_id to which it was issued. Clients cannot get tokens with this =
scope through the usual Token Endpoint means, by design. All of the =
Client Configuration Endpoint URLs are protected such that they require =
access from a valid token with the scope     "registration-token", and =
the client_id tied to that token MUST match the client_id in the URL. =
Each client is limited to the OAuth flows (grant_types and =
response_types) that it's allowed to call from the token endpoint. All =
of this is specific to our implementation, but I can speak with some =
authority that it's at least implementable this way. This method lets us =
do public clients, confidential clients, public-key clients (that use =
JWT assertions to call the token endpoint), and all different OAuth =
flows.=20
>=20
> If we were to switch things to what you're recommending (using client =
credentials to get the equivalent of the Registration Access Token), I =
would need to issue some form of client credentials to all clients =
(including public clients) and allow all dynamically registered clients =
access to the client_credentials flow at the token endpoint but only if =
they're asking for a registration-token scope, a scope value which =
hasn't been standardized either. I don't think this is even possible in =
my architecture, and it's certainly not desirable.=20
>=20
> If we were to switch to having the client credentials used directly on =
the registration endpoint, then you get back into the situation that =
OIDC has already tried, and which failed. I see no reason to try the =
same thing again and expect different results.
>=20
> I will admit that it was a little strange when I first pulled the =
TokenServices reference into our RegistrationEndpoint class, but doing =
so greatly simplified everything else. I can see the desire to have an =
ideological purity of "all tokens come from the token endpoint", but =
such purity just doesn't help in this case.=20
>=20
>  -- Justin
>=20
> On 05/30/2013 03:31 PM, Phil Hunt wrote:
>> For this, I would suggest:
>>=20
>> Anonymous, user assisted registration - client registers using the =
client credential flow but may use an administrator (in the case of web =
app) or end-user (uid/password) .  Since resource owner would still =
require separate credential, then the client flow could be used even =
though we are passing end-user creds. Client obtains access token =
limited to registering the new entity.
>>=20
>> Anonymous unassisted registration (no user present) - the only =
solution I can come up with is the client self asserted client_id (e.g. =
UUID) that the token endpoint chooses to accept if scope equals =
"registration" (or whatever the scope is to be for registration).   IMHO =
this should be avoided.
>>=20
>> 3rd Party Assertion - client presents signed assertion in the form of =
JWT or SAML Bearer assertion and exchanges for an access token. Access =
is limited to registering a new entity.
>>=20
>> The value of the access token being short lived or potentially even =
single-use (or limited use, like 3 tries), would be to prevent abuse of =
the registration end-point.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-30, at 11:59 AM, Justin Richer wrote:
>>=20
>>> But this still doesn't address clients who don't have a =
client_secret. Do they now need one in order to talk to the registration =
endpoint? What you're suggesting is that a client use one set of =
credentials to get access tokens and another set of credentials to get =
registrations. This is certainly no simpler.
>>>=20
>>> And this exact functionality was tried, implemented, and rejected as =
too complicated by the OpenID Connect community. I don't see why it'd be =
any different the second time around.
>>>=20
>>> I really don't see any reason to change it.=20
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>>>> It's hard to say what the best solution here is regarding =
clarifications until we get clarity on the issue of registration access =
token.
>>>>=20
>>>> I don't think using a client credential flow to obtain an access =
token to the registration endpoint is complex. It's the normal flow. =20
>>>>=20
>>>> I concede that you are looking at it as using Client Credential to =
get an access token to get a new Client Credential. But that's not =
really what is happening in terms of protocol here. =20
>>>>=20
>>>> If you take the perspective that the client needs to occasionally =
update registration (e.g. because of a pending credential expiry), then =
it is still simple. You use client credential flow to obtain an access =
token to update registration. Then, from the context of the REST API, =
the client credential is just another piece of JSON data.
>>>>=20
>>>> IOW from the REST perspective, it is the registration endpoint that =
is being updated, not the client credential.  The client credential is =
just data in the perspective of REST.
>>>>=20
>>>> I think you may be inferring complexity where there really is none.
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>>>>=20
>>>>> Thanks for clearing up where the confusion was taking place. I had =
tried to make it clear that these were absolutely standard, opaque =
OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, =
but if that's not clear that needs to be updated. This is what the text =
says right now:
>>>>>=20
>>>>> The Client Registration Endpoint MAY accept an Initial Access =
Token in the form of an OAuth 2.0 [RFC6749] access token to limit =
registration to only previously authorized parties. The method by which =
the Initial Access Token is obtained by the registrant is generally =
out-of-band and is out of scope of this specification.
>>>>>=20
>>>>> And:
>>>>>=20
>>>>> The Client Configuration Endpoint is an OAuth 2.0 protected =
resource that is provisioned by the server for a specific client to be =
able to view and update its registered information. The location of this =
endpoint is communicated to the Client through the =
registration_client_uri member of the Client Information Response =
[client-info-response]. The Client MUST use its Registration Access =
Token in all calls to this endpoint as an OAuth 2.0 Bearer Token =
[RFC6750].
>>>>>=20
>>>>> Along with the definitions in the introduction:
>>>>> Registration Access Token
>>>>> OAuth 2.0 Bearer Token issued by the Authorization Server through =
the Client Registration Endpoint that is used to authenticate the caller =
when accessing the Client's registration information at the Client =
Configuration Endpoint. This Access Token is associated with a =
particular registered Client.
>>>>> Initial Access Token
>>>>> An OAuth 2.0 Access Token optionally issued by an Authorization =
Server granting access to its Client Registration Endpoint.
>>>>>=20
>>>>> I'd welcome any proposed changes to the text to make this clearer.
>>>>>=20
>>>>> As to the other suggestion, what you're saying is to use the =
client credentials to get an access token to get the client credentials =
... ? I can see the argument for using the oauth client credentials =
flow, but I think that's far more complicated than an endpoint saying =
"here's a token, go use it", personally. Besides, not all clients have =
credentials at the token endpoint, so it's a bit of a non-starter for a =
large class of clients.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>>=20
>>>>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>>>>> I see what is happening.
>>>>>>=20
>>>>>> I think the reason why I find this spec sooo confusing is that =
the terms imply new token types when they don't.
>>>>>>=20
>>>>>> For example when you say "Registration Access Token" and "Initial =
Access Token" it implies to me that it is a totally new token type (and =
in one case it sorta is). When you read the spec (particularly draft 10) =
it is easy to assume something very different is going on. Hence my push =
back.
>>>>>>=20
>>>>>> It is now clear to me that what you mean to say is *Access Token =
used for initial access* and *Access Token used for registration*.
>>>>>>=20
>>>>>> Why not write the draft to make clear that the registration end =
point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can =
eliminate all of the terminology and lifecycle around access tokens =
except to say the endpoint is accessed by tokens issued based on the =
scope "oauth2:registration".
>>>>>>=20
>>>>>> That only brings issues with the registration token.  The "Access =
Token used for registration" seems to have special lifecycle =
differences.
>>>>>> 1.  Issed by reg endpoint as part of successful registration
>>>>>> 2.  Has a different lifetime than the client credential (whatever =
it is).
>>>>>>=20
>>>>>> Why not again simplify and follow normal OAuth2 pattern and have =
the access token issued for registration be *short* lived.  Each time =
the client wants to either initially register or update its profile it =
must request a normal access token with scope "oauth2:registration".=20
>>>>>>=20
>>>>>> As for client credential expiry, why not simply require the =
client to update its registration before it expires?  Why have a =
long-lived "registration access token" that has to be managed as well?
>>>>>>=20
>>>>>> Maybe now I am completely confused?
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>>>>=20
>>>>>>> The issue is that it has different issuing/lifecycle than =
normal. E.g. Why is it issued by the registration endpoint?
>>>>>>>=20
>>>>>>> Why doesn't the client just request an access token using its =
client credential for the registration endpoint when it wants to update =
its profile?
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>>>>=20
>>>>>>>> The reg access token is a OAuth bearer token that is issued as =
part of the registration response and used to access the new client =
resource for reads and or updates depending on the permissions.
>>>>>>>>=20
>>>>>>>> They are both oauth access tokens.
>>>>>>>>=20
>>>>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  =
wrote:
>>>>>>>>=20
>>>>>>>>> Seriously. The new dyn reg draft introduces two new tokens. =
The initial reg token and the registration access token.=20
>>>>>>>>>=20
>>>>>>>>> As for the latter, the reg access token, my understanding is =
it has nothing to do with an access token. It is issued *after* =
registration to allow reg updates.  Right? I know some are confused =
about this.=20
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> On 2013-05-30, at 8:52, Phil Hunt  =
wrote:
>>>>>>>>>=20
>>>>>>>>>> No different issue. I was concerned about the initial client =
assertion being passed in as authen cred. It is a signed set of client =
reg metadata.=20
>>>>>>>>>>=20
>>>>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> On 2013-05-30, at 8:48, John Bradley  =
wrote:
>>>>>>>>>>=20
>>>>>>>>>>> I think Phil also had some processing reason why a Token =
endpoint or RS wouldn't want to tale the authentication as a header, as =
the processing was easier with them as parameters as they are =
potentially available to different parts of the stack.   That may have =
been mostly around RS, but the principal may apply to the token endpoint =
as well.
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer =
 wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>>>>> BASIC and POST are essentially the same just different =
ways to send the client secret. If an authorization server supports =
both, both should work for any client. So are both methods treated =
differently?
>>>>>>>>>>>>>> I agree, and this was one of my original arguments for =
making this field plural (or plural-able), but there hasn't been WG =
support for that so far.
>>>>>>>>>>>>> I'm not arguing to make it plural. I think the =
authentication method is just "client_secret".
>>>>>>>>>>>> That was also an option that was brought up, but in the =
OIDC WG the counter-argument was (as I recall) that the two are =
syntactically separate and there's a desire to restrict to a single =
type, such as disabling client_secret_post. Basically, to make it =
unambiguous.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_71CE01DD-5735-4B17-8571-67A1D606441A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



Phil

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








On 2013-05-30, at 12:51 PM, Justin Richer wrote:


 =20
    
 =20
  

    I don't understand which access token is being talked about here --
    is this the Initial Registration Token? Because you can already do
    everything below. How you get the Initial Registration token is out
    of scope precisely so that the AS can decide what that means. We can
    add language in the lifecycle discussions to bring up the fact that
    you can get this token from an OAuth flow, if you think that'll help
    clear things up.

    

    However, the client doesn't register using the client credential
    flow at all -- it registers using a POST to the registration
    endpoint, and that POST might have an OAuth token attached to it.
    How the client got that OAuth token is, again, out of scope. The
    client could have done some other OAuth flow (any OAuth flow) to get
    a hold of the token, but how is it supposed to get an OAuth token at
    an AS it hasn't been registered with? 

    

    Now, if you're talking about the Registration Access Token, though,
    that makes less sense to me. The client *has* to register first
    before it can get *anything* from the token endpoint. What you're
    suggesting is that all clients be given access to the token endpoint
    with the client credentials flow for the purposes of retrieving the
    Registration Access Token, unless I misread things. You probably
    don't want the client getting other scopes from the token endpoint
    using the client credentials flow, as it'd be an enormous security
    risk. Thing is, I don't think I can implement that level of
    separation in my app stack, and I haven't seen any others that do
    that. Separating access to different endpoints based on OAuth tokens
    (and the scopes attached) is par for the course, though.

    

    Let me run down how it works in our own setup. When a client
    registers, we create a new token (using a TokenServices class) that
    has a special scope, "registration-token". This token is tied to the
    client_id to which it was issued. Clients cannot get tokens with
    this scope through the usual Token Endpoint means, by design. All of
    the Client Configuration Endpoint URLs are protected such that they
    require access from a valid token with the scope
    "registration-token", and the client_id tied to that token MUST
    match the client_id in the URL. Each client is limited to the OAuth
    flows (grant_types and response_types) that it's allowed to call
    from the token endpoint. All of this is specific to our
    implementation, but I can speak with some authority that it's at
    least implementable this way. This method lets us do public clients,
    confidential clients, public-key clients (that use JWT assertions to
    call the token endpoint), and all different OAuth flows. 

    

    If we were to switch things to what you're recommending (using
    client credentials to get the equivalent of the Registration Access
    Token), I would need to issue some form of client credentials to all
    clients (including public clients) and allow all dynamically
    registered clients access to the client_credentials flow at the
    token endpoint but only if they're asking for a registration-token
    scope, a scope value which hasn't been standardized either. I don't
    think this is even possible in my architecture, and it's certainly
    not desirable. 

    

    If we were to switch to having the client credentials used directly
    on the registration endpoint, then you get back into the situation
    that OIDC has already tried, and which failed. I see no reason to
    try the same thing again and expect different results.

    

    I will admit that it was a little strange when I first pulled the
    TokenServices reference into our RegistrationEndpoint class, but
    doing so greatly simplified everything else. I can see the desire to
    have an ideological purity of "all tokens come from the token
    endpoint", but such purity just doesn't help in this case. 

    

     -- Justin

    

    
On 05/30/2013 03:31 PM, Phil Hunt
      wrote:

    

    

      
      For this, I would suggest:
      


      

      
Anonymous, user assisted registration - client registers
        using the client credential flow but may use an administrator
        (in the case of web app) or end-user (uid/password) . =
 Since
        resource owner would still require separate credential, then the
        client flow could be used even though we are passing end-user
        creds. Client obtains access token limited to registering the
        new entity.

      


      

      
Anonymous unassisted registration (no user present) - the
        only solution I can come up with is the client self asserted
        client_id (e.g. UUID) that the token endpoint chooses to accept
        if scope equals "registration" (or whatever the scope is to be
        for registration).   IMHO this should be avoided.

      


      

      
3rd Party Assertion - client presents signed assertion in the
        form of JWT or SAML Bearer assertion and exchanges for an access
        token. Access is limited to registering a new entity.

      


      

      
The value of the access token being short lived or
        potentially even single-use (or limited use, like 3 tries),
        would be to prevent abuse of the registration end-point.

      


        
        

        

          
On 2013-05-30, at 11:59 AM, Justin Richer wrote:

          

          

            
 But this still
              doesn't address clients who don't have a client_secret. Do
              they now need one in order to talk to the registration
              endpoint? What you're suggesting is that a client use one
              set of credentials to get access tokens and another set of
              credentials to get registrations. This is certainly no
              simpler.

              

              And this exact functionality was tried, implemented, and
              rejected as too complicated by the OpenID Connect
              community. I don't see why it'd be any different the
              second time around.

              

              I really don't see any reason to change it. 

              

               -- Justin

              

              
On 05/30/2013 02:56 PM, =
Phil
                Hunt wrote:

              

              
 It's hard to say what the best solution
                here is regarding clarifications until we get clarity on
                the issue of registration access token.
                


                

                
I don't think using a client credential flow to
                  obtain an access token to the registration endpoint is
                  complex. It's the normal flow.  

                


                

                
I concede that you are looking at it as using
                  Client Credential to get an access token to get a new
                  Client Credential. But that's not really what is
                  happening in terms of protocol here.  

                


                

                
If you take the perspective that the client needs
                  to occasionally update registration (e.g. because of a
                  pending credential expiry), then it is still simple.
                  You use client credential flow to obtain an access
                  token to update registration. Then, from the context
                  of the REST API, the client credential is just another
                  piece of JSON data.

                


                

                
IOW from the REST perspective, it is the
                  registration endpoint that is being updated, not the
                  client credential.  The client credential is just =
data
                  in the perspective of REST.

                


                

                
I think you may be inferring complexity where there
                  really is none.

                


                

                

                  
                  

                  

                    
On 2013-05-30, at 11:33 AM, Justin Richer
                      wrote:

                    

                    

                      
 Thanks =
for
                        clearing up where the confusion was taking
                        place. I had tried to make it clear that these
                        were absolutely standard, opaque OAuth2 bearer
                        tokens and absolutely standard OAuth2-protected
                        endpoints, but if that's not clear that needs to
                        be updated. This is what the text says right
                        now:

                        

                        
The Client Registration Endpoint MAY
                          accept an Initial Access Token in the form of
                          an OAuth


                            2.0  [RFC6749]=

                          access token to limit registration to only
                          previously authorized parties. The method by
                          which the Initial Access Token is obtained by
                          the registrant is generally out-of-band and is
                          out of scope of this specification.

                        

                        

                        And:

                        

                        
The Client Configuration Endpoint is
                          an OAuth 2.0 protected resource that is
                          provisioned by the server for a specific
                          client to be able to view and update its
                          registered information. The location of this
                          endpoint is communicated to the Client through
                          the registration_client_uri
                          member of the Client


                            Information Response [client-info-response].
                          The Client MUST use its Registration Access
                          Token in all calls to this endpoint as an OAuth


                            2.0 Bearer Token [RFC6750].

                        

                        

                        Along with the definitions in the =
introduction:

                        

                          

                            
Registration Access Token

                            
OAuth 2.0 =
Bearer
                              Token issued by the Authorization Server
                              through the Client Registration Endpoint
                              that is used to authenticate the caller
                              when accessing the Client's registration
                              information at the Client Configuration
                              Endpoint. This Access Token is associated
                              with a particular registered Client.

                            
Initial Access Token

                            
An OAuth 2.0
                              Access Token optionally issued by an
                              Authorization Server granting access to
                              its Client Registration Endpoint.

                          

                        

                        

                        I'd welcome any proposed changes to the text to
                        make this clearer.

                        

                        As to the other suggestion, what you're saying
                        is to use the client credentials to get an
                        access token to get the client credentials ... ?
                        I can see the argument for using the oauth
                        client credentials flow, but I think that's far
                        more complicated than an endpoint saying "here's
                        a token, go use it", personally. Besides, not
                        all clients have credentials at the token
                        endpoint, so it's a bit of a non-starter for a
                        large class of clients.

                        

                         -- Justin

                        

                        

                        
On 05/30/2013 =
01:55
                          PM, Phil Hunt wrote:

                        

                        

                          
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms =
imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access =
Token" it implies to me that it is a totally new token type (and in one =
case it sorta is). When you read the spec (particularly draft 10) it is =
easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used =
for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is =
just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate =
all of the terminology and lifecycle around access tokens except to say =
the endpoint is accessed by tokens issued based on the scope =
"oauth2:registration".

That only brings issues with the registration token.  The "Access Token =
used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it =
is).

Why not again simplify and follow normal OAuth2 pattern and have the =
access token issued for registration be *short* lived.  Each time the =
client wants to either initially register or update its profile it must =
request a normal access token with scope "oauth2:registration".=20

As for client credential expiry, why not simply require the client to =
update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                          

                            
The issue is that it has =
different issuing/lifecycle than normal. E.g. Why is it issued by the =
registration endpoint?

Why doesn't the client just request an access token using its client =
credential for the registration endpoint when it wants to update its =
profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                            

                              
The reg access token is a =
OAuth bearer token that is issued as part of the registration response =
and used to access the new client resource for reads and or updates =
depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                              

                                
Seriously. The new dyn =
reg draft introduces two new tokens. The initial reg token and the =
registration access token.=20

As for the latter, the reg access token, my understanding is it has =
nothing to do with an access token. It is issued *after* registration to =
allow reg updates.  Right? I know some are confused about this.=20

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                                

                                  
No different issue. I =
was concerned about the initial client assertion being passed in as =
authen cred. It is a signed set of client reg metadata.=20

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                                  

                                    
I think Phil also had =
some processing reason why a Token endpoint or RS wouldn't want to tale =
the authentication as a header, as the processing was easier with them =
as parameters as they are potentially available to different parts of =
the stack.   That may have been mostly around RS, but the principal may =
apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                                    

                                      

                                        

                                          

                                            
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the =
client secret. If an authorization server supports both, both should =
work for any client. So are both methods treated differently?


                                          

                                          
I agree, and =
this was one of my original arguments for making this field plural (or =
plural-able), but there hasn't been WG support for that so far.


                                        

                                        
I'm not arguing =
to make it plural. I think the authentication method is just =
"client_secret".


                                      

                                      
That was also an =
option that was brought up, but in the OIDC WG the counter-argument was =
(as I recall) that the two are syntactically separate and there's a =
desire to restrict to a single type, such as disabling =
client_secret_post. Basically, to make it unambiguous.


                                    

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


                                  

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


                                

                              

                            

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


                          

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


                        

                        

                      

                    

                  

                  

                

              

              

            

          

        

        

      

    

    

  




=

--Apple-Mail=_71CE01DD-5735-4B17-8571-67A1D606441A--

From jricher@mitre.org  Thu May 30 14:10:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381A121F9079 for ; Thu, 30 May 2013 14:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.908
X-Spam-Level: 
X-Spam-Status: No, score=-4.908 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbjcyz4udXGz for ; Thu, 30 May 2013 14:10:14 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2399C21F85B4 for ; Thu, 30 May 2013 14:10:14 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 246051F03B9; Thu, 30 May 2013 17:10:13 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C994C1F0712; Thu, 30 May 2013 17:10:12 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 17:10:12 -0400
Message-ID: <51A7C00B.6050409@mitre.org>
Date: Thu, 30 May 2013 17:09:31 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>
In-Reply-To: <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>
Content-Type: multipart/alternative; boundary="------------090707060605010809040506"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 21:10:20 -0000

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

OK, I think see part of the hang up. I have not seen the scenario that 
you describe, where you trade a 3rd party token for a "local" token. I 
have seen where access tokens are federated directly at the PR. 
(Introspection lets you do some good things with that pattern.) But 
that's neither here nor there, as you can already do what you're asking 
for and I think I can clear things up:

In your case, the "3rd party bearer assertion" is simply *not* the 
Initial Registration Token. It's an assertion that can be used to *get* 
an Initial Registration Token. The token that you get from the Token 
Endpoint, in your case, would be "local" from your own AS. Your 
registration endpoint would look at this token on the way in, know how 
to validate it, do whatever else it wants to with it, and process the 
registration. Then it would issue a Registration Access Token that to 
the registering client to use at the RESTful endpoint. Incidentally, 
that token would also be "local", just like before. How you (the 
client/developer) get the actual Initial Registration Token is 
completely and forever out of scope for the Dynamic Registration spec.


This all still fits with the current definitions as they are. You don't 
have to use federated tokens if you don't want to. I can still use them 
if I want to. Everybody's happy! And this is all because we are not 
defining any content or semantics tied to the processing of the Initial 
Registration Token or calling it an Assertion or anything -- it's up to 
the AS to process it however it would normally process an OAuth Access 
token. So if your AS needs a local token, then you need to use a local 
token. If you don't want to use structured foreign tokens as your 
Initial Registration Tokens, don't. But that shouldn't preclude others 
of us from doing so.

If you think it would be helpful, I can add language to the lifecycle 
discussion to clarify that the Initial Registration Token can be gotten 
through any number of means, not just the manual-portal approach that's 
talked about now. Or if you want to write up this specific use case we 
can add it as another concrete example.

I will close by pointing out that I have *never* proposed that we 
dictate that the Registration Endpoint have to accept and process 
federated tokens, and it would be ludicrous to do so. I have been and 
still am committed to the Initial Registration Token and the 
Registration Access Token being plain old opaque-to-the-client OAuth 2 
tokens.

I think it's possible that you're still conflating the work I'm doing 
with the BB+ *extension* to dynamic registration with the dynamic 
registration document itself. I have never suggested that we pull all 
the extended BB+ stuff down into Dyn Reg, and in fact I think quite the 
opposite as I don't believe it's as generally applicable without the 
larger BB+ stack (which includes discovery as well as reliance on policy 
and other frameworks).

  -- Justin

On 05/30/2013 03:54 PM, Phil Hunt wrote:
> Justin,
>
> So far, every time an OAuth server has accepted a 3rd party token it 
> has been a bearer assertion. The common pattern is to exchange that 
> assertion for a an access token issued by the local server for the 
> local resource endpoint.
>
> That's the pattern I am trying to follow.
>
> Going this way means we do not have to define the initial registration 
> token.
>
> If however, you really want to use the initial registration token AS 
> an access token, you are taking us into the question of using 
> federated access tokens.  I prefer not to do that here.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>
>> I don't understand which access token is being talked about here -- 
>> is this the Initial Registration Token? Because you can already do 
>> everything below. How you get the Initial Registration token is out 
>> of scope precisely so that the AS can decide what that means. We can 
>> add language in the lifecycle discussions to bring up the fact that 
>> you can get this token from an OAuth flow, if you think that'll help 
>> clear things up.
>>
>> However, the client doesn't register using the client credential flow 
>> at all -- it registers using a POST to the registration endpoint, and 
>> that POST might have an OAuth token attached to it. How the client 
>> got that OAuth token is, again, out of scope. The client could have 
>> done some other OAuth flow (any OAuth flow) to get a hold of the 
>> token, but how is it supposed to get an OAuth token at an AS it 
>> hasn't been registered with?
>>
>> Now, if you're talking about the Registration Access Token, though, 
>> that makes less sense to me. The client *has* to register first 
>> before it can get *anything* from the token endpoint. What you're 
>> suggesting is that all clients be given access to the token endpoint 
>> with the client credentials flow for the purposes of retrieving the 
>> Registration Access Token, unless I misread things. You probably 
>> don't want the client getting other scopes from the token endpoint 
>> using the client credentials flow, as it'd be an enormous security 
>> risk. Thing is, I don't think I can implement that level of 
>> separation in my app stack, and I haven't seen any others that do 
>> that. Separating access to different endpoints based on OAuth tokens 
>> (and the scopes attached) is par for the course, though.
>>
>> Let me run down how it works in our own setup. When a client 
>> registers, we create a new token (using a TokenServices class) that 
>> has a special scope, "registration-token". This token is tied to the 
>> client_id to which it was issued. Clients cannot get tokens with this 
>> scope through the usual Token Endpoint means, by design. All of the 
>> Client Configuration Endpoint URLs are protected such that they 
>> require access from a valid token with the scope 
>> "registration-token", and the client_id tied to that token MUST match 
>> the client_id in the URL. Each client is limited to the OAuth flows 
>> (grant_types and response_types) that it's allowed to call from the 
>> token endpoint. All of this is specific to our implementation, but I 
>> can speak with some authority that it's at least implementable this 
>> way. This method lets us do public clients, confidential clients, 
>> public-key clients (that use JWT assertions to call the token 
>> endpoint), and all different OAuth flows.
>>
>> If we were to switch things to what you're recommending (using client 
>> credentials to get the equivalent of the Registration Access Token), 
>> I would need to issue some form of client credentials to all clients 
>> (including public clients) and allow all dynamically registered 
>> clients access to the client_credentials flow at the token endpoint 
>> but only if they're asking for a registration-token scope, a scope 
>> value which hasn't been standardized either. I don't think this is 
>> even possible in my architecture, and it's certainly not desirable.
>>
>> If we were to switch to having the client credentials used directly 
>> on the registration endpoint, then you get back into the situation 
>> that OIDC has already tried, and which failed. I see no reason to try 
>> the same thing again and expect different results.
>>
>> I will admit that it was a little strange when I first pulled the 
>> TokenServices reference into our RegistrationEndpoint class, but 
>> doing so greatly simplified everything else. I can see the desire to 
>> have an ideological purity of "all tokens come from the token 
>> endpoint", but such purity just doesn't help in this case.
>>
>>  -- Justin
>>
>> On 05/30/2013 03:31 PM, Phil Hunt wrote:
>>> For this, I would suggest:
>>>
>>> Anonymous, user assisted registration - client registers using the 
>>> client credential flow but may use an administrator (in the case of 
>>> web app) or end-user (uid/password) .  Since resource owner would 
>>> still require separate credential, then the client flow could be 
>>> used even though we are passing end-user creds. Client obtains 
>>> access token limited to registering the new entity.
>>>
>>> Anonymous unassisted registration (no user present) - the only 
>>> solution I can come up with is the client self asserted client_id 
>>> (e.g. UUID) that the token endpoint chooses to accept if scope 
>>> equals "registration" (or whatever the scope is to be for 
>>> registration).   IMHO this should be avoided.
>>>
>>> 3rd Party Assertion - client presents signed assertion in the form 
>>> of JWT or SAML Bearer assertion and exchanges for an access token. 
>>> Access is limited to registering a new entity.
>>>
>>> The value of the access token being short lived or potentially even 
>>> single-use (or limited use, like 3 tries), would be to prevent abuse 
>>> of the registration end-point.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>> On 2013-05-30, at 11:59 AM, Justin Richer wrote:
>>>
>>>> But this still doesn't address clients who don't have a 
>>>> client_secret. Do they now need one in order to talk to the 
>>>> registration endpoint? What you're suggesting is that a client use 
>>>> one set of credentials to get access tokens and another set of 
>>>> credentials to get registrations. This is certainly no simpler.
>>>>
>>>> And this exact functionality was tried, implemented, and rejected 
>>>> as too complicated by the OpenID Connect community. I don't see why 
>>>> it'd be any different the second time around.
>>>>
>>>> I really don't see any reason to change it.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>>>>> It's hard to say what the best solution here is regarding 
>>>>> clarifications until we get clarity on the issue of registration 
>>>>> access token.
>>>>>
>>>>> I don't think using a client credential flow to obtain an access 
>>>>> token to the registration endpoint is complex. It's the normal flow.
>>>>>
>>>>> I concede that you are looking at it as using Client Credential to 
>>>>> get an access token to get a new Client Credential. But that's not 
>>>>> really what is happening in terms of protocol here.
>>>>>
>>>>> If you take the perspective that the client needs to occasionally 
>>>>> update registration (e.g. because of a pending credential expiry), 
>>>>> then it is still simple. You use client credential flow to obtain 
>>>>> an access token to update registration. Then, from the context of 
>>>>> the REST API, the client credential is just another piece of JSON 
>>>>> data.
>>>>>
>>>>> IOW from the REST perspective, it is the registration endpoint 
>>>>> that is being updated, not the client credential.  The client 
>>>>> credential is just data in the perspective of REST.
>>>>>
>>>>> I think you may be inferring complexity where there really is none.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>>>>>
>>>>>> Thanks for clearing up where the confusion was taking place. I 
>>>>>> had tried to make it clear that these were absolutely standard, 
>>>>>> opaque OAuth2 bearer tokens and absolutely standard 
>>>>>> OAuth2-protected endpoints, but if that's not clear that needs to 
>>>>>> be updated. This is what the text says right now:
>>>>>>
>>>>>>     The Client Registration Endpoint MAY accept an Initial Access
>>>>>>     Token in the form of an OAuth 2.0
>>>>>>     
>>>>>>     [RFC6749] access token to limit registration to only
>>>>>>     previously authorized parties. The method by which the
>>>>>>     Initial Access Token is obtained by the registrant is
>>>>>>     generally out-of-band and is out of scope of this specification.
>>>>>>
>>>>>>
>>>>>> And:
>>>>>>
>>>>>>     The Client Configuration Endpoint is an OAuth 2.0 protected
>>>>>>     resource that is provisioned by the server for a specific
>>>>>>     client to be able to view and update its registered
>>>>>>     information. The location of this endpoint is communicated to
>>>>>>     the Client through the registration_client_uri member of the
>>>>>>     Client Information Response
>>>>>>     
>>>>>>     [client-info-response]. The Client MUST use its Registration
>>>>>>     Access Token in all calls to this endpoint as an OAuth 2.0
>>>>>>     Bearer Token
>>>>>>     
>>>>>>     [RFC6750].
>>>>>>
>>>>>>
>>>>>> Along with the definitions in the introduction:
>>>>>>
>>>>>>     Registration Access Token
>>>>>>         OAuth 2.0 Bearer Token issued by the Authorization Server
>>>>>>         through the Client Registration Endpoint that is used to
>>>>>>         authenticate the caller when accessing the Client's
>>>>>>         registration information at the Client Configuration
>>>>>>         Endpoint. This Access Token is associated with a
>>>>>>         particular registered Client.
>>>>>>     Initial Access Token
>>>>>>         An OAuth 2.0 Access Token optionally issued by an
>>>>>>         Authorization Server granting access to its Client
>>>>>>         Registration Endpoint.
>>>>>>
>>>>>>
>>>>>> I'd welcome any proposed changes to the text to make this clearer.
>>>>>>
>>>>>> As to the other suggestion, what you're saying is to use the 
>>>>>> client credentials to get an access token to get the client 
>>>>>> credentials ... ? I can see the argument for using the oauth 
>>>>>> client credentials flow, but I think that's far more complicated 
>>>>>> than an endpoint saying "here's a token, go use it", personally. 
>>>>>> Besides, not all clients have credentials at the token endpoint, 
>>>>>> so it's a bit of a non-starter for a large class of clients.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>>>>>> I see what is happening.
>>>>>>>
>>>>>>> I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.
>>>>>>>
>>>>>>> For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.
>>>>>>>
>>>>>>> It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.
>>>>>>>
>>>>>>> Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".
>>>>>>>
>>>>>>> That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
>>>>>>> 1.  Issed by reg endpoint as part of successful registration
>>>>>>> 2.  Has a different lifetime than the client credential (whatever it is).
>>>>>>>
>>>>>>> Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration".
>>>>>>>
>>>>>>> As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?
>>>>>>>
>>>>>>> Maybe now I am completely confused?
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>>>>>
>>>>>>>> The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?
>>>>>>>>
>>>>>>>> Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>>>>>
>>>>>>>>> The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.
>>>>>>>>>
>>>>>>>>> They are both oauth access tokens.
>>>>>>>>>
>>>>>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  wrote:
>>>>>>>>>
>>>>>>>>>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token.
>>>>>>>>>>
>>>>>>>>>> As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this.
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> On 2013-05-30, at 8:52, Phil Hunt  wrote:
>>>>>>>>>>
>>>>>>>>>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata.
>>>>>>>>>>>
>>>>>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> On 2013-05-30, at 8:48, John Bradley  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?
>>>>>>>>>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.
>>>>>>>>>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret".
>>>>>>>>>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OAuth mailing 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
>>>>>>
>>>>>
>>>>
>>>
>>
>


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


  
    
  
  
    OK, I think see part of the hang up. I have not seen the scenario
    that you describe, where you trade a 3rd party token for a "local"
    token. I have seen where access tokens are federated directly at the
    PR. (Introspection lets you do some good things with that pattern.)
    But that's neither here nor there, as you can already do what you're
    asking for and I think I can clear things up:

    

    In your case, the "3rd party bearer assertion" is simply *not* the
    Initial Registration Token. It's an assertion that can be used to
    *get* an Initial Registration Token. The token that you get from the
    Token Endpoint, in your case, would be "local" from your own AS.
    Your registration endpoint would look at this token on the way in,
    know how to validate it, do whatever else it wants to with it, and
    process the registration. Then it would issue a Registration Access
    Token that to the registering client to use at the RESTful endpoint.
    Incidentally, that token would also be "local", just like before.
    How you (the client/developer) get the actual Initial Registration
    Token is completely and forever out of scope for the Dynamic
    Registration spec. 

    

    

    This all still fits with the current definitions as they are. You
    don't have to use federated tokens if you don't want to. I can still
    use them if I want to. Everybody's happy! And this is all because we
    are not defining any content or semantics tied to the processing of
    the Initial Registration Token or calling it an Assertion or
    anything -- it's up to the AS to process it however it would
    normally process an OAuth Access token. So if your AS needs a local
    token, then you need to use a local token. If you don't want to use
    structured foreign tokens as your Initial Registration Tokens,
    don't. But that shouldn't preclude others of us from doing so.

    

    If you think it would be helpful, I can add language to the
    lifecycle discussion to clarify that the Initial Registration Token
    can be gotten through any number of means, not just the
    manual-portal approach that's talked about now. Or if you want to
    write up this specific use case we can add it as another concrete
    example. 

    

    I will close by pointing out that I have *never* proposed that we
    dictate that the Registration Endpoint have to accept and process
    federated tokens, and it would be ludicrous to do so. I have been
    and still am committed to the Initial Registration Token and the
    Registration Access Token being plain old opaque-to-the-client OAuth
    2 tokens. 

    

    I think it's possible that you're still conflating the work I'm
    doing with the BB+ *extension* to dynamic registration with the
    dynamic registration document itself. I have never suggested that we
    pull all the extended BB+ stuff down into Dyn Reg, and in fact I
    think quite the opposite as I don't believe it's as generally
    applicable without the larger BB+ stack (which includes discovery as
    well as reliance on policy and other frameworks). 

    

     -- Justin

    

    
On 05/30/2013 03:54 PM, Phil Hunt
      wrote:

    

    

      
      Justin,
      


      

      
So far, every time an OAuth server has accepted a 3rd party
        token it has been a bearer assertion. The common pattern is to
        exchange that assertion for a an access token issued by the
        local server for the local resource endpoint.

      


      

      
That's the pattern I am trying to follow.

      


      

      
Going this way means we do not have to define the initial
        registration token.

      


      

      
If however, you really want to use the initial registration
        token AS an access token, you are taking us into the question of
        using federated access tokens.  I prefer not to do that here.

      


      

      

        

          

            
            

            

              
On 2013-05-30, at 12:51 PM, Justin Richer wrote:

              

              

                
 I don't
                  understand which access token is being talked about
                  here -- is this the Initial Registration Token?
                  Because you can already do everything below. How you
                  get the Initial Registration token is out of scope
                  precisely so that the AS can decide what that means.
                  We can add language in the lifecycle discussions to
                  bring up the fact that you can get this token from an
                  OAuth flow, if you think that'll help clear things up.

                  

                  However, the client doesn't register using the client
                  credential flow at all -- it registers using a POST to
                  the registration endpoint, and that POST might have an
                  OAuth token attached to it. How the client got that
                  OAuth token is, again, out of scope. The client could
                  have done some other OAuth flow (any OAuth flow) to
                  get a hold of the token, but how is it supposed to get
                  an OAuth token at an AS it hasn't been registered
                  with? 

                  

                  Now, if you're talking about the Registration Access
                  Token, though, that makes less sense to me. The client
                  *has* to register first before it can get *anything*
                  from the token endpoint. What you're suggesting is
                  that all clients be given access to the token endpoint
                  with the client credentials flow for the purposes of
                  retrieving the Registration Access Token, unless I
                  misread things. You probably don't want the client
                  getting other scopes from the token endpoint using the
                  client credentials flow, as it'd be an enormous
                  security risk. Thing is, I don't think I can implement
                  that level of separation in my app stack, and I
                  haven't seen any others that do that. Separating
                  access to different endpoints based on OAuth tokens
                  (and the scopes attached) is par for the course,
                  though.

                  

                  Let me run down how it works in our own setup. When a
                  client registers, we create a new token (using a
                  TokenServices class) that has a special scope,
                  "registration-token". This token is tied to the
                  client_id to which it was issued. Clients cannot get
                  tokens with this scope through the usual Token
                  Endpoint means, by design. All of the Client
                  Configuration Endpoint URLs are protected such that
                  they require access from a valid token with the scope
                  "registration-token", and the client_id tied to that
                  token MUST match the client_id in the URL. Each client
                  is limited to the OAuth flows (grant_types and
                  response_types) that it's allowed to call from the
                  token endpoint. All of this is specific to our
                  implementation, but I can speak with some authority
                  that it's at least implementable this way. This method
                  lets us do public clients, confidential clients,
                  public-key clients (that use JWT assertions to call
                  the token endpoint), and all different OAuth flows. 

                  

                  If we were to switch things to what you're
                  recommending (using client credentials to get the
                  equivalent of the Registration Access Token), I would
                  need to issue some form of client credentials to all
                  clients (including public clients) and allow all
                  dynamically registered clients access to the
                  client_credentials flow at the token endpoint but only
                  if they're asking for a registration-token scope, a
                  scope value which hasn't been standardized either. I
                  don't think this is even possible in my architecture,
                  and it's certainly not desirable. 

                  

                  If we were to switch to having the client credentials
                  used directly on the registration endpoint, then you
                  get back into the situation that OIDC has already
                  tried, and which failed. I see no reason to try the
                  same thing again and expect different results.

                  

                  I will admit that it was a little strange when I first
                  pulled the TokenServices reference into our
                  RegistrationEndpoint class, but doing so greatly
                  simplified everything else. I can see the desire to
                  have an ideological purity of "all tokens come from
                  the token endpoint", but such purity just doesn't help
                  in this case. 

                  

                   -- Justin

                  

                  
On 05/30/2013 03:31 PM,
                    Phil Hunt wrote:

                  

                  
 For this, I would suggest:
                    


                    

                    
Anonymous, user assisted registration - client
                      registers using the client credential flow but may
                      use an administrator (in the case of web app) or
                      end-user (uid/password) .  Since resource owner
                      would still require separate credential, then the
                      client flow could be used even though we are
                      passing end-user creds. Client obtains access
                      token limited to registering the new entity.

                    


                    

                    
Anonymous unassisted registration (no user
                      present) - the only solution I can come up with is
                      the client self asserted client_id (e.g. UUID)
                      that the token endpoint chooses to accept if scope
                      equals "registration" (or whatever the scope is to
                      be for registration).   IMHO this should be
                      avoided.

                    


                    

                    
3rd Party Assertion - client presents signed
                      assertion in the form of JWT or SAML Bearer
                      assertion and exchanges for an access token.
                      Access is limited to registering a new entity.

                    


                    

                    
The value of the access token being short lived
                      or potentially even single-use (or limited use,
                      like 3 tries), would be to prevent abuse of the
                      registration end-point.

                    


                      
                      

                      

                        
On 2013-05-30, at 11:59 AM, Justin Richer
                          wrote:

                        

                        

                          
 But
                            this still doesn't address clients who don't
                            have a client_secret. Do they now need one
                            in order to talk to the registration
                            endpoint? What you're suggesting is that a
                            client use one set of credentials to get
                            access tokens and another set of credentials
                            to get registrations. This is certainly no
                            simpler.

                            

                            And this exact functionality was tried,
                            implemented, and rejected as too complicated
                            by the OpenID Connect community. I don't see
                            why it'd be any different the second time
                            around.

                            

                            I really don't see any reason to change it.
                            

                            

                             -- Justin

                            

                            
On 05/30/2013
                              02:56 PM, Phil Hunt wrote:

                            

                            
 It's hard to say what the
                              best solution here is regarding
                              clarifications until we get clarity on the
                              issue of registration access token.
                              


                              

                              
I don't think using a client
                                credential flow to obtain an access
                                token to the registration endpoint is
                                complex. It's the normal flow.  

                              


                              

                              
I concede that you are looking at it
                                as using Client Credential to get an
                                access token to get a new Client
                                Credential. But that's not really what
                                is happening in terms of protocol here.
                                 

                              


                              

                              
If you take the perspective that the
                                client needs to occasionally update
                                registration (e.g. because of a pending
                                credential expiry), then it is still
                                simple. You use client credential flow
                                to obtain an access token to update
                                registration. Then, from the context of
                                the REST API, the client credential is
                                just another piece of JSON data.

                              


                              

                              
IOW from the REST perspective, it is
                                the registration endpoint that is being
                                updated, not the client credential.  The
                                client credential is just data in the
                                perspective of REST.

                              


                              

                              
I think you may be inferring
                                complexity where there really is none.

                              


                              

                              

                                
                                

                                

                                  
On 2013-05-30, at 11:33 AM,
                                    Justin Richer wrote:

                                  

                                  

                                    
 Thanks for
                                      clearing up where the confusion
                                      was taking place. I had tried to
                                      make it clear that these were
                                      absolutely standard, opaque OAuth2
                                      bearer tokens and absolutely
                                      standard OAuth2-protected
                                      endpoints, but if that's not clear
                                      that needs to be updated. This is
                                      what the text says right now:

                                      

                                      
The Client
                                        Registration Endpoint MAY accept
                                        an Initial Access Token in the
                                        form of an OAuth




                                          2.0  [RFC6749]
                                        access token to limit
                                        registration to only previously
                                        authorized parties. The method
                                        by which the Initial Access
                                        Token is obtained by the
                                        registrant is generally
                                        out-of-band and is out of scope
                                        of this specification.

                                      

                                      

                                      And:

                                      

                                      
The Client
                                        Configuration Endpoint is an
                                        OAuth 2.0 protected resource
                                        that is provisioned by the
                                        server for a specific client to
                                        be able to view and update its
                                        registered information. The
                                        location of this endpoint is
                                        communicated to the Client
                                        through the registration_client_uri
                                        member of the Client




                                          Information Response [client-info-response].
                                        The Client MUST use its
                                        Registration Access Token in all
                                        calls to this endpoint as an OAuth




                                          2.0 Bearer Token [RFC6750].

                                      

                                      

                                      Along with the definitions in the
                                      introduction:

                                      

                                        

                                          
Registration Access Token

                                          
OAuth

                                            2.0 Bearer Token issued by
                                            the Authorization Server
                                            through the Client
                                            Registration Endpoint that
                                            is used to authenticate the
                                            caller when accessing the
                                            Client's registration
                                            information at the Client
                                            Configuration Endpoint. This
                                            Access Token is associated
                                            with a particular registered
                                            Client.

                                          
Initial Access Token

                                          
An
                                            OAuth 2.0 Access Token
                                            optionally issued by an
                                            Authorization Server
                                            granting access to its
                                            Client Registration
                                            Endpoint.

                                        

                                      

                                      

                                      I'd welcome any proposed changes
                                      to the text to make this clearer.

                                      

                                      As to the other suggestion, what
                                      you're saying is to use the client
                                      credentials to get an access token
                                      to get the client credentials ...
                                      ? I can see the argument for using
                                      the oauth client credentials flow,
                                      but I think that's far more
                                      complicated than an endpoint
                                      saying "here's a token, go use
                                      it", personally. Besides, not all
                                      clients have credentials at the
                                      token endpoint, so it's a bit of a
                                      non-starter for a large class of
                                      clients.

                                      

                                       -- Justin

                                      

                                      

                                      
On
                                        05/30/2013 01:55 PM, Phil Hunt
                                        wrote:

                                      

                                      

                                        
I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration".

That only brings issues with the registration token.  The "Access Token used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it is).

Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived.  Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". 

As for client credential expiry, why not simply require the client to update its registration before it expires?  Why have a long-lived "registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                                        

                                          
The issue is that it has different issuing/lifecycle than normal. E.g. Why is it issued by the registration endpoint?

Why doesn't the client just request an access token using its client credential for the registration endpoint when it wants to update its profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                                          

                                            
The reg access token is a OAuth bearer token that is issued as part of the registration response and used to access the new client resource for reads and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



                                            

                                              
Seriously. The new dyn reg draft introduces two new tokens. The initial reg token and the registration access token. 

As for the latter, the reg access token, my understanding is it has nothing to do with an access token. It is issued *after* registration to allow reg updates.  Right? I know some are confused about this. 

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> wrote:



                                              

                                                
No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                                                

                                                  
I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                                                  

                                                    

                                                      

                                                        

                                                          
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?


                                                        

                                                        
I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.


                                                      

                                                      
I'm not arguing to make it plural. I think the authentication method is just "client_secret".


                                                    

                                                    
That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.


                                                  

                                                  
_______________________________________________
OAuth mailing 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


                                      

                                      

                                    

                                  

                                

                                

                              

                            

                            

                          

                        

                      

                      

                    

                  

                  

                

              

            

            

          

        

      

    

    

  


--------------090707060605010809040506--

From phil.hunt@oracle.com  Thu May 30 14:26:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2553521F9307 for ; Thu, 30 May 2013 14:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.411
X-Spam-Level: 
X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPHZB9lsWad7 for ; Thu, 30 May 2013 14:26:06 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85621F9354 for ; Thu, 30 May 2013 14:26:05 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4ULQ3V7015197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 21:26:04 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4ULQ2Bm012651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 21:26:03 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4ULQ2gl003583; Thu, 30 May 2013 21:26:02 GMT
Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 14:26:00 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DEC5A9D7-8886-4D3F-8D67-E3DC59CA2E7B"
From: Phil Hunt 
In-Reply-To: <51A7C00B.6050409@mitre.org>
Date: Thu, 30 May 2013 14:25:58 -0700
Message-Id: <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 21:26:12 -0000

--Apple-Mail=_DEC5A9D7-8886-4D3F-8D67-E3DC59CA2E7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

See below.
Phil

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





On 2013-05-30, at 2:09 PM, Justin Richer wrote:

> OK, I think see part of the hang up. I have not seen the scenario that =
you describe, where you trade a 3rd party token for a "local" token. I =
have seen where access tokens are federated directly at the PR. =
(Introspection lets you do some good things with that pattern.) But =
that's neither here nor there, as you can already do what you're asking =
for and I think I can clear things up:
>=20
> In your case, the "3rd party bearer assertion" is simply *not* the =
Initial Registration Token. It's an assertion that can be used to *get* =
an Initial Registration Token. The token that you get from the Token =
Endpoint, in your case, would be "local" from your own AS. Your =
registration endpoint would look at this token on the way in, know how =
to validate it, do whatever else it wants to with it, and process the =
registration. Then it would issue a Registration Access Token that to =
the registering client to use at the RESTful endpoint. Incidentally, =
that token would also be "local", just like before.

> How you (the client/developer) get the actual Initial Registration =
Token is completely and forever out of scope for the Dynamic =
Registration spec.=20

[PH]  Yes, the issuance of the third party bearer assertion token token =
would be out of scope of this spec.

If however the group decides to except federated direct access tokens as =
registration *access* tokens, then I think we have to define federation =
for access tokens first.   For me, I think this is something that should =
be discussed in a different charter.

>=20
>=20
> This all still fits with the current definitions as they are. You =
don't have to use federated tokens if you don't want to. I can still use =
them if I want to. Everybody's happy! And this is all because we are not =
defining any content or semantics tied to the processing of the Initial =
Registration Token or calling it an Assertion or anything -- it's up to =
the AS to process it however it would normally process an OAuth Access =
token. So if your AS needs a local token, then you need to use a local =
token. If you don't want to use structured foreign tokens as your =
Initial Registration Tokens, don't. But that shouldn't preclude others =
of us from doing so.

[PH] The difference is where the client is expected to present the =
federated (aka 3rd party) assertion.  I would rather follow the standard =
6749 4.5 method in all cases for consistency. =20

You can choose to short circuit, but I think the draft should follow a =
consistent methodology.

>=20
> If you think it would be helpful, I can add language to the lifecycle =
discussion to clarify that the Initial Registration Token can be gotten =
through any number of means, not just the manual-portal approach that's =
talked about now. Or if you want to write up this specific use case we =
can add it as another concrete example.=20

[PH] I think there is potential to cut a lot of text out of the spec if =
we strictly define the registration endpoint as a normal OAuth2 =
protected endpoint.
>=20
> I will close by pointing out that I have *never* proposed that we =
dictate that the Registration Endpoint have to accept and process =
federated tokens, and it would be ludicrous to do so. I have been and =
still am committed to the Initial Registration Token and the =
Registration Access Token being plain old opaque-to-the-client OAuth 2 =
tokens.=20

[PH] Agreed.  However, the use case of a 3rd party signer for client =
applications is critical to both commercial organizations and open =
source orgs that publish software that are deployed by many separate =
entities.  The client developer needs to be able to contact the =
publisher in many cases to obtain a signed assertion. =20

I believe this is a core use case. =20

I believe as I've proposed it using the normal 4.5 exchange federated =
assertion for local token method, the draft doesn't have to get into the =
details of the assertion.  Though that said, I would suggest the draft =
make some suggestions on the contents of such assertions.
>=20
> I think it's possible that you're still conflating the work I'm doing =
with the BB+ *extension* to dynamic registration with the dynamic =
registration document itself. I have never suggested that we pull all =
the extended BB+ stuff down into Dyn Reg, and in fact I think quite the =
opposite as I don't believe it's as generally applicable without the =
larger BB+ stack (which includes discovery as well as reliance on policy =
and other frameworks).=20

[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle =
have very similar requirements.  As I said above, the use case is a key =
use case.=20

However I agree, the way you solve it in BB+ is not the way to solve it =
within the draft spec.  I think the BB+ does well inform our discussions =
though.
>=20
>  -- Justin
>=20
> On 05/30/2013 03:54 PM, Phil Hunt wrote:
>> Justin,
>>=20
>> So far, every time an OAuth server has accepted a 3rd party token it =
has been a bearer assertion. The common pattern is to exchange that =
assertion for a an access token issued by the local server for the local =
resource endpoint.
>>=20
>> That's the pattern I am trying to follow.
>>=20
>> Going this way means we do not have to define the initial =
registration token.
>>=20
>> If however, you really want to use the initial registration token AS =
an access token, you are taking us into the question of using federated =
access tokens.  I prefer not to do that here.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>>=20
>>> I don't understand which access token is being talked about here -- =
is this the Initial Registration Token? Because you can already do =
everything below. How you get the Initial Registration token is out of =
scope precisely so that the AS can decide what that means. We can add =
language in the lifecycle discussions to bring up the fact that you can =
get this token from an OAuth flow, if you think that'll help clear =
things up.
>>>=20
>>> However, the client doesn't register using the client credential =
flow at all -- it registers using a POST to the registration endpoint, =
and that POST might have an OAuth token attached to it. How the client =
got that OAuth token is, again, out of scope. The client could have done =
some other OAuth flow (any OAuth flow) to get a hold of the token, but =
how is it supposed to get an OAuth token at an AS it hasn't been =
registered with?=20
>>>=20
>>> Now, if you're talking about the Registration Access Token, though, =
that makes less sense to me. The client *has* to register first before =
it can get *anything* from the token endpoint. What you're suggesting is =
that all clients be given access to the token endpoint with the client =
credentials flow for the purposes of retrieving the Registration Access =
Token, unless I misread things. You probably don't want the client =
getting other scopes from the token endpoint using the client =
credentials flow, as it'd be an enormous security risk. Thing is, I =
don't think I can implement that level of separation in my app stack, =
and I haven't seen any others that do that. Separating access to =
different endpoints based on OAuth tokens (and the scopes attached) is =
par for the course, though.
>>>=20
>>> Let me run down how it works in our own setup. When a client =
registers, we create a new token (using a TokenServices class) that has =
a special scope, "registration-token". This token is tied to the =
client_id to which it was issued. Clients cannot get tokens with this =
scope through the usual Token Endpoint means, by design. All of the =
Client Configuration Endpoint URLs are protected such that they require =
access from a valid token with the scope "registration-token", and the =
client_id tied to that token MUST match the client_id in the URL. Each =
client is limited to the OAuth flows (grant_types and response_types) =
that it's allowed to call from the token endpoint. All of this is =
specific to our implementation, but I can speak with some authority that =
it's at least implementable this way. This method lets us do public =
clients, confidential clients, public-key clients (that use JWT =
assertions to call the token endpoint), and all different OAuth flows.=20=

>>>=20
>>> If we were to switch things to what you're recommending (using =
client credentials to get the equivalent of the Registration Access =
Token), I would need to issue some form of client credentials to all =
clients (including public clients) and allow all dynamically registered =
clients access to the client_credentials flow at the token endpoint but =
only if they're asking for a registration-token scope, a scope value =
which hasn't been standardized either. I don't think this is even =
possible in my architecture, and it's certainly not desirable.=20
>>>=20
>>> If we were to switch to having the client credentials used directly =
on the registration endpoint, then you get back into the situation that =
OIDC has already tried, and which failed. I see no reason to try the =
same thing again and expect different results.
>>>=20
>>> I will admit that it was a little strange when I first pulled the =
TokenServices reference into our RegistrationEndpoint class, but doing =
so greatly simplified everything else. I can see the desire to have an =
ideological purity of "all tokens come from the token endpoint", but =
such purity just doesn't help in this case.=20
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/30/2013 03:31 PM, Phil Hunt wrote:
>>>> For this, I would suggest:
>>>>=20
>>>> Anonymous, user assisted registration - client registers using the =
client credential flow but may use an administrator (in the case of web =
app) or end-user (uid/password) .  Since resource owner would still =
require separate credential, then the client flow could be used even =
though we are passing end-user creds. Client obtains access token =
limited to registering the new entity.
>>>>=20
>>>> Anonymous unassisted registration (no user present) - the only =
solution I can come up with is the client self asserted client_id (e.g. =
UUID) that the token endpoint chooses to accept if scope equals =
"registration" (or whatever the scope is to be for registration).   IMHO =
this should be avoided.
>>>>=20
>>>> 3rd Party Assertion - client presents signed assertion in the form =
of JWT or SAML Bearer assertion and exchanges for an access token. =
Access is limited to registering a new entity.
>>>>=20
>>>> The value of the access token being short lived or potentially even =
single-use (or limited use, like 3 tries), would be to prevent abuse of =
the registration end-point.
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-05-30, at 11:59 AM, Justin Richer wrote:
>>>>=20
>>>>> But this still doesn't address clients who don't have a =
client_secret. Do they now need one in order to talk to the registration =
endpoint? What you're suggesting is that a client use one set of =
credentials to get access tokens and another set of credentials to get =
registrations. This is certainly no simpler.
>>>>>=20
>>>>> And this exact functionality was tried, implemented, and rejected =
as too complicated by the OpenID Connect community. I don't see why it'd =
be any different the second time around.
>>>>>=20
>>>>> I really don't see any reason to change it.=20
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> On 05/30/2013 02:56 PM, Phil Hunt wrote:
>>>>>> It's hard to say what the best solution here is regarding =
clarifications until we get clarity on the issue of registration access =
token.
>>>>>>=20
>>>>>> I don't think using a client credential flow to obtain an access =
token to the registration endpoint is complex. It's the normal flow. =20
>>>>>>=20
>>>>>> I concede that you are looking at it as using Client Credential =
to get an access token to get a new Client Credential. But that's not =
really what is happening in terms of protocol here. =20
>>>>>>=20
>>>>>> If you take the perspective that the client needs to occasionally =
update registration (e.g. because of a pending credential expiry), then =
it is still simple. You use client credential flow to obtain an access =
token to update registration. Then, from the context of the REST API, =
the client credential is just another piece of JSON data.
>>>>>>=20
>>>>>> IOW from the REST perspective, it is the registration endpoint =
that is being updated, not the client credential.  The client credential =
is just data in the perspective of REST.
>>>>>>=20
>>>>>> I think you may be inferring complexity where there really is =
none.
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-05-30, at 11:33 AM, Justin Richer wrote:
>>>>>>=20
>>>>>>> Thanks for clearing up where the confusion was taking place. I =
had tried to make it clear that these were absolutely standard, opaque =
OAuth2 bearer tokens and absolutely standard OAuth2-protected endpoints, =
but if that's not clear that needs to be updated. This is what the text =
says right now:
>>>>>>>=20
>>>>>>> The Client Registration Endpoint MAY accept an Initial Access =
Token in the form of an OAuth 2.0 [RFC6749] access token to limit =
registration to only previously authorized parties. The method by which =
the Initial Access Token is obtained by the registrant is generally =
out-of-band and is out of scope of this specification.
>>>>>>>=20
>>>>>>> And:
>>>>>>>=20
>>>>>>> The Client Configuration Endpoint is an OAuth 2.0 protected =
resource that is provisioned by the server for a specific client to be =
able to view and update its registered information. The location of this =
endpoint is communicated to the Client through the =
registration_client_uri member of the Client Information Response =
[client-info-response]. The Client MUST use its Registration Access =
Token in all calls to this endpoint as an OAuth 2.0 Bearer Token =
[RFC6750].
>>>>>>>=20
>>>>>>> Along with the definitions in the introduction:
>>>>>>> Registration Access Token
>>>>>>> OAuth 2.0 Bearer Token issued by the Authorization Server =
through the Client Registration Endpoint that is used to authenticate =
the caller when accessing the Client's registration information at the =
Client Configuration Endpoint. This Access Token is associated with a =
particular registered Client.
>>>>>>> Initial Access Token
>>>>>>> An OAuth 2.0 Access Token optionally issued by an Authorization =
Server granting access to its Client Registration Endpoint.
>>>>>>>=20
>>>>>>> I'd welcome any proposed changes to the text to make this =
clearer.
>>>>>>>=20
>>>>>>> As to the other suggestion, what you're saying is to use the =
client credentials to get an access token to get the client credentials =
... ? I can see the argument for using the oauth client credentials =
flow, but I think that's far more complicated than an endpoint saying =
"here's a token, go use it", personally. Besides, not all clients have =
credentials at the token endpoint, so it's a bit of a non-starter for a =
large class of clients.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 05/30/2013 01:55 PM, Phil Hunt wrote:
>>>>>>>> I see what is happening.
>>>>>>>>=20
>>>>>>>> I think the reason why I find this spec sooo confusing is that =
the terms imply new token types when they don't.
>>>>>>>>=20
>>>>>>>> For example when you say "Registration Access Token" and =
"Initial Access Token" it implies to me that it is a totally new token =
type (and in one case it sorta is). When you read the spec (particularly =
draft 10) it is easy to assume something very different is going on. =
Hence my push back.
>>>>>>>>=20
>>>>>>>> It is now clear to me that what you mean to say is *Access =
Token used for initial access* and *Access Token used for registration*.
>>>>>>>>=20
>>>>>>>> Why not write the draft to make clear that the registration end =
point is just a NORMAL OAuth2 Enabled REST endpoint?  That way you can =
eliminate all of the terminology and lifecycle around access tokens =
except to say the endpoint is accessed by tokens issued based on the =
scope "oauth2:registration".
>>>>>>>>=20
>>>>>>>> That only brings issues with the registration token.  The =
"Access Token used for registration" seems to have special lifecycle =
differences.
>>>>>>>> 1.  Issed by reg endpoint as part of successful registration
>>>>>>>> 2.  Has a different lifetime than the client credential =
(whatever it is).
>>>>>>>>=20
>>>>>>>> Why not again simplify and follow normal OAuth2 pattern and =
have the access token issued for registration be *short* lived.  Each =
time the client wants to either initially register or update its profile =
it must request a normal access token with scope "oauth2:registration".=20=

>>>>>>>>=20
>>>>>>>> As for client credential expiry, why not simply require the =
client to update its registration before it expires?  Why have a =
long-lived "registration access token" that has to be managed as well?
>>>>>>>>=20
>>>>>>>> Maybe now I am completely confused?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
>>>>>>>>=20
>>>>>>>>> The issue is that it has different issuing/lifecycle than =
normal. E.g. Why is it issued by the registration endpoint?
>>>>>>>>>=20
>>>>>>>>> Why doesn't the client just request an access token using its =
client credential for the registration endpoint when it wants to update =
its profile?
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com
>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2013-05-30, at 10:08 AM, John Bradley wrote:
>>>>>>>>>=20
>>>>>>>>>> The reg access token is a OAuth bearer token that is issued =
as part of the registration response and used to access the new client =
resource for reads and or updates depending on the permissions.
>>>>>>>>>>=20
>>>>>>>>>> They are both oauth access tokens.
>>>>>>>>>>=20
>>>>>>>>>> On 2013-05-30, at 12:02 PM, Phil Hunt  =
wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Seriously. The new dyn reg draft introduces two new tokens. =
The initial reg token and the registration access token.=20
>>>>>>>>>>>=20
>>>>>>>>>>> As for the latter, the reg access token, my understanding is =
it has nothing to do with an access token. It is issued *after* =
registration to allow reg updates.  Right? I know some are confused =
about this.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Phil
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-05-30, at 8:52, Phil Hunt  =
wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> No different issue. I was concerned about the initial =
client assertion being passed in as authen cred. It is a signed set of =
client reg metadata.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> See we are confused. Hence my worry. :-)
>>>>>>>>>>>>=20
>>>>>>>>>>>> Phil
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-05-30, at 8:48, John Bradley  =
wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> I think Phil also had some processing reason why a Token =
endpoint or RS wouldn't want to tale the authentication as a header, as =
the processing was easier with them as parameters as they are =
potentially available to different parts of the stack.   That may have =
been mostly around RS, but the principal may apply to the token endpoint =
as well.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer =
 wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>>>>>>>>>>> BASIC and POST are essentially the same just different =
ways to send the client secret. If an authorization server supports =
both, both should work for any client. So are both methods treated =
differently?
>>>>>>>>>>>>>>>> I agree, and this was one of my original arguments for =
making this field plural (or plural-able), but there hasn't been WG =
support for that so far.
>>>>>>>>>>>>>>> I'm not arguing to make it plural. I think the =
authentication method is just "client_secret".
>>>>>>>>>>>>>> That was also an option that was brought up, but in the =
OIDC WG the counter-argument was (as I recall) that the two are =
syntactically separate and there's a desire to restrict to a single =
type, such as disabling client_secret_post. Basically, to make it =
unambiguous.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_DEC5A9D7-8886-4D3F-8D67-E3DC59CA2E7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

See =
below.


Phil

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








On 2013-05-30, at 2:09 PM, Justin Richer wrote:


 =20
    
 =20
  

    OK, I think see part of the hang up. I have not seen the scenario
    that you describe, where you trade a 3rd party token for a "local"
    token. I have seen where access tokens are federated directly at the
    PR. (Introspection lets you do some good things with that pattern.)
    But that's neither here nor there, as you can already do what you're
    asking for and I think I can clear things up:

    

    In your case, the "3rd party bearer assertion" is simply *not* the
    Initial Registration Token. It's an assertion that can be used to
    *get* an Initial Registration Token. The token that you get from the
    Token Endpoint, in your case, would be "local" from your own AS.
    Your registration endpoint would look at this token on the way in,
    know how to validate it, do whatever else it wants to with it, and
    process the registration. Then it would issue a Registration Access
    Token that to the registering client to use at the RESTful endpoint.
    Incidentally, that token would also be "local", just like =
before.


    How you (the client/developer) get the actual Initial Registration
    Token is completely and forever out of scope for the Dynamic
    Registration spec. 

[PH] =
 Yes, the issuance of the third party bearer assertion token token =
would be out of scope of this spec.

If however =
the group decides to except federated direct access tokens as =
registration *access* tokens, then I think we have to define federation =
for access tokens first.   For me, I think this is something that =
should be discussed in a different =
charter.


    

    

    This all still fits with the current definitions as they are. You
    don't have to use federated tokens if you don't want to. I can still
    use them if I want to. Everybody's happy! And this is all because we
    are not defining any content or semantics tied to the processing of
    the Initial Registration Token or calling it an Assertion or
    anything -- it's up to the AS to process it however it would
    normally process an OAuth Access token. So if your AS needs a local
    token, then you need to use a local token. If you don't want to use
    structured foreign tokens as your Initial Registration Tokens,
    don't. But that shouldn't preclude others of us from doing =
so.

[PH] The difference is where =
the client is expected to present the federated (aka 3rd party) =
assertion.  I would rather follow the standard 6749 4.5 method in =
all cases for consistency.  

You can =
choose to short circuit, but I think the draft should follow a =
consistent methodology.


    

    If you think it would be helpful, I can add language to the
    lifecycle discussion to clarify that the Initial Registration Token
    can be gotten through any number of means, not just the
    manual-portal approach that's talked about now. Or if you want to
    write up this specific use case we can add it as another concrete
    example. 

[PH] I think there is =
potential to cut a lot of text out of the spec if we strictly define the =
registration endpoint as a normal OAuth2 protected =
endpoint.

    

    I will close by pointing out that I have *never* proposed that we
    dictate that the Registration Endpoint have to accept and process
    federated tokens, and it would be ludicrous to do so. I have been
    and still am committed to the Initial Registration Token and the
    Registration Access Token being plain old opaque-to-the-client OAuth
    2 tokens. 

[PH] Agreed. =
 However, the use case of a 3rd party signer for client =
applications is critical to both commercial organizations and open =
source orgs that publish software that are deployed by many separate =
entities.  The client developer needs to be able to contact the =
publisher in many cases to obtain a signed assertion. =
 

I believe this is a core use case. =
 

I believe as I've proposed it using the =
normal 4.5 exchange federated assertion for local token method, the =
draft doesn't have to get into the details of the assertion. =
 Though that said, I would suggest the draft make some suggestions =
on the contents of such assertions.

    

    I think it's possible that you're still conflating the work I'm
    doing with the BB+ *extension* to dynamic registration with the
    dynamic registration document itself. I have never suggested that we
    pull all the extended BB+ stuff down into Dyn Reg, and in fact I
    think quite the opposite as I don't believe it's as generally
    applicable without the larger BB+ stack (which includes discovery as
    well as reliance on policy and other frameworks). =


[PH] I'm only using it as an =
example. Both Cisco (at IIW) and Oracle have very similar requirements. =
 As I said above, the use case is a key use =
case. 

However I agree, the way you solve =
it in BB+ is not the way to solve it within the draft spec.  I =
think the BB+ does well inform our discussions though.

    

     -- Justin

    

    
On 05/30/2013 03:54 PM, Phil Hunt
      wrote:

    

    

      
      Justin,
      


      

      
So far, every time an OAuth server has accepted a 3rd party
        token it has been a bearer assertion. The common pattern is to
        exchange that assertion for a an access token issued by the
        local server for the local resource endpoint.

      


      

      
That's the pattern I am trying to follow.

      


      

      
Going this way means we do not have to define the initial
        registration token.

      


      

      
If however, you really want to use the initial registration
        token AS an access token, you are taking us into the question of
        using federated access tokens.  I prefer not to do that =
here.

      


      

      

        

          

            
            

            

              
On 2013-05-30, at 12:51 PM, Justin Richer =
wrote:

              

              

                
 I don't
                  understand which access token is being talked about
                  here -- is this the Initial Registration Token?
                  Because you can already do everything below. How you
                  get the Initial Registration token is out of scope
                  precisely so that the AS can decide what that means.
                  We can add language in the lifecycle discussions to
                  bring up the fact that you can get this token from an
                  OAuth flow, if you think that'll help clear things =
up.

                  

                  However, the client doesn't register using the client
                  credential flow at all -- it registers using a POST to
                  the registration endpoint, and that POST might have an
                  OAuth token attached to it. How the client got that
                  OAuth token is, again, out of scope. The client could
                  have done some other OAuth flow (any OAuth flow) to
                  get a hold of the token, but how is it supposed to get
                  an OAuth token at an AS it hasn't been registered
                  with? 

                  

                  Now, if you're talking about the Registration Access
                  Token, though, that makes less sense to me. The client
                  *has* to register first before it can get *anything*
                  from the token endpoint. What you're suggesting is
                  that all clients be given access to the token endpoint
                  with the client credentials flow for the purposes of
                  retrieving the Registration Access Token, unless I
                  misread things. You probably don't want the client
                  getting other scopes from the token endpoint using the
                  client credentials flow, as it'd be an enormous
                  security risk. Thing is, I don't think I can implement
                  that level of separation in my app stack, and I
                  haven't seen any others that do that. Separating
                  access to different endpoints based on OAuth tokens
                  (and the scopes attached) is par for the course,
                  though.

                  

                  Let me run down how it works in our own setup. When a
                  client registers, we create a new token (using a
                  TokenServices class) that has a special scope,
                  "registration-token". This token is tied to the
                  client_id to which it was issued. Clients cannot get
                  tokens with this scope through the usual Token
                  Endpoint means, by design. All of the Client
                  Configuration Endpoint URLs are protected such that
                  they require access from a valid token with the scope
                  "registration-token", and the client_id tied to that
                  token MUST match the client_id in the URL. Each client
                  is limited to the OAuth flows (grant_types and
                  response_types) that it's allowed to call from the
                  token endpoint. All of this is specific to our
                  implementation, but I can speak with some authority
                  that it's at least implementable this way. This method
                  lets us do public clients, confidential clients,
                  public-key clients (that use JWT assertions to call
                  the token endpoint), and all different OAuth flows. =


                  

                  If we were to switch things to what you're
                  recommending (using client credentials to get the
                  equivalent of the Registration Access Token), I would
                  need to issue some form of client credentials to all
                  clients (including public clients) and allow all
                  dynamically registered clients access to the
                  client_credentials flow at the token endpoint but only
                  if they're asking for a registration-token scope, a
                  scope value which hasn't been standardized either. I
                  don't think this is even possible in my architecture,
                  and it's certainly not desirable. 

                  

                  If we were to switch to having the client credentials
                  used directly on the registration endpoint, then you
                  get back into the situation that OIDC has already
                  tried, and which failed. I see no reason to try the
                  same thing again and expect different results.

                  

                  I will admit that it was a little strange when I first
                  pulled the TokenServices reference into our
                  RegistrationEndpoint class, but doing so greatly
                  simplified everything else. I can see the desire to
                  have an ideological purity of "all tokens come from
                  the token endpoint", but such purity just doesn't help
                  in this case. 

                  

                   -- Justin

                  

                  
On 05/30/2013 03:31 PM,
                    Phil Hunt wrote:

                  

                  
 For this, I would suggest:
                    


                    

                    
Anonymous, user assisted registration - client
                      registers using the client credential flow but may
                      use an administrator (in the case of web app) or
                      end-user (uid/password) .  Since resource =
owner
                      would still require separate credential, then the
                      client flow could be used even though we are
                      passing end-user creds. Client obtains access
                      token limited to registering the new entity.

                    


                    

                    
Anonymous unassisted registration (no user
                      present) - the only solution I can come up with is
                      the client self asserted client_id (e.g. UUID)
                      that the token endpoint chooses to accept if scope
                      equals "registration" (or whatever the scope is to
                      be for registration).   IMHO this should be
                      avoided.

                    


                    

                    
3rd Party Assertion - client presents signed
                      assertion in the form of JWT or SAML Bearer
                      assertion and exchanges for an access token.
                      Access is limited to registering a new =
entity.

                    


                    

                    
The value of the access token being short lived
                      or potentially even single-use (or limited use,
                      like 3 tries), would be to prevent abuse of the
                      registration end-point.

                    


                      
                      

                      

                        
On 2013-05-30, at 11:59 AM, Justin Richer
                          wrote:

                        

                        

                          
 But
                            this still doesn't address clients who don't
                            have a client_secret. Do they now need one
                            in order to talk to the registration
                            endpoint? What you're suggesting is that a
                            client use one set of credentials to get
                            access tokens and another set of credentials
                            to get registrations. This is certainly no
                            simpler.

                            

                            And this exact functionality was tried,
                            implemented, and rejected as too complicated
                            by the OpenID Connect community. I don't see
                            why it'd be any different the second time
                            around.

                            

                            I really don't see any reason to change it.
                            

                            

                             -- Justin

                            

                            
On 05/30/2013
                              02:56 PM, Phil Hunt wrote:

                            

                            
 It's hard to say what the
                              best solution here is regarding
                              clarifications until we get clarity on the
                              issue of registration access token.
                              


                              

                              
I don't think using a client
                                credential flow to obtain an access
                                token to the registration endpoint is
                                complex. It's the normal flow. =
 

                              


                              

                              
I concede that you are looking at it
                                as using Client Credential to get an
                                access token to get a new Client
                                Credential. But that's not really what
                                is happening in terms of protocol here.
                                 

                              


                              

                              
If you take the perspective that the
                                client needs to occasionally update
                                registration (e.g. because of a pending
                                credential expiry), then it is still
                                simple. You use client credential flow
                                to obtain an access token to update
                                registration. Then, from the context of
                                the REST API, the client credential is
                                just another piece of JSON data.

                              


                              

                              
IOW from the REST perspective, it is
                                the registration endpoint that is being
                                updated, not the client credential. =
 The
                                client credential is just data in the
                                perspective of REST.

                              


                              

                              
I think you may be inferring
                                complexity where there really is =
none.

                              


                              

                              

                                
                                

                                

                                  
On 2013-05-30, at 11:33 AM,
                                    Justin Richer wrote:

                                  
=

                                  

                                    
 Thanks for
                                      clearing up where the confusion
                                      was taking place. I had tried to
                                      make it clear that these were
                                      absolutely standard, opaque OAuth2
                                      bearer tokens and absolutely
                                      standard OAuth2-protected
                                      endpoints, but if that's not clear
                                      that needs to be updated. This is
                                      what the text says right now:

                                      

                                      
The Client
                                        Registration Endpoint MAY accept
                                        an Initial Access Token in the
                                        form of an OAuth




                                          2.0  [RFC6749]
                                        access token to limit
                                        registration to only previously
                                        authorized parties. The method
                                        by which the Initial Access
                                        Token is obtained by the
                                        registrant is generally
                                        out-of-band and is out of scope
                                        of this specification.

                                      

                                      

                                      And:

                                      

                                      
The Client
                                        Configuration Endpoint is an
                                        OAuth 2.0 protected resource
                                        that is provisioned by the
                                        server for a specific client to
                                        be able to view and update its
                                        registered information. The
                                        location of this endpoint is
                                        communicated to the Client
                                        through the =
registration_client_uri
                                        member of the Client




                                          Information Response [client-info-response].
                                        The Client MUST use its
                                        Registration Access Token in all
                                        calls to this endpoint as an OAuth




                                          2.0 Bearer Token [RFC6750].

                                      

                                      

                                      Along with the definitions in the
                                      introduction:

                                      

                                        

                                          
Registration Access =
Token

                                          
OAuth

                                            2.0 Bearer Token issued by
                                            the Authorization Server
                                            through the Client
                                            Registration Endpoint that
                                            is used to authenticate the
                                            caller when accessing the
                                            Client's registration
                                            information at the Client
                                            Configuration Endpoint. This
                                            Access Token is associated
                                            with a particular registered
                                            Client.

                                          
Initial Access Token

                                          
An
                                            OAuth 2.0 Access Token
                                            optionally issued by an
                                            Authorization Server
                                            granting access to its
                                            Client Registration
                                            Endpoint.

                                        

                                      

                                      

                                      I'd welcome any proposed changes
                                      to the text to make this =
clearer.

                                      

                                      As to the other suggestion, what
                                      you're saying is to use the client
                                      credentials to get an access token
                                      to get the client credentials ...
                                      ? I can see the argument for using
                                      the oauth client credentials flow,
                                      but I think that's far more
                                      complicated than an endpoint
                                      saying "here's a token, go use
                                      it", personally. Besides, not all
                                      clients have credentials at the
                                      token endpoint, so it's a bit of a
                                      non-starter for a large class of
                                      clients.

                                      

                                       -- Justin

                                      

                                      

                                      
On
                                        05/30/2013 01:55 PM, Phil Hunt
                                        wrote:

                                      

                                      

                                        
I see what is =
happening.

I think the reason why I find this spec sooo confusing is that the terms =
imply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access =
Token" it implies to me that it is a totally new token type (and in one =
case it sorta is). When you read the spec (particularly draft 10) it is =
easy to assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used =
for initial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is =
just a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate =
all of the terminology and lifecycle around access tokens except to say =
the endpoint is accessed by tokens issued based on the scope =
"oauth2:registration".

That only brings issues with the registration token.  The "Access Token =
used for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it =
is).

Why not again simplify and follow normal OAuth2 pattern and have the =
access token issued for registration be *short* lived.  Each time the =
client wants to either initially register or update its profile it must =
request a normal access token with scope "oauth2:registration".=20

As for client credential expiry, why not simply require the client to =
update its registration before it expires?  Why have a long-lived =
"registration access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



                                        

                                          
The issue is =
that it has different issuing/lifecycle than normal. E.g. Why is it =
issued by the registration endpoint?

Why doesn't the client just request an access token using its client =
credential for the registration endpoint when it wants to update its =
profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



                                          

                                            
The reg =
access token is a OAuth bearer token that is issued as part of the =
registration response and used to access the new client resource for =
reads and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                                            

                                              
Seriously. =
The new dyn reg draft introduces two new tokens. The initial reg token =
and the registration access token.=20

As for the latter, the reg access token, my understanding is it has =
nothing to do with an access token. It is issued *after* registration to =
allow reg updates.  Right? I know some are confused about this.=20

Phil

On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com> =
wrote:



                                              

                                                
No =
different issue. I was concerned about the initial client assertion =
being passed in as authen cred. It is a signed set of client reg =
metadata.=20

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:



                                                
=

                                                  
I think =
Phil also had some processing reason why a Token endpoint or RS wouldn't =
want to tale the authentication as a header, as the processing was =
easier with them as parameters as they are potentially available to =
different parts of the stack.   That may have been mostly around RS, but =
the principal may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:



                                                  

                                                    

                                                      

                                                        

                                                          
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the =
client secret. If an authorization server supports both, both should =
work for any client. So are both methods treated differently?


                                                        

                                                        
I =
agree, and this was one of my original arguments for making this field =
plural (or plural-able), but there hasn't been WG support for that so =
far.


                                                      

                                                      
I'm =
not arguing to make it plural. I think the authentication method is just =
"client_secret".


                                                    

                                                    
That =
was also an option that was brought up, but in the OIDC WG the =
counter-argument was (as I recall) that the two are syntactically =
separate and there's a desire to restrict to a single type, such as =
disabling client_secret_post. Basically, to make it unambiguous.


                                                  

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


                                                

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


                                              

                                            

                                          

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


                                        

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


                                      

                                      

                                    

                                  

                                

                                

                              

                            

                            

                          

                        

                      

                      

                    

                  

                  

                

              

            

            

          

        

      

    

    

  




=

--Apple-Mail=_DEC5A9D7-8886-4D3F-8D67-E3DC59CA2E7B--

From jricher@mitre.org  Thu May 30 16:11:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345D21F8F00 for ; Thu, 30 May 2013 16:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.87
X-Spam-Level: 
X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-0.572,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_CREDIT=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMWPUOoQlm44 for ; Thu, 30 May 2013 16:11:05 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DC21F9128 for ; Thu, 30 May 2013 16:11:04 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8D8D51F059D; Thu, 30 May 2013 19:11:03 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 75EBC1F026A; Thu, 30 May 2013 19:11:03 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Thu, 30 May 2013 19:11:03 -0400
From: "Richer, Justin P." 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Thread-Index: AQHOXSFKoUPHFo+jJEeuqil8woB+1Jkd4A8XgABEGwCAAALvAIAAEjEAgAABU4CAAAv5AP//zhOmgAAJjwGAAAa4l4AAGWZYgAAdN8Q=
Date: Thu, 30 May 2013 23:11:03 +0000
Message-ID: 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org>, <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>
In-Reply-To: <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.31.52]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E08F97708IMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 23:11:11 -0000

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

Comments inline, marked by [JR].

________________________________
From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.
Phil

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





On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you =
describe, where you trade a 3rd party token for a "local" token. I have see=
n where access tokens are federated directly at the PR. (Introspection lets=
 you do some good things with that pattern.) But that's neither here nor th=
ere, as you can already do what you're asking for and I think I can clear t=
hings up:

In your case, the "3rd party bearer assertion" is simply *not* the Initial =
Registration Token. It's an assertion that can be used to *get* an Initial =
Registration Token. The token that you get from the Token Endpoint, in your=
 case, would be "local" from your own AS. Your registration endpoint would =
look at this token on the way in, know how to validate it, do whatever else=
 it wants to with it, and process the registration. Then it would issue a R=
egistration Access Token that to the registering client to use at the RESTf=
ul endpoint. Incidentally, that token would also be "local", just like befo=
re.

How you (the client/developer) get the actual Initial Registration Token is=
 completely and forever out of scope for the Dynamic Registration spec.

[PH]  Yes, the issuance of the third party bearer assertion token token wou=
ld be out of scope of this spec.

If however the group decides to except federated direct access tokens as re=
gistration *access* tokens, then I think we have to define federation for a=
ccess tokens first.   For me, I think this is something that should be disc=
ussed in a different charter.

[JR] It's an access token, plain and simple. The draft doesn't care -- and =
shouldn't care -- if it's federated or not. I agree, and have been arguing =
all along, that if you have a use case for federated access tokens, you nee=
d to define the mechanisms for such tokens, and that registration is *not* =
the place for that definition. It's orthogonal but they can be used togethe=
r. Let's define them separately but in a compatible way.



This all still fits with the current definitions as they are. You don't hav=
e to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any =
content or semantics tied to the processing of the Initial Registration Tok=
en or calling it an Assertion or anything -- it's up to the AS to process i=
t however it would normally process an OAuth Access token. So if your AS ne=
eds a local token, then you need to use a local token. If you don't want to=
 use structured foreign tokens as your Initial Registration Tokens, don't. =
But that shouldn't preclude others of us from doing so.

[PH] The difference is where the client is expected to present the federate=
d (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 m=
ethod in all cases for consistency.

You can choose to short circuit, but I think the draft should follow a cons=
istent methodology.

[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as i=
t's talking about access to the token endpoint and not to protected resourc=
es. Additionally, people do use assertions encoded inside of OAuth tokens d=
irectly at protected resources all the time (since OAuth2 tokens are opaque=
 to clients but must be understood by protected resources), but that's *sti=
ll* completely irrelevant to this discussion because it doesn't matter in t=
erms of the interoperability of the protocol. If you want to use assertions=
 or auth codes or client credentials or magic to get your Initial Registrat=
ion Token, the dynamic registration protocol doesn't care how you did it. J=
ust like any other OAuth2 protected resource doesn't care how you got the t=
oken. This abstraction was one of the key insights in how OAuth2 is structu=
red as a framework and protocol. The important thing here is that if the cl=
ient gets an Initial Registration Token it knows where to send it and how t=
o use it. What I hear you saying is that you don't want to use a federated =
token as an Initial Registration Token. That's fine! Don't do it -- and you=
 have that option precisely because of how we've already written it! If you=
r clients get handed a token that *isn't* an Initial Registration Token and=
 you want them to go through another step to *get* an Initial Registration =
Token, so be it! But it doesn't make sense to encode that behavior as requi=
red into the registration protocol, because (as you point out) not everythi=
ng is going to be an assertion in the first place. Again I say that you can=
 do everything that you want to do with existing mechanisms or self-contain=
ed extensions.


If you think it would be helpful, I can add language to the lifecycle discu=
ssion to clarify that the Initial Registration Token can be gotten through =
any number of means, not just the manual-portal approach that's talked abou=
t now. Or if you want to write up this specific use case we can add it as a=
nother concrete example.

[PH] I think there is potential to cut a lot of text out of the spec if we =
strictly define the registration endpoint as a normal OAuth2 protected endp=
oint.

[JR] I don't understand what you're saying here -- it already *is* an OAuth=
2 protected endpoint, like I've pointed out below. All OAuth2 protected end=
points don't care how you get the token, neither does this one. All OAuth2 =
protected endpoints don't care (from OAuth2's perspective) how the token is=
 verified or processed, and neither does this one (from the draft's perspec=
tive). I explicitly want to keep that kind of token and assertion processin=
g *out* of this draft because it's more useful to build generally applicabl=
e mechanisms. If we keep the registration endpoint as an OAuth2 protected e=
ndpoint -- like it already is -- then we can inherit whatever mechanisms yo=
u want, and that is a very powerful setup.

I will close by pointing out that I have *never* proposed that we dictate t=
hat the Registration Endpoint have to accept and process federated tokens, =
and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and the Registration Access Token being plain=
 old opaque-to-the-client OAuth 2 tokens.

[PH] Agreed.  However, the use case of a 3rd party signer for client applic=
ations is critical to both commercial organizations and open source orgs th=
at publish software that are deployed by many separate entities.  The clien=
t developer needs to be able to contact the publisher in many cases to obta=
in a signed assertion.

I believe this is a core use case.

I believe as I've proposed it using the normal 4.5 exchange federated asser=
tion for local token method, the draft doesn't have to get into the details=
 of the assertion.  Though that said, I would suggest the draft make some s=
uggestions on the contents of such assertions.

[JR] You can already do what you want to without mentioning assertions. The=
 current draft doesn't mention assertions at all, either. All talk of use o=
f assertions is outside the scope of registration. You're proposing adding =
it in, and I'm strongly against that.

I think it's possible that you're still conflating the work I'm doing with =
the BB+ *extension* to dynamic registration with the dynamic registration d=
ocument itself. I have never suggested that we pull all the extended BB+ st=
uff down into Dyn Reg, and in fact I think quite the opposite as I don't be=
lieve it's as generally applicable without the larger BB+ stack (which incl=
udes discovery as well as reliance on policy and other frameworks).

[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have v=
ery similar requirements.  As I said above, the use case is a key use case.

However I agree, the way you solve it in BB+ is not the way to solve it wit=
hin the draft spec.  I think the BB+ does well inform our discussions thoug=
h.

[JR] Considering that BB+ manages to do all of this with a cleanly defined =
extension without any changes in the existing draft text, I think that's as=
 strong an argument as anything to keep it defined how it is, and that what=
's there is a sufficient base to build on.

 -- Justin

On 05/30/2013 03:54 PM, Phil Hunt wrote:
Justin,

So far, every time an OAuth server has accepted a 3rd party token it has be=
en a bearer assertion. The common pattern is to exchange that assertion for=
 a an access token issued by the local server for the local resource endpoi=
nt.

That's the pattern I am trying to follow.

Going this way means we do not have to define the initial registration toke=
n.

If however, you really want to use the initial registration token AS an acc=
ess token, you are taking us into the question of using federated access to=
kens.  I prefer not to do that here.

Phil

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





On 2013-05-30, at 12:51 PM, Justin Richer wrote:

I don't understand which access token is being talked about here -- is this=
 the Initial Registration Token? Because you can already do everything belo=
w. How you get the Initial Registration token is out of scope precisely so =
that the AS can decide what that means. We can add language in the lifecycl=
e discussions to bring up the fact that you can get this token from an OAut=
h flow, if you think that'll help clear things up.

However, the client doesn't register using the client credential flow at al=
l -- it registers using a POST to the registration endpoint, and that POST =
might have an OAuth token attached to it. How the client got that OAuth tok=
en is, again, out of scope. The client could have done some other OAuth flo=
w (any OAuth flow) to get a hold of the token, but how is it supposed to ge=
t an OAuth token at an AS it hasn't been registered with?

Now, if you're talking about the Registration Access Token, though, that ma=
kes less sense to me. The client *has* to register first before it can get =
*anything* from the token endpoint. What you're suggesting is that all clie=
nts be given access to the token endpoint with the client credentials flow =
for the purposes of retrieving the Registration Access Token, unless I misr=
ead things. You probably don't want the client getting other scopes from th=
e token endpoint using the client credentials flow, as it'd be an enormous =
security risk. Thing is, I don't think I can implement that level of separa=
tion in my app stack, and I haven't seen any others that do that. Separatin=
g access to different endpoints based on OAuth tokens (and the scopes attac=
hed) is par for the course, though.

Let me run down how it works in our own setup. When a client registers, we =
create a new token (using a TokenServices class) that has a special scope, =
"registration-token". This token is tied to the client_id to which it was i=
ssued. Clients cannot get tokens with this scope through the usual Token En=
dpoint means, by design. All of the Client Configuration Endpoint URLs are =
protected such that they require access from a valid token with the scope "=
registration-token", and the client_id tied to that token MUST match the cl=
ient_id in the URL. Each client is limited to the OAuth flows (grant_types =
and response_types) that it's allowed to call from the token endpoint. All =
of this is specific to our implementation, but I can speak with some author=
ity that it's at least implementable this way. This method lets us do publi=
c clients, confidential clients, public-key clients (that use JWT assertion=
s to call the token endpoint), and all different OAuth flows.

If we were to switch things to what you're recommending (using client crede=
ntials to get the equivalent of the Registration Access Token), I would nee=
d to issue some form of client credentials to all clients (including public=
 clients) and allow all dynamically registered clients access to the client=
_credentials flow at the token endpoint but only if they're asking for a re=
gistration-token scope, a scope value which hasn't been standardized either=
. I don't think this is even possible in my architecture, and it's certainl=
y not desirable.

If we were to switch to having the client credentials used directly on the =
registration endpoint, then you get back into the situation that OIDC has a=
lready tried, and which failed. I see no reason to try the same thing again=
 and expect different results.

I will admit that it was a little strange when I first pulled the TokenServ=
ices reference into our RegistrationEndpoint class, but doing so greatly si=
mplified everything else. I can see the desire to have an ideological purit=
y of "all tokens come from the token endpoint", but such purity just doesn'=
t help in this case.

 -- Justin

On 05/30/2013 03:31 PM, Phil Hunt wrote:
For this, I would suggest:

Anonymous, user assisted registration - client registers using the client c=
redential flow but may use an administrator (in the case of web app) or end=
-user (uid/password) .  Since resource owner would still require separate c=
redential, then the client flow could be used even though we are passing en=
d-user creds. Client obtains access token limited to registering the new en=
tity.

Anonymous unassisted registration (no user present) - the only solution I c=
an come up with is the client self asserted client_id (e.g. UUID) that the =
token endpoint chooses to accept if scope equals "registration" (or whateve=
r the scope is to be for registration).   IMHO this should be avoided.

3rd Party Assertion - client presents signed assertion in the form of JWT o=
r SAML Bearer assertion and exchanges for an access token. Access is limite=
d to registering a new entity.

The value of the access token being short lived or potentially even single-=
use (or limited use, like 3 tries), would be to prevent abuse of the regist=
ration end-point.

Phil

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





On 2013-05-30, at 11:59 AM, Justin Richer wrote:

But this still doesn't address clients who don't have a client_secret. Do t=
hey now need one in order to talk to the registration endpoint? What you're=
 suggesting is that a client use one set of credentials to get access token=
s and another set of credentials to get registrations. This is certainly no=
 simpler.

And this exact functionality was tried, implemented, and rejected as too co=
mplicated by the OpenID Connect community. I don't see why it'd be any diff=
erent the second time around.

I really don't see any reason to change it.

 -- Justin

On 05/30/2013 02:56 PM, Phil Hunt wrote:
It's hard to say what the best solution here is regarding clarifications un=
til we get clarity on the issue of registration access token.

I don't think using a client credential flow to obtain an access token to t=
he registration endpoint is complex. It's the normal flow.

I concede that you are looking at it as using Client Credential to get an a=
ccess token to get a new Client Credential. But that's not really what is h=
appening in terms of protocol here.

If you take the perspective that the client needs to occasionally update re=
gistration (e.g. because of a pending credential expiry), then it is still =
simple. You use client credential flow to obtain an access token to update =
registration. Then, from the context of the REST API, the client credential=
 is just another piece of JSON data.

IOW from the REST perspective, it is the registration endpoint that is bein=
g updated, not the client credential.  The client credential is just data i=
n the perspective of REST.

I think you may be inferring complexity where there really is none.

Phil

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





On 2013-05-30, at 11:33 AM, Justin Richer wrote:

Thanks for clearing up where the confusion was taking place. I had tried to=
 make it clear that these were absolutely standard, opaque OAuth2 bearer to=
kens and absolutely standard OAuth2-protected endpoints, but if that's not =
clear that needs to be updated. This is what the text says right now:

The Client Registration Endpoint MAY accept an Initial Access Token in the =
form of an OAuth 2.0  [RFC6749] access token to limit registration to only previous=
ly authorized parties. The method by which the Initial Access Token is obta=
ined by the registrant is generally out-of-band and is out of scope of this=
 specification.

And:

The Client Configuration Endpoint is an OAuth 2.0 protected resource that i=
s provisioned by the server for a specific client to be able to view and up=
date its registered information. The location of this endpoint is communica=
ted to the Client through the registration_client_uri member of the Client =
Information Response [client-info-response]. The Client MUST use its R=
egistration Access Token in all calls to this endpoint as an OAuth 2.0 Bear=
er Token=
 [RFC6750].

Along with the definitions in the introduction:

Registration Access Token
OAuth 2.0 Bearer Token issued by the Authorization Server through the Clien=
t Registration Endpoint that is used to authenticate the caller when access=
ing the Client's registration information at the Client Configuration Endpo=
int. This Access Token is associated with a particular registered Client.
Initial Access Token
An OAuth 2.0 Access Token optionally issued by an Authorization Server gran=
ting access to its Client Registration Endpoint.

I'd welcome any proposed changes to the text to make this clearer.

As to the other suggestion, what you're saying is to use the client credent=
ials to get an access token to get the client credentials ... ? I can see t=
he argument for using the oauth client credentials flow, but I think that's=
 far more complicated than an endpoint saying "here's a token, go use it", =
personally. Besides, not all clients have credentials at the token endpoint=
, so it's a bit of a non-starter for a large class of clients.

 -- Justin


On 05/30/2013 01:55 PM, Phil Hunt wrote:

I see what is happening.

I think the reason why I find this spec sooo confusing is that the terms im=
ply new token types when they don't.

For example when you say "Registration Access Token" and "Initial Access To=
ken" it implies to me that it is a totally new token type (and in one case =
it sorta is). When you read the spec (particularly draft 10) it is easy to =
assume something very different is going on. Hence my push back.

It is now clear to me that what you mean to say is *Access Token used for i=
nitial access* and *Access Token used for registration*.

Why not write the draft to make clear that the registration end point is ju=
st a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all o=
f the terminology and lifecycle around access tokens except to say the endp=
oint is accessed by tokens issued based on the scope "oauth2:registration".

That only brings issues with the registration token.  The "Access Token use=
d for registration" seems to have special lifecycle differences.
1.  Issed by reg endpoint as part of successful registration
2.  Has a different lifetime than the client credential (whatever it is).

Why not again simplify and follow normal OAuth2 pattern and have the access=
 token issued for registration be *short* lived.  Each time the client want=
s to either initially register or update its profile it must request a norm=
al access token with scope "oauth2:registration".

As for client credential expiry, why not simply require the client to updat=
e its registration before it expires?  Why have a long-lived "registration =
access token" that has to be managed as well?

Maybe now I am completely confused?

Phil

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





On 2013-05-30, at 10:12 AM, Phil Hunt wrote:



The issue is that it has different issuing/lifecycle than normal. E.g. Why =
is it issued by the registration endpoint?

Why doesn't the client just request an access token using its client creden=
tial for the registration endpoint when it wants to update its profile?

Phil

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





On 2013-05-30, at 10:08 AM, John Bradley wrote:



The reg access token is a OAuth bearer token that is issued as part of the =
registration response and used to access the new client resource for reads =
and or updates depending on the permissions.

They are both oauth access tokens.

On 2013-05-30, at 12:02 PM, Phil Hunt  wrote:



Seriously. The new dyn reg draft introduces two new tokens. The initial reg=
 token and the registration access token.

As for the latter, the reg access token, my understanding is it has nothing=
 to do with an access token. It is issued *after* registration to allow reg=
 updates.  Right? I know some are confused about this.

Phil

On 2013-05-30, at 8:52, Phil Hunt  wrote:



No different issue. I was concerned about the initial client assertion bein=
g passed in as authen cred. It is a signed set of client reg metadata.

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley  wrote:



I think Phil also had some processing reason why a Token endpoint or RS wou=
ldn't want to tale the authentication as a header, as the processing was ea=
sier with them as parameters as they are potentially available to different=
 parts of the stack.   That may have been mostly around RS, but the princip=
al may apply to the token endpoint as well.

On 2013-05-30, at 10:21 AM, Justin Richer  wrote:



"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the cli=
ent secret. If an authorization server supports both, both should work for =
any client. So are both methods treated differently?


I agree, and this was one of my original arguments for making this field pl=
ural (or plural-able), but there hasn't been WG support for that so far.


I'm not arguing to make it plural. I think the authentication method is jus=
t "client_secret".


That was also an option that was brought up, but in the OIDC WG the counter=
-argument was (as I recall) that the two are syntactically separate and the=
re's a desire to restrict to a single type, such as disabling client_secret=
_post. Basically, to make it unambiguous.


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


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


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


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










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








Comments inline, marked by [JR].






From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-=
11.txt






See below.







On 2013-05-30, at 2:09 PM, Justin Richer wrote:






OK, I think see part of the hang up. I have not se=
en the scenario that you describe, where you trade a 3rd party token for a =
"local" token. I have seen where access tokens are federated dire=
ctly at the PR. (Introspection lets you do some
 good things with that pattern.) But that's neither here nor there, as you =
can already do what you're asking for and I think I can clear things up:


In your case, the "3rd party bearer assertion" is simply *not* th=
e Initial Registration Token. It's an assertion that can be used to *get* a=
n Initial Registration Token. The token that you get from the Token Endpoin=
t, in your case, would be "local" from your
 own AS. Your registration endpoint would look at this token on the way in,=
 know how to validate it, do whatever else it wants to with it, and process=
 the registration. Then it would issue a Registration Access Token that to =
the registering client to use at
 the RESTful endpoint. Incidentally, that token would also be "local&q=
uot;, just like before.








How you (the client/developer) get the actual Init=
ial Registration Token is completely and forever out of scope for the Dynam=
ic Registration spec.











[PH]  Yes, the issuance of the third party bearer assertion token toke=
n would be out of scope of this spec.







If however the group decides to except federated direct access tokens =
as registration *access* tokens, then I think we have to define federation =
for access tokens first.   For me, I think this is something that shou=
ld be discussed in a different charter.




[JR] It's an access token, plain and simple. The dra=
ft doesn't care -- and shouldn't care -- if it's federated or not. I agree<=
font color=3D"3366FF">, and have been arguing all along, that if you=
 have a use case for federated access
 tokens, you need to define the mechanisms for such tokens, and that regist=
ration is *not* the place for that definition. It's =
orthogonal but they can be used together. Let's define them separately
but in a compatible way. 














This all still fits with the current definitions as they are. You don't hav=
e to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any =
content or semantics tied to the
 processing of the Initial Registration Token or calling it an Assertion or=
 anything -- it's up to the AS to process it however it would normally proc=
ess an OAuth Access token. So if your AS needs a local token, then you need=
 to use a local token. If you don't
 want to use structured foreign tokens as your Initial Registration Tokens,=
 don't. But that shouldn't preclude others of us from doing so.










[PH] The difference is where the client is expected to present the federate=
d (aka 3rd party) assertion.  I would rather follow the standard 6749 =
4.5 method in all cases for consistency.  







You can choose to short circuit, but I think the draft should follow a=
 consistent methodology.




[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as i=
t's talking about access to the token endpoint and not to protected resourc=
es. Additionally, people do use assertions encoded inside of OAuth tokens d=
irectly at protected resources all
 the time (since OAuth2 tokens are opaque to clients but must be understood=
 by protected resources), but that's *still* completely irrelevant to this =
discussion because it doesn't matter in terms of the interoperability of th=
e protocol. If you want to use assertions
 or auth codes or client credentials or magic to get your Initial Registrat=
ion Token, the dynamic registration protocol doesn't care how you did it. J=
ust like any other OAuth2 protected resource doesn't care how you got the t=
oken. This abstraction was one of
 the key insights in how OAuth2 is structured as a framework and protocol. =
The important thing here is that if the client gets an Initial Registration=
 Token it knows where to send it and how to use it. What I hear you saying =
is that you don't want to use a
 federated token as an Initial Registration Token. That's fine! Don't do it=
 -- and you have that option precisely because of how we've already written=
 it! If your clients get handed a token that *isn't* an Initial Registratio=
n Token and you want them to go
 through another step to *get* an Initial Registration Token, so be it! But=
 it doesn't make sense to encode that behavior as required into the registr=
ation protocol, because (as you point out) not everything is going to be an=
 assertion in the first place. Again
 I say that you can do everything that you want to do with existing mechani=
sms or self-contained extensions.









If you think it would be helpful, I can add language to the lifecycle discu=
ssion to clarify that the Initial Registration Token can be gotten through =
any number of means, not just the manual-portal approach that's talked abou=
t now. Or if you want to write up
 this specific use case we can add it as another concrete example. 










[PH] I think there is potential to cut a lot of text out of the spec if we =
strictly define the registration endpoint as a normal OAuth2 protected endp=
oint.



[JR] I don't understand what you're saying here -- i=
t already *is* an OAuth2 protected endpoint, like I've pointed out below. A=
ll OAuth2 protected endpoints don't care how you get the token, neither doe=
s this one. All OAuth2 protected endpoints
 don't care (from OAuth2's perspective) how the token is verified or proces=
sed, and neither does this one (from the draft's perspective). I explicitly=
 want to keep that kind of token and assertion processing *out* of this dra=
ft because it's more useful to build
 generally applicable mechanisms. If we keep the registration endpoint as a=
n OAuth2 protected endpoint -- like it already is -- then we can inherit wh=
atever mechanisms you want, and that is a very powerful setup.






I will close by pointing out that I have *never* proposed that we dictate t=
hat the Registration Endpoint have to accept and process federated tokens, =
and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and
 the Registration Access Token being plain old opaque-to-the-client OAuth 2=
 tokens.











[PH] Agreed.  However, the use case of a 3rd party signer for client a=
pplications is critical to both commercial organizations and open source or=
gs that publish software that are deployed by many separate entities.  =
;The client developer needs to be able to
 contact the publisher in many cases to obtain a signed assertion.  






I believe this is a core use case.  







I believe as I've proposed it using the normal 4.5 exchange federated =
assertion for local token method, the draft doesn't have to get into the de=
tails of the assertion.  Though that said, I would suggest the draft m=
ake some suggestions on the contents
 of such assertions.



[JR] You can already do what you want to without men=
tioning assertions. The current draft doesn't mention assertions at all, ei=
ther. All talk of use of assertions is outside the scope of registration. Y=
ou're proposing adding it in, and
 I'm strongly against that. 






I think it's possible that you're still conflating the work I'm doing with =
the BB+ *extension* to dynamic registration with the dynamic registrati=
on document itself. I have never suggested that we pull all the extended BB=
+ stuff down into Dyn Reg, and in fact
 I think quite the opposite as I don't believe it's as generally applicable=
 without the larger BB+ stack (which includes discovery as well as reli=
ance on policy and other frameworks).











[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have v=
ery similar requirements.  As I said above, the use case is a key use =
case. 







However I agree, the way you solve it in BB+ is not the way to sol=
ve it within the draft spec.  I think the BB+ does well inform our=
 discussions though.



[JR] Considering that BB+ manages to do all of t=
his with a cleanly defined extension without any changes in the existing dr=
aft text, I think that's as strong an argument as anything to keep it defin=
ed how it is, and that what's there is
 a sufficient base to build on.






 -- Justin




On 05/30/2013 03:54 PM, Phil Hunt wrote:




Justin,






So far, every time an OAuth server has accepted a 3rd party token it h=
as been a bearer assertion. The common pattern is to exchange that assertio=
n for a an access token issued by the local server for the local resource e=
ndpoint.







That's the pattern I am trying to follow.







Going this way means we do not have to define the initial registration=
 token.







If however, you really want to use the initial registration token AS a=
n access token, you are taking us into the question of using federated acce=
ss tokens.  I prefer not to do that here.


















On 2013-05-30, at 12:51 PM, Justin Richer wrote:






I don't understand which access token is being tal=
ked about here -- is this the Initial Registration Token? Because you can a=
lready do everything below. How you get the Initial Registration token is o=
ut of scope precisely so that the
 AS can decide what that means. We can add language in the lifecycle discus=
sions to bring up the fact that you can get this token from an OAuth flow, =
if you think that'll help clear things up.



However, the client doesn't register using the client credential flow at al=
l -- it registers using a POST to the registration endpoint, and that POST =
might have an OAuth token attached to it. How the client got that OAuth tok=
en is, again, out of scope. The
 client could have done some other OAuth flow (any OAuth flow) to get a hol=
d of the token, but how is it supposed to get an OAuth token at an AS it ha=
sn't been registered with?




Now, if you're talking about the Registration Access Token, though, that ma=
kes less sense to me. The client *has* to register first before it can get =
*anything* from the token endpoint. What you're suggesting is that all clie=
nts be given access to the token
 endpoint with the client credentials flow for the purposes of retrieving t=
he Registration Access Token, unless I misread things. You probably don't w=
ant the client getting other scopes from the token endpoint using the clien=
t credentials flow, as it'd be an
 enormous security risk. Thing is, I don't think I can implement that level=
 of separation in my app stack, and I haven't seen any others that do that.=
 Separating access to different endpoints based on OAuth tokens (and the sc=
opes attached) is par for the course,
 though.



Let me run down how it works in our own setup. When a client registers, we =
create a new token (using a TokenServices class) that has a special scope, =
"registration-token". This token is tied to the client_id to whic=
h it was issued. Clients cannot get tokens
 with this scope through the usual Token Endpoint means, by design. All of =
the Client Configuration Endpoint URLs are protected such that they require=
 access from a valid token with the scope "registration-token", a=
nd the client_id tied to that token MUST match
 the client_id in the URL. Each client is limited to the OAuth flows (grant=
_types and response_types) that it's allowed to call from the token endpoin=
t. All of this is specific to our implementation, but I can speak with some=
 authority that it's at least implementable
 this way. This method lets us do public clients, confidential clients, pub=
lic-key clients (that use JWT assertions to call the token endpoint), and a=
ll different OAuth flows.




If we were to switch things to what you're recommending (using client crede=
ntials to get the equivalent of the Registration Access Token), I would nee=
d to issue some form of client credentials to all clients (including public=
 clients) and allow all dynamically
 registered clients access to the client_credentials flow at the token endp=
oint but only if they're asking for a registration-token scope, a scope val=
ue which hasn't been standardized either. I don't think this is even possib=
le in my architecture, and it's
 certainly not desirable. 



If we were to switch to having the client credentials used directly on the =
registration endpoint, then you get back into the situation that OIDC has a=
lready tried, and which failed. I see no reason to try the same thing again=
 and expect different results.



I will admit that it was a little strange when I first pulled the TokenServ=
ices reference into our RegistrationEndpoint class, but doing so greatly si=
mplified everything else. I can see the desire to have an ideological purit=
y of "all tokens come from the token
 endpoint", but such purity just doesn't help in this case. 



 -- Justin




On 05/30/2013 03:31 PM, Phil Hunt wrote:




For this, I would suggest:






Anonymous, user assisted registration - client registers using the cli=
ent credential flow but may use an administrator (in the case of web app) o=
r end-user (uid/password) .  Since resource owner would still require =
separate credential, then the client
 flow could be used even though we are passing end-user creds. Client obtai=
ns access token limited to registering the new entity.







Anonymous unassisted registration (no user present) - the only solutio=
n I can come up with is the client self asserted client_id (e.g. UUID) that=
 the token endpoint chooses to accept if scope equals "registration&qu=
ot; (or whatever the scope is to be for registration).
   IMHO this should be avoided.







3rd Party Assertion - client presents signed assertion in the form of =
JWT or SAML Bearer assertion and exchanges for an access token. Access is l=
imited to registering a new entity.







The value of the access token being short lived or potentially even si=
ngle-use (or limited use, like 3 tries), would be to prevent abuse of the r=
egistration end-point.










On 2013-05-30, at 11:59 AM, Justin Richer wrote:






But this still doesn't address clients who don't h=
ave a client_secret. Do they now need one in order to talk to the registrat=
ion endpoint? What you're suggesting is that a client use one set of creden=
tials to get access tokens and another
 set of credentials to get registrations. This is certainly no simpler.



And this exact functionality was tried, implemented, and rejected as too co=
mplicated by the OpenID Connect community. I don't see why it'd be any diff=
erent the second time around.



I really don't see any reason to change it. 



 -- Justin




On 05/30/2013 02:56 PM, Phil Hunt wrote:




It's hard to say what the best solution here is r=
egarding clarifications until we get clarity on the issue of registration a=
ccess token.






I don't think using a client credential flow to obtain an access token=
 to the registration endpoint is complex. It's the normal flow.  






I concede that you are looking at it as using Client Credential to get=
 an access token to get a new Client Credential. But that's not really what=
 is happening in terms of protocol here.  







If you take the perspective that the client needs to occasionally upda=
te registration (e.g. because of a pending credential expiry), then it is s=
till simple. You use client credential flow to obtain an access token to up=
date registration. Then, from the
 context of the REST API, the client credential is just another piece of JS=
ON data.







IOW from the REST perspective, it is the registration endpoint that is=
 being updated, not the client credential.  The client credential is j=
ust data in the perspective of REST.







I think you may be inferring complexity where there really is none.













On 2013-05-30, at 11:33 AM, Justin Richer wrote:






Thanks for clearing up where the confusion was tak=
ing place. I had tried to make it clear that these were absolutely standard=
, opaque OAuth2 bearer tokens and absolutely standard OAuth2-protected endp=
oints, but if that's not clear that
 needs to be updated. This is what the text says right now:




The Client Registration Endpoint MAY accept an Initial Access T=
oken in the form of an

OAuth 2.0 [RFC6749] access token to limit r=
egistration to only previously authorized parties. The method by which the =
Initial Access Token is obtained by the registrant is generally out-of-band=
 and is out of scope of this specification.





And:




The Client Configuration Endpoint is an OAuth 2.0 protected res=
ource that is provisioned by the server for a specific client to be able to=
 view and update its registered information. The location of this endpoint =
is communicated to the Client through
 the registration_client_uri member of the 
Client Information Response [client-info-response]=
. The Client MUST use its Registration Access Token in all calls to =
this endpoint as an

OAuth 2.0 Bearer Token [RFC6750].





Along with the definitions in the introduction:




Registration Access Token 
OAuth 2.=
0 Bearer Token issued by the Authorization Server through the Client Regist=
ration Endpoint that is used to authenticate the caller when accessing the =
Client's registration information at the Client Configuration Endpoint. Thi=
s
 Access Token is associated with a particular registered Client. 
I=
nitial Access Token 
An OAuth 2.0 Access To=
ken optionally issued by an Authorization Server granting access to its Cli=
ent Registration Endpoint.






I'd welcome any proposed changes to the text to make this clearer.



As to the other suggestion, what you're saying is to use the client credent=
ials to get an access token to get the client credentials ... ? I can see t=
he argument for using the oauth client credentials flow, but I think that's=
 far more complicated than an endpoint
 saying "here's a token, go use it", personally. Besides, not all=
 clients have credentials at the token endpoint, so it's a bit of a non-sta=
rter for a large class of clients.



 -- Justin






On 05/30/2013 01:55 PM, Phil Hunt wrote:






I see what is happening.=0A=
=0A=
I think the reason why I find this spec sooo confusing is that the terms im=
ply new token types when they don't.=0A=
=0A=
For example when you say "Registration Access Token" and "In=
itial Access Token" it implies to me that it is a totally new token ty=
pe (and in one case it sorta is). When you read the spec (particularly draf=
t 10) it is easy to assume something very different is going on. Hence my p=
ush back.=0A=
=0A=
It is now clear to me that what you mean to say is *Access Token used for i=
nitial access* and *Access Token used for registration*.=0A=
=0A=
Why not write the draft to make clear that the registration end point is ju=
st a NORMAL OAuth2 Enabled REST endpoint?  That way you can eliminate all o=
f the terminology and lifecycle around access tokens except to say the endp=
oint is accessed by tokens issued based on the scope "oauth2:registrat=
ion".=0A=
=0A=
That only brings issues with the registration token.  The "Access Toke=
n used for registration" seems to have special lifecycle differences.=
=0A=
1.  Issed by reg endpoint as part of successful registration=0A=
2.  Has a different lifetime than the client credential (whatever it is).=
=0A=
=0A=
Why not again simplify and follow normal OAuth2 pattern and have the access=
 token issued for registration be *short* lived.  Each time the client want=
s to either initially register or update its profile it must request a norm=
al access token with scope "oauth2:registration". =0A=
=0A=
As for client credential expiry, why not simply require the client to updat=
e its registration before it expires?  Why have a long-lived "registra=
tion access token" that has to be managed as well?=0A=
=0A=
Maybe now I am completely confused?=0A=
=0A=
Phil=0A=
=0A=
@independentid=0A=
www.independentid.com=0A=
phil.hunt@oracle.com=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
On 2013-05-30, at 10:12 AM, Phil Hunt wrote:=0A=
=0A=





The issue is that it has different issuing/lifecycle than normal. E.g.=
 Why is it issued by the registration endpoint?=0A=
=0A=
Why doesn't the client just request an access token using its client creden=
tial for the registration endpoint when it wants to update its profile?=0A=
=0A=
Phil=0A=
=0A=
@independentid=0A=
www.independentid.com=0A=
phil.hunt@oracle.com=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
On 2013-05-30, at 10:08 AM, John Bradley wrote:=0A=
=0A=





The reg access token is a OAuth bearer token that is issued as part of=
 the registration response and used to access the new client resource for r=
eads and or updates depending on the permissions.=0A=
=0A=
They are both oauth access tokens.=0A=
=0A=
On 2013-05-30, at 12:02 PM, Phil Hunt <phil.hunt@oracle.c=
om> wrote:=0A=
=0A=





Seriously. The new dyn reg draft introduces two new tokens. The initia=
l reg token and the registration access token. =0A=
=0A=
As for the latter, the reg access token, my understanding is it has nothing=
 to do with an access token. It is issued *after* registration to allow reg=
 updates.  Right? I know some are confused about this. =0A=
=0A=
Phil=0A=
=0A=
On 2013-05-30, at 8:52, Phil Hunt <phil.hunt@oracle.com=
> wrote:=0A=
=0A=





No different issue. I was concerned about the initial client assertion=
 being passed in as authen cred. It is a signed set of client reg metadata.=
 =0A=
=0A=
See we are confused. Hence my worry. :-)=0A=
=0A=
Phil=0A=
=0A=
On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com><=
/a> wrote:=0A=
=0A=





I think Phil also had some processing reason why a Token endpoint or R=
S wouldn't want to tale the authentication as a header, as the processing w=
as easier with them as parameters as they are potentially available to diff=
erent parts of the stack.   That may have been mostly around RS, but the pr=
incipal may apply to the token endpoint as well.=0A=
=0A=
On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org=
> wrote:=0A=
=0A=











"client_secret_post vs client_secret_basic"=0A=
BASIC and POST are essentially the same just different ways to send the cli=
ent secret. If an authorization server supports both, both should work for =
any client. So are both methods treated differently?=0A=





I agree, and this was one of my original arguments for making this fie=
ld plural (or plural-able), but there hasn't been WG support for that so fa=
r.=0A=





I'm not arguing to make it plural. I think the authentication method i=
s just "client_secret".=0A=





That was also an option that was brought up, but in the OIDC WG the co=
unter-argument was (as I recall) that the two are syntactically separate an=
d there's a desire to restrict to a single type, such as disabling client_s=
ecret_post. Basically, to make it unambiguous.=0A=





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





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









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





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





































































--_000_B33BFB58CCC8BE4998958016839DE27E08F97708IMCMBX01MITREOR_--

From sooolooo.mm@gmail.com  Thu May 30 16:20:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF021F90CD for ; Thu, 30 May 2013 16:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.821
X-Spam-Level: **
X-Spam-Status: No, score=2.821 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EMPTY_MESSAGE=1.439, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSzCfMZ2ShTE for ; Thu, 30 May 2013 16:20:25 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6206921F9080 for ; Thu, 30 May 2013 16:20:25 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id fq12so816276lab.34 for ; Thu, 30 May 2013 16:20:24 -0700 (PDT)
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=r6cfW71zsMAK/MWgqD8vfimT8U8WABMh5Hgt2cTkJNI=; b=nzRg36xbt57y6rrf7zb0NH5VRbkdjE1XLtdpYtZmasTgGoqRmL4r0LrH8ibCdWiUmX 8h/MHxw0kuuKPOtBVXC4H9B0cU2MinR7UchRsefts3fYeBNY5S5DBOC6dvBJnwG4lwUe s2hjujedXUfashLhsrcjlbwEQeohoFFo5ylfEQ3qURvfHE25hGCyXterJKx1KAggmvJl S9LfhVedpzkv6kPAtIRR15ilsTQnsBqGMG3OhAqtU7Vk8yG98jZy/aG+7gOptLcHReNy lBrFs9BZT8RfNXzntpvAyVhyz0KwrZgGnqYttSvbOgtY5hbGsHxTsEBpS96hwyr87/+R +Q8w==
MIME-Version: 1.0
X-Received: by 10.112.22.97 with SMTP id c1mr4646432lbf.52.1369956024282; Thu, 30 May 2013 16:20:24 -0700 (PDT)
Received: by 10.112.59.67 with HTTP; Thu, 30 May 2013 16:20:24 -0700 (PDT)
Received: by 10.112.59.67 with HTTP; Thu, 30 May 2013 16:20:24 -0700 (PDT)
Date: Fri, 31 May 2013 01:20:24 +0200
Message-ID: 
From: Maik Mahn 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=14dae94736072f752304ddf7be89
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 30 May 2013 23:20:26 -0000

--14dae94736072f752304ddf7be89
Content-Type: text/plain; charset=ISO-8859-1



--14dae94736072f752304ddf7be89
Content-Type: text/html; charset=ISO-8859-1



--14dae94736072f752304ddf7be89--

From phil.hunt@oracle.com  Thu May 30 16:31:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF08121F8972 for ; Thu, 30 May 2013 16:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.962
X-Spam-Level: 
X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRel1Fang+V8 for ; Thu, 30 May 2013 16:31:17 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 52DEB21F98F4 for ; Thu, 30 May 2013 16:31:17 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UNVDPv014865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 23:31:14 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UNVENO005577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 23:31:14 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UNVDNb015308; Thu, 30 May 2013 23:31:13 GMT
Received: from [25.65.60.94] (/24.114.38.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 16:31:12 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-B5D284B8-6BCC-4080-BB65-5313D35C2BF1
Content-Transfer-Encoding: 7bit
Message-Id: <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Thu, 30 May 2013 16:31:07 -0700
To: "Richer, Justin P." 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 23:31:37 -0000

--Apple-Mail-B5D284B8-6BCC-4080-BB65-5313D35C2BF1
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



Phil

On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:

> Comments inline, marked by [JR].
>=20
> From: Phil Hunt [phil.hunt@oracle.com]
> Sent: Thursday, May 30, 2013 5:25 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt=

>=20
> See below.
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>=20
>> OK, I think see part of the hang up. I have not seen the scenario that yo=
u describe, where you trade a 3rd party token for a "local" token. I have se=
en where access tokens are federated directly at the PR. (Introspection lets=
 you do some good things with that pattern.) But that's neither here nor the=
re, as you can already do what you're asking for and I think I can clear thi=
ngs up:
>>=20
>> In your case, the "3rd party bearer assertion" is simply *not* the Initia=
l Registration Token. It's an assertion that can be used to *get* an Initial=
 Registration Token. The token that you get from the Token Endpoint, in your=
 case, would be "local" from your own AS. Your registration endpoint would l=
ook at this token on the way in, know how to validate it, do whatever else i=
t wants to with it, and process the registration. Then it would issue a Regi=
stration Access Token that to the registering client to use at the RESTful e=
ndpoint. Incidentally, that token would also be "local", just like before.
>=20
>> How you (the client/developer) get the actual Initial Registration Token i=
s completely and forever out of scope for the Dynamic Registration spec.
>=20
> [PH]  Yes, the issuance of the third party bearer assertion token token wo=
uld be out of scope of this spec.
>=20
> If however the group decides to except federated direct access tokens as r=
egistration *access* tokens, then I think we have to define federation for a=
ccess tokens first.   For me, I think this is something that should be discu=
ssed in a different charter.
>=20
> [JR] It's an access token, plain and simple. The draft doesn't care -- and=
 shouldn't care -- if it's federated or not. I agree, and have been arguing a=
ll along, that if you have a use case for federated access tokens, you need t=
o define the mechanisms for such tokens, and that registration is *not* the p=
lace for that definition. It's orthogonal but they can be used together. Let=
's define them separately but in a compatible way.=20
>=20
[ph] thats not the impression i get from the draft. As i mentioned earlier u=
sing access token for registration is clearer.=20
>>=20
>>=20
>> This all still fits with the current definitions as they are. You don't h=
ave to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any c=
ontent or semantics tied to the processing of the Initial Registration Token=
 or calling it an Assertion or anything -- it's up to the AS to process it h=
owever it would normally process an OAuth Access token. So if your AS needs a=
 local token, then you need to use a local token. If you don't want to use s=
tructured foreign tokens as your Initial Registration Tokens, don't. But tha=
t shouldn't preclude others of us from doing so.
>=20
> [PH] The difference is where the client is expected to present the federat=
ed (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 m=
ethod in all cases for consistency. =20
>=20
> You can choose to short circuit, but I think the draft should follow a con=
sistent methodology.
>=20
> [JR] 6749 section 4.5 (extension grants) is irrelevant to registration as i=
t's talking about access to the token endpoint and not to protected resource=
s. Additionally, people do use assertions encoded inside of OAuth tokens dir=
ectly at protected resources all the time (since OAuth2 tokens are opaque to=
 clients but must be understood by protected resources), but that's *still* c=
ompletely irrelevant to this discussion because it doesn't matter in terms o=
f the interoperability of the protocol. If you want to use assertions  or au=
th codes or client credentials or magic to get your Initial Registration Tok=
en, the dynamic registration protocol doesn't care how you did it. Just like=
 any other OAuth2 protected resource doesn't care how you got the token. Thi=
s abstraction was one of the key insights in how OAuth2 is structured as a f=
ramework and protocol. The important thing here is that if the client gets a=
n Initial Registration Token it knows where to send it and how to use it. Wh=
at I hear you saying is that you don't want to use a federated token as an I=
nitial Registration Token. That's fine! Don't do it -- and you have that opt=
ion precisely because of how we've already written it! If your clients get h=
anded a token that *isn't* an Initial Registration Token and you want them t=
o go through another step to *get* an Initial Registration Token, so be it! B=
ut it doesn't make sense to encode that behavior as required into the regist=
ration protocol, because (as you point out) not everything is going to be an=
 assertion in the first place. Again I say that you can do everything that y=
ou want to do with existing mechanisms or self-contained extensions.=20

[ph] i am referring to the mechanism currently defined that accepts external=
 assertions in exchange for access tokens within the server.=20

When you do it this way all clients are now accessing the reg endpoint with a=
 short term access token.=20

If you want to make federated access tokens a formal approach you need to pr=
ofile it since there is no spec for federated access tokens.=20

IOW, handle federated access tokens the same way 6749 does which is to say n=
othing.=20

If you do this you can really simplify registration because now it just norm=
al oauth protected resource without any special handling.=20

>=20
>>=20
>> If you think it would be helpful, I can add language to the lifecycle dis=
cussion to clarify that the Initial Registration Token can be gotten through=
 any number of means, not just the manual-portal approach that's talked abou=
t now. Or if you want to write up this specific use case we can add it as an=
other concrete example.
>=20
> [PH] I think there is potential to cut a lot of text out of the spec if we=
 strictly define the registration endpoint as a normal OAuth2 protected endp=
oint.
>=20
> [JR] I don't understand what you're saying here -- it already *is* an OAut=
h2 protected endpoint, like I've pointed out below. All OAuth2 protected end=
points don't care how you get the token, neither does this one. All OAuth2 p=
rotected endpoints don't care (from OAuth2's perspective) how the token is v=
erified or processed, and neither does this one (from the draft's perspectiv=
e). I explicitly want to keep that kind of token and assertion processing *o=
ut* of this draft because it's more useful to build generally applicable mec=
hanisms. If we keep the registration endpoint as an OAuth2 protected endpoin=
t -- like it already is -- then we can inherit whatever mechanisms you want,=
 and that is a very powerful setup.
>>=20
>> I will close by pointing out that I have *never* proposed that we dictate=
 that the Registration Endpoint have to accept and process federated tokens,=
 and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and the Registration Access Token being plain o=
ld opaque-to-the-client OAuth 2 tokens.
>=20
> [PH] Agreed.  However, the use case of a 3rd party signer for client appli=
cations is critical to both commercial organizations and open source orgs th=
at publish software that are deployed by many separate entities.  The client=
 developer needs to be able to contact the publisher in many cases to obtain=
 a signed assertion. =20
>=20
> I believe this is a core use case. =20
>=20
> I believe as I've proposed it using the normal 4.5 exchange federated asse=
rtion for local token method, the draft doesn't have to get into the details=
 of the assertion.  Though that said, I would suggest the draft make some su=
ggestions on the contents of such assertions.
>=20
> [JR] You can already do what you want to without mentioning assertions. Th=
e current draft doesn't mention assertions at all, either. All talk of use o=
f assertions is outside the scope of registration. You're proposing adding i=
t in, and I'm strongly against that.=20
>>=20
>> I think it's possible that you're still conflating the work I'm doing wit=
h the BB+ *extension* to dynamic registration with the dynamic registration d=
ocument itself. I have never suggested that we pull all the extended BB+ stu=
ff down into Dyn Reg, and in fact I think quite the opposite as I don't beli=
eve it's as generally applicable without the larger BB+ stack (which include=
s discovery as well as reliance on policy and other frameworks).
>=20
> [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have v=
ery similar requirements.  As I said above, the use case is a key use case.=20=

>=20
> However I agree, the way you solve it in BB+ is not the way to solve it wi=
thin the draft spec.  I think the BB+ does well inform our discussions thoug=
h.
>=20
> [JR] Considering that BB+ manages to do all of this with a cleanly defined=
 extension without any changes in the existing draft text, I think that's as=
 strong an argument as anything to keep it defined how it is, and that what'=
s there is a sufficient base to build on.
>>=20
>>  -- Justin
>>=20
>> On 05/30/2013 03:54 PM, Phil Hunt wrote:
>>> Justin,
>>>=20
>>> So far, every time an OAuth server has accepted a 3rd party token it has=
 been a bearer assertion. The common pattern is to exchange that assertion f=
or a an access token issued by the local server for the local resource endpo=
int.
>>>=20
>>> That's the pattern I am trying to follow.
>>>=20
>>> Going this way means we do not have to define the initial registration t=
oken.
>>>=20
>>> If however, you really want to use the initial registration token AS an a=
ccess token, you are taking us into the question of using federated access t=
okens.  I prefer not to do that here.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>>>=20
>>>> I don't understand which access token is being talked about here -- is t=
his the Initial Registration Token? Because you can already do everything be=
low. How you get the Initial Registration token is out of scope precisely so=
 that the AS can decide what that means. We can add language in the lifecycl=
e discussions to bring up the fact that you can get this token from an OAuth=
 flow, if you think that'll help clear things up.
>>>>=20
>>>> However, the client doesn't register using the client credential flow a=
t all -- it registers using a POST to the registration endpoint, and that PO=
ST might have an OAuth token attached to it. How the client got that OAuth t=
ok=3D

--Apple-Mail-B5D284B8-6BCC-4080-BB65-5313D35C2BF1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Phil







Comments inline, marked by [JR].








From: Phil Hunt [phil.hunt@oracle.com]

Sent: Thursday, May 30, 2013 5:25 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-1=
1.txt






See below.







On 2013-05-30, at 2:09 PM, Justin Richer wrote:






OK, I think see part of the hang up. I have not see=
n the scenario that you describe, where you trade a 3rd party token for a "l=
ocal" token. I have seen where access tokens are federated directly at the P=
R. (Introspection lets you do some
 good things with that pattern.) But that's neither here nor there, as you c=
an already do what you're asking for and I think I can clear things up:



In your case, the "3rd party bearer assertion" is simply *not* the Initial R=
egistration Token. It's an assertion that can be used to *get* an Initial Re=
gistration Token. The token that you get from the Token Endpoint, in your ca=
se, would be "local" from your
 own AS. Your registration endpoint would look at this token on the way in, k=
now how to validate it, do whatever else it wants to with it, and process th=
e registration. Then it would issue a Registration Access Token that to the r=
egistering client to use at
 the RESTful endpoint. Incidentally, that token would also be "local", just l=
ike before.








How you (the client/developer) get the actual Initi=
al Registration Token is completely and forever out of scope for the Dynamic=
 Registration spec.











[PH]  Yes, the issuance of the third party bearer assertion token token=
 would be out of scope of this spec.







If however the group decides to except federated direct access tokens a=
s registration *access* tokens, then I think we have to define federation fo=
r access tokens first.   For me, I think this is something that should b=
e discussed in a different charter.




[JR] It's an access token, plain and simple. The draf=
t doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you ha=
ve a use case for federated access
 tokens, you need to define the mechanisms for such tokens, and that registr=
ation is *not* the place for that definition. It's or=
thogonal but they can be used together. Let's define them separately
but in a compatible way. 


[ph] tha=
ts not the impression i get from the draft. As i mentioned earlier using acc=
ess token for registration is clearer. 












This all still fits with the current definitions as they are. You don't have=
 to use federated tokens if you don't want to. I can still use them if I wan=
t to. Everybody's happy! And this is all because we are not defining any con=
tent or semantics tied to the
 processing of the Initial Registration Token or calling it an Assertion or a=
nything -- it's up to the AS to process it however it would normally process=
 an OAuth Access token. So if your AS needs a local token, then you need to u=
se a local token. If you don't
 want to use structured foreign tokens as your Initial Registration Tokens, d=
on't. But that shouldn't preclude others of us from doing so.










[PH] The difference is where the client is expected to present the federated=
 (aka 3rd party) assertion.  I would rather follow the standard 6749 4.=
5 method in all cases for consistency.  







You can choose to short circuit, but I think the draft should follow a c=
onsistent methodology.




[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as it=
's talking about access to the token endpoint and not to protected resources=
. Additionally, people do use assertions encoded inside of OAuth tokens dire=
ctly at protected resources all
 the time (since OAuth2 tokens are opaque to clients but must be understood b=
y protected resources), but that's *still* completely irrelevant to this dis=
cussion because it doesn't matter in terms of the interoperability of the pr=
otocol. If you want to use assertions
 or auth codes or client credentials or magic to get your Initial Registrati=
on Token, the dynamic registration protocol doesn't care how you did it. Jus=
t like any other OAuth2 protected resource doesn't care how you got the toke=
n. This abstraction was one of
 the key insights in how OAuth2 is structured as a framework and protocol. T=
he important thing here is that if the client gets an Initial Registration T=
oken it knows where to send it and how to use it. What I hear you saying is t=
hat you don't want to use a
 federated token as an Initial Registration Token. That's fine! Don't do it -=
- and you have that option precisely because of how we've already written it=
! If your clients get handed a token that *isn't* an Initial Registration To=
ken and you want them to go
 through another step to *get* an Initial Registration Token, so be it! But i=
t doesn't make sense to encode that behavior as required into the registrati=
on protocol, because (as you point out) not everything is going to be an ass=
ertion in the first place. Again
 I say that you can do everything that you want to do with existing mechanis=
ms or self-contained extensions.


[ph] i a=
m referring to the mechanism currently defined that accepts external asserti=
ons in exchange for access tokens within the server. 

When you do it this way all clients are now accessing the reg endpoint wit=
h a short term access token. 

If you want to m=
ake federated access tokens a formal approach you need to profile it since t=
here is no spec for federated access tokens. 

=
IOW, handle federated access tokens the same way 6749 does which is to say n=
othing. 

If you do this you can really simplif=
y registration because now it just normal oauth protected resource without a=
ny special handling. 









If you think it would be helpful, I can add language to the lifecycle discus=
sion to clarify that the Initial Registration Token can be gotten through an=
y number of means, not just the manual-portal approach that's talked about n=
ow. Or if you want to write up
 this specific use case we can add it as another concrete example. 










[PH] I think there is potential to cut a lot of text out of the spec if we s=
trictly define the registration endpoint as a normal OAuth2 protected endpoi=
nt.



[JR] I don't understand what you're saying here -- it=
 already *is* an OAuth2 protected endpoint, like I've pointed out below. All=
 OAuth2 protected endpoints don't care how you get the token, neither does t=
his one. All OAuth2 protected endpoints
 don't care (from OAuth2's perspective) how the token is verified or process=
ed, and neither does this one (from the draft's perspective). I explicitly w=
ant to keep that kind of token and assertion processing *out* of this draft b=
ecause it's more useful to build
 generally applicable mechanisms. If we keep the registration endpoint as an=
 OAuth2 protected endpoint -- like it already is -- then we can inherit what=
ever mechanisms you want, and that is a very powerful setup.






I will close by pointing out that I have *never* proposed that we dictate th=
at the Registration Endpoint have to accept and process federated tokens, an=
d it would be ludicrous to do so. I have been and still am committed to the I=
nitial Registration Token and
 the Registration Access Token being plain old opaque-to-the-client OAuth 2 t=
okens.











[PH] Agreed.  However, the use case of a 3rd party signer for client ap=
plications is critical to both commercial organizations and open source orgs=
 that publish software that are deployed by many separate entities.  Th=
e client developer needs to be able to
 contact the publisher in many cases to obtain a signed assertion.  






I believe this is a core use case.  







I believe as I've proposed it using the normal 4.5 exchange federated a=
ssertion for local token method, the draft doesn't have to get into the deta=
ils of the assertion.  Though that said, I would suggest the draft make=
 some suggestions on the contents
 of such assertions.



[JR] You can already do what you want to without ment=
ioning assertions. The current draft doesn't mention assertions at all, eith=
er. All talk of use of assertions is outside the scope of registration. You'=
re proposing adding it in, and
 I'm strongly against that. 






I think it's possible that you're still conflating the work I'm doing with t=
he BB+ *extension* to dynamic registration with the dynamic registration doc=
ument itself. I have never suggested that we pull all the extended BB+ stuff=
 down into Dyn Reg, and in fact
 I think quite the opposite as I don't believe it's as generally applicable w=
ithout the larger BB+ stack (which includes discovery as well as reliance on=
 policy and other frameworks).











[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have ve=
ry similar requirements.  As I said above, the use case is a key use ca=
se. 







However I agree, the way you solve it in BB+ is not the way to solve it=
 within the draft spec.  I think the BB+ does well inform our discussio=
ns though.



[JR] Considering that BB+ manages to do all of this w=
ith a cleanly defined extension without any changes in the existing draft te=
xt, I think that's as strong an argument as anything to keep it defined how i=
t is, and that what's there is
 a sufficient base to build on.






 -- Justin




On 05/30/2013 03:54 PM, Phil Hunt wrote:




Justin,






So far, every time an OAuth server has accepted a 3rd party token it ha=
s been a bearer assertion. The common pattern is to exchange that assertion f=
or a an access token issued by the local server for the local resource endpo=
int.







That's the pattern I am trying to follow.







Going this way means we do not have to define the initial registration t=
oken.







If however, you really want to use the initial registration token AS an=
 access token, you are taking us into the question of using federated access=
 tokens.  I prefer not to do that here.


















On 2013-05-30, at 12:51 PM, Justin Richer wrote:






I don't understand which access token is being talk=
ed about here -- is this the Initial Registration Token? Because you can alr=
eady do everything below. How you get the Initial Registration token is out o=
f scope precisely so that the
 AS can decide what that means. We can add language in the lifecycle discuss=
ions to bring up the fact that you can get this token from an OAuth flow, if=
 you think that'll help clear things up.



However, the client doesn't register using the client credential flow at all=
 -- it registers using a POST to the registration endpoint, and that POST mi=
ght have an OAuth token attached to it. How the client got that OAuth tok=3D=

<=
/div>
=

--Apple-Mail-B5D284B8-6BCC-4080-BB65-5313D35C2BF1--

From jricher@mitre.org  Thu May 30 16:47:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82821F8F6E for ; Thu, 30 May 2013 16:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.366
X-Spam-Level: 
X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm12Dt3EtPbE for ; Thu, 30 May 2013 16:47:20 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBC21F8F61 for ; Thu, 30 May 2013 16:47:20 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3D501F069E; Thu, 30 May 2013 19:47:19 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8808D1F04A6; Thu, 30 May 2013 19:47:19 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Thu, 30 May 2013 19:47:19 -0400
From: "Richer, Justin P." 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Thread-Index: AQHOXSFKoUPHFo+jJEeuqil8woB+1Jkd4A8XgABEGwCAAALvAIAAEjEAgAABU4CAAAv5AP//zhOmgAAJjwGAAAa4l4AAGWZYgAAdN8SAAEjCgP//wLSP
Date: Thu, 30 May 2013 23:47:19 +0000
Message-ID: 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> , <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>
In-Reply-To: <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.31.52]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E08F977D8IMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 30 May 2013 23:47:26 -0000

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

I don't understand any of the comments below -- it already *is* an OAuth2 p=
rotected resource without any special handling. Your access tokens can be s=
hort-lived, long-lived, federated, structured, random blobs ... totally doe=
sn't matter. They are access tokens being used to access a normal protected=
 resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning a=
re merely examples of some ways you *could* use it and are non-normative an=
d non-exhaustive.

You seem to be asking for something that's already in the draft.

 -- Justin

________________________________
From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt



Phil

On 2013-05-30, at 16:11, "Richer, Justin P." > wrote:

Comments inline, marked by [JR].

________________________________
From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.
Phil

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





On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you =
describe, where you trade a 3rd party token for a "local" token. I have see=
n where access tokens are federated directly at the PR. (Introspection lets=
 you do some good things with that pattern.) But that's neither here nor th=
ere, as you can already do what you're asking for and I think I can clear t=
hings up:

In your case, the "3rd party bearer assertion" is simply *not* the Initial =
Registration Token. It's an assertion that can be used to *get* an Initial =
Registration Token. The token that you get from the Token Endpoint, in your=
 case, would be "local" from your own AS. Your registration endpoint would =
look at this token on the way in, know how to validate it, do whatever else=
 it wants to with it, and process the registration. Then it would issue a R=
egistration Access Token that to the registering client to use at the RESTf=
ul endpoint. Incidentally, that token would also be "local", just like befo=
re.

How you (the client/developer) get the actual Initial Registration Token is=
 completely and forever out of scope for the Dynamic Registration spec.

[PH]  Yes, the issuance of the third party bearer assertion token token wou=
ld be out of scope of this spec.

If however the group decides to except federated direct access tokens as re=
gistration *access* tokens, then I think we have to define federation for a=
ccess tokens first.   For me, I think this is something that should be disc=
ussed in a different charter.

[JR] It's an access token, plain and simple. The draft doesn't care -- and =
shouldn't care -- if it's federated or not. I agree, and have been arguing =
all along, that if you have a use case for federated access tokens, you nee=
d to define the mechanisms for such tokens, and that registration is *not* =
the place for that definition. It's orthogonal but they can be used togethe=
r. Let's define them separately but in a compatible way.

[ph] thats not the impression i get from the draft. As i mentioned earlier =
using access token for registration is clearer.


This all still fits with the current definitions as they are. You don't hav=
e to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any =
content or semantics tied to the processing of the Initial Registration Tok=
en or calling it an Assertion or anything -- it's up to the AS to process i=
t however it would normally process an OAuth Access token. So if your AS ne=
eds a local token, then you need to use a local token. If you don't want to=
 use structured foreign tokens as your Initial Registration Tokens, don't. =
But that shouldn't preclude others of us from doing so.

[PH] The difference is where the client is expected to present the federate=
d (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 m=
ethod in all cases for consistency.

You can choose to short circuit, but I think the draft should follow a cons=
istent methodology.

[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as i=
t's talking about access to the token endpoint and not to protected resourc=
es. Additionally, people do use assertions encoded inside of OAuth tokens d=
irectly at protected resources all the time (since OAuth2 tokens are opaque=
 to clients but must be understood by protected resources), but that's *sti=
ll* completely irrelevant to this discussion because it doesn't matter in t=
erms of the interoperability of the protocol. If you want to use assertions=
 or auth codes or client credentials or magic to get your Initial Registrat=
ion Token, the dynamic registration protocol doesn't care how you did it. J=
ust like any other OAuth2 protected resource doesn't care how you got the t=
oken. This abstraction was one of the key insights in how OAuth2 is structu=
red as a framework and protocol. The important thing here is that if the cl=
ient gets an Initial Registration Token it knows where to send it and how t=
o use it. What I hear you saying is that you don't want to use a federated =
token as an Initial Registration Token. That's fine! Don't do it -- and you=
 have that option precisely because of how we've already written it! If you=
r clients get handed a token that *isn't* an Initial Registration Token and=
 you want them to go through another step to *get* an Initial Registration =
Token, so be it! But it doesn't make sense to encode that behavior as requi=
red into the registration protocol, because (as you point out) not everythi=
ng is going to be an assertion in the first place. Again I say that you can=
 do everything that you want to do with existing mechanisms or self-contain=
ed extensions.

[ph] i am referring to the mechanism currently defined that accepts externa=
l assertions in exchange for access tokens within the server.

When you do it this way all clients are now accessing the reg endpoint with=
 a short term access token.

If you want to make federated access tokens a formal approach you need to p=
rofile it since there is no spec for federated access tokens.

IOW, handle federated access tokens the same way 6749 does which is to say =
nothing.

If you do this you can really simplify registration because now it just nor=
mal oauth protected resource without any special handling.



If you think it would be helpful, I can add language to the lifecycle discu=
ssion to clarify that the Initial Registration Token can be gotten through =
any number of means, not just the manual-portal approach that's talked abou=
t now. Or if you want to write up this specific use case we can add it as a=
nother concrete example.

[PH] I think there is potential to cut a lot of text out of the spec if we =
strictly define the registration endpoint as a normal OAuth2 protected endp=
oint.

[JR] I don't understand what you're saying here -- it already *is* an OAuth=
2 protected endpoint, like I've pointed out below. All OAuth2 protected end=
points don't care how you get the token, neither does this one. All OAuth2 =
protected endpoints don't care (from OAuth2's perspective) how the token is=
 verified or processed, and neither does this one (from the draft's perspec=
tive). I explicitly want to keep that kind of token and assertion processin=
g *out* of this draft because it's more useful to build generally applicabl=
e mechanisms. If we keep the registration endpoint as an OAuth2 protected e=
ndpoint -- like it already is -- then we can inherit whatever mechanisms yo=
u want, and that is a very powerful setup.

I will close by pointing out that I have *never* proposed that we dictate t=
hat the Registration Endpoint have to accept and process federated tokens, =
and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and the Registration Access Token being plain=
 old opaque-to-the-client OAuth 2 tokens.

[PH] Agreed.  However, the use case of a 3rd party signer for client applic=
ations is critical to both commercial organizations and open source orgs th=
at publish software that are deployed by many separate entities.  The clien=
t developer needs to be able to contact the publisher in many cases to obta=
in a signed assertion.

I believe this is a core use case.

I believe as I've proposed it using the normal 4.5 exchange federated asser=
tion for local token method, the draft doesn't have to get into the details=
 of the assertion.  Though that said, I would suggest the draft make some s=
uggestions on the contents of such assertions.

[JR] You can already do what you want to without mentioning assertions. The=
 current draft doesn't mention assertions at all, either. All talk of use o=
f assertions is outside the scope of registration. You're proposing adding =
it in, and I'm strongly against that.

I think it's possible that you're still conflating the work I'm doing with =
the BB+ *extension* to dynamic registration with the dynamic registration d=
ocument itself. I have never suggested that we pull all the extended BB+ st=
uff down into Dyn Reg, and in fact I think quite the opposite as I don't be=
lieve it's as generally applicable without the larger BB+ stack (which incl=
udes discovery as well as reliance on policy and other frameworks).

[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have v=
ery similar requirements.  As I said above, the use case is a key use case.

However I agree, the way you solve it in BB+ is not the way to solve it wit=
hin the draft spec.  I think the BB+ does well inform our discussions thoug=
h.

[JR] Considering that BB+ manages to do all of this with a cleanly defined =
extension without any changes in the existing draft text, I think that's as=
 strong an argument as anything to keep it defined how it is, and that what=
's there is a sufficient base to build on.

 -- Justin

On 05/30/2013 03:54 PM, Phil Hunt wrote:
Justin,

So far, every time an OAuth server has accepted a 3rd party token it has be=
en a bearer assertion. The common pattern is to exchange that assertion for=
 a an access token issued by the local server for the local resource endpoi=
nt.

That's the pattern I am trying to follow.

Going this way means we do not have to define the initial registration toke=
n.

If however, you really want to use the initial registration token AS an acc=
ess token, you are taking us into the question of using federated access to=
kens.  I prefer not to do that here.

Phil

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





On 2013-05-30, at 12:51 PM, Justin Richer wrote:

I don't understand which access token is being talked about here -- is this=
 the Initial Registration Token? Because you can already do everything belo=
w. How you get the Initial Registration token is out of scope precisely so =
that the AS can decide what that means. We can add language in the lifecycl=
e discussions to bring up the fact that you can get this token from an OAut=
h flow, if you think that'll help clear things up.

However, the client doesn't register using the client credential flow at al=
l -- it registers using a POST to the registration endpoint, and that POST =
might have an OAuth token attached to it. How the client got that OAuth tok=
=3D

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








I don't understand any of the comments below -- it already *is* an O=
Auth2 protected resource without any special handling. Your access tokens c=
an be short-lived, long-lived, federated,
 structured, random blobs ... totally doesn't matter. They are access token=
s being used to access a normal protected resource. Full stop.



Anything else is out of scope. The lifecycle discussions at the beginning a=
re merely examples of some ways you *could* use it and are non-normative an=
d non-exhaustive.



You seem to be asking for something that's already in the draft.



 -- Justin






From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-=
11.txt














Phil




On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:












Comments inline, marked by [JR].








From: Phil Hunt [phil.hunt@oracle.com]

Sent: Thursday, May 30, 2013 5:25 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-=
11.txt






See below.







On 2013-05-30, at 2:09 PM, Justin Richer wrote:






OK, I think see part of the hang up. I have not se=
en the scenario that you describe, where you trade a 3rd party token for a =
"local" token. I have seen where access tokens are federated dire=
ctly at the PR. (Introspection lets you do some
 good things with that pattern.) But that's neither here nor there, as you =
can already do what you're asking for and I think I can clear things up:


In your case, the "3rd party bearer assertion" is simply *not* th=
e Initial Registration Token. It's an assertion that can be used to *get* a=
n Initial Registration Token. The token that you get from the Token Endpoin=
t, in your case, would be "local" from your
 own AS. Your registration endpoint would look at this token on the way in,=
 know how to validate it, do whatever else it wants to with it, and process=
 the registration. Then it would issue a Registration Access Token that to =
the registering client to use at
 the RESTful endpoint. Incidentally, that token would also be "local&q=
uot;, just like before.








How you (the client/developer) get the actual Init=
ial Registration Token is completely and forever out of scope for the Dynam=
ic Registration spec.











[PH]  Yes, the issuance of the third party bearer assertion token toke=
n would be out of scope of this spec.







If however the group decides to except federated direct access tokens =
as registration *access* tokens, then I think we have to define federation =
for access tokens first.   For me, I think this is something that shou=
ld be discussed in a different charter.




[JR] It's an access token, plain and simple. The dra=
ft doesn't care -- and shouldn't care -- if it's federated or not. I agree<=
font color=3D"3366FF">, and have been arguing all along, that if you=
 have a use case for federated access
 tokens, you need to define the mechanisms for such tokens, and that regist=
ration is *not* the place for that definition. It's =
orthogonal but they can be used together. Let's define them separately
but in a compatible way. 















[ph] thats not the impression i get from the draft. As i mentioned earlier =
using access token for registration is clearer. 












<=
/font>










This all still fits with the current definitions as they are. You don't hav=
e to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any =
content or semantics tied to the
 processing of the Initial Registration Token or calling it an Assertion or=
 anything -- it's up to the AS to process it however it would normally proc=
ess an OAuth Access token. So if your AS needs a local token, then you need=
 to use a local token. If you don't
 want to use structured foreign tokens as your Initial Registration Tokens,=
 don't. But that shouldn't preclude others of us from doing so.










[PH] The difference is where the client is expected to present the federate=
d (aka 3rd party) assertion.  I would rather follow the standard 6749 =
4.5 method in all cases for consistency.  







You can choose to short circuit, but I think the draft should follow a=
 consistent methodology.




[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as i=
t's talking about access to the token endpoint and not to protected resourc=
es. Additionally, people do use assertions encoded inside of OAuth tokens d=
irectly at protected resources all
 the time (since OAuth2 tokens are opaque to clients but must be understood=
 by protected resources), but that's *still* completely irrelevant to this =
discussion because it doesn't matter in terms of the interoperability of th=
e protocol. If you want to use assertions
 or auth codes or client credentials or magic to get your Initial Registrat=
ion Token, the dynamic registration protocol doesn't care how you did it. J=
ust like any other OAuth2 protected resource doesn't care how you got the t=
oken. This abstraction was one of
 the key insights in how OAuth2 is structured as a framework and protocol. =
The important thing here is that if the client gets an Initial Registration=
 Token it knows where to send it and how to use it. What I hear you saying =
is that you don't want to use a
 federated token as an Initial Registration Token. That's fine! Don't do it=
 -- and you have that option precisely because of how we've already written=
 it! If your clients get handed a token that *isn't* an Initial Registratio=
n Token and you want them to go
 through another step to *get* an Initial Registration Token, so be it! But=
 it doesn't make sense to encode that behavior as required into the registr=
ation protocol, because (as you point out) not everything is going to be an=
 assertion in the first place. Again
 I say that you can do everything that you want to do with existing mechani=
sms or self-contained extensions.



















[ph] i am referring to the mechanism currently defined that accepts externa=
l assertions in exchange for access tokens within the server. 






When you do it this way all clients are now accessing the reg endpoint=
 with a short term access token. 







If you want to make federated access tokens a formal approach you need=
 to profile it since there is no spec for federated access tokens. 






IOW, handle federated access tokens the same way 6749 does which is to=
 say nothing. 







If you do this you can really simplify registration because now it jus=
t normal oauth protected resource without any special handling. 


























If you think it would be helpful, I can add language to the lifecycle discu=
ssion to clarify that the Initial Registration Token can be gotten through =
any number of means, not just the manual-portal approach that's talked abou=
t now. Or if you want to write up
 this specific use case we can add it as another concrete example. 










[PH] I think there is potential to cut a lot of text out of the spec if we =
strictly define the registration endpoint as a normal OAuth2 protected endp=
oint.



[JR] I don't understand what you're saying here -- i=
t already *is* an OAuth2 protected endpoint, like I've pointed out below. A=
ll OAuth2 protected endpoints don't care how you get the token, neither doe=
s this one. All OAuth2 protected endpoints
 don't care (from OAuth2's perspective) how the token is verified or proces=
sed, and neither does this one (from the draft's perspective). I explicitly=
 want to keep that kind of token and assertion processing *out* of this dra=
ft because it's more useful to build
 generally applicable mechanisms. If we keep the registration endpoint as a=
n OAuth2 protected endpoint -- like it already is -- then we can inherit wh=
atever mechanisms you want, and that is a very powerful setup.






I will close by pointing out that I have *never* proposed that we dictate t=
hat the Registration Endpoint have to accept and process federated tokens, =
and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and
 the Registration Access Token being plain old opaque-to-the-client OAuth 2=
 tokens.











[PH] Agreed.  However, the use case of a 3rd party signer for client a=
pplications is critical to both commercial organizations and open source or=
gs that publish software that are deployed by many separate entities.  =
;The client developer needs to be able to
 contact the publisher in many cases to obtain a signed assertion.  






I believe this is a core use case.  







I believe as I've proposed it using the normal 4.5 exchange federated =
assertion for local token method, the draft doesn't have to get into the de=
tails of the assertion.  Though that said, I would suggest the draft m=
ake some suggestions on the contents
 of such assertions.



[JR] You can already do what you want to without men=
tioning assertions. The current draft doesn't mention assertions at all, ei=
ther. All talk of use of assertions is outside the scope of registration. Y=
ou're proposing adding it in, and
 I'm strongly against that. 






I think it's possible that you're still conflating the work I'm doing with =
the BB+ *extension* to dynamic registration with the dynamic registrati=
on document itself. I have never suggested that we pull all the extended BB=
+ stuff down into Dyn Reg, and in fact
 I think quite the opposite as I don't believe it's as generally applicable=
 without the larger BB+ stack (which includes discovery as well as reli=
ance on policy and other frameworks).











[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have v=
ery similar requirements.  As I said above, the use case is a key use =
case. 







However I agree, the way you solve it in BB+ is not the way to sol=
ve it within the draft spec.  I think the BB+ does well inform our=
 discussions though.



[JR] Considering that BB+ manages to do all of t=
his with a cleanly defined extension without any changes in the existing dr=
aft text, I think that's as strong an argument as anything to keep it defin=
ed how it is, and that what's there is
 a sufficient base to build on.






 -- Justin




On 05/30/2013 03:54 PM, Phil Hunt wrote:




Justin,






So far, every time an OAuth server has accepted a 3rd party token it h=
as been a bearer assertion. The common pattern is to exchange that assertio=
n for a an access token issued by the local server for the local resource e=
ndpoint.







That's the pattern I am trying to follow.







Going this way means we do not have to define the initial registration=
 token.







If however, you really want to use the initial registration token AS a=
n access token, you are taking us into the question of using federated acce=
ss tokens.  I prefer not to do that here.


















On 2013-05-30, at 12:51 PM, Justin Richer wrote:






I don't understand which access token is being tal=
ked about here -- is this the Initial Registration Token? Because you can a=
lready do everything below. How you get the Initial Registration token is o=
ut of scope precisely so that the
 AS can decide what that means. We can add language in the lifecycle discus=
sions to bring up the fact that you can get this token from an OAuth flow, =
if you think that'll help clear things up.



However, the client doesn't register using the client credential flow at al=
l -- it registers using a POST to the registration endpoint, and that POST =
might have an OAuth token attached to it. How the client got that OAuth tok=
=3D








































--_000_B33BFB58CCC8BE4998958016839DE27E08F977D8IMCMBX01MITREOR_--

From torsten@lodderstedt.net  Fri May 31 02:07:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2421F91CB for ; Fri, 31 May 2013 02:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.914
X-Spam-Level: 
X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSK6itQ6MoYG for ; Fri, 31 May 2013 02:07:48 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBBC21F928C for ; Fri, 31 May 2013 02:07:46 -0700 (PDT)
Received: from [82.135.76.93] (helo=[192.168.1.6]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1UiLJJ-0001RO-5F for oauth@ietf.org; Fri, 31 May 2013 11:07:45 +0200
User-Agent: K-9 Mail for Android
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----29B1BED4HM3NCN0EUQSQ4DVWVBU5JB"
From: Torsten Lodderstedt 
Date: Fri, 31 May 2013 11:00:06 +0200
To: oauth@ietf.org
Message-ID: <6b327248-e427-452f-8fee-15a3677f48c3@email.android.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Subject: [OAUTH-WG] Fwd: Re: review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 09:07:52 -0000

------29B1BED4HM3NCN0EUQSQ4DVWVBU5JB
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

resending to the list


-------- Original-Nachricht --------
Von: Torsten Lodderstedt 
Gesendet: Thu May 30 17:18:48 MESZ 2013
An: Justin Richer 
Betreff: Re: review comments on draft-ietf-oauth-dyn-reg-11.txt

Hi Justin,

see below :-)

Justin Richer  schrieb:

>Torsten, thanks -- responses inline.
>
>On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
>> Hi Justin,
>>
>> comments inline.
>>
>>>>
>>>> section 1.4
>>>>
>>>> How is the client supposed to identify/distinguish authorization 
>>>> servers? Based on the Client Registration Endpoint URI? 
>>>> Authorization server identification is necessary in order to map 
>>>> client_ids to authorization servers for clients, which are
>connected 
>>>> to multiple authorization servers.
>>> That's a great question -- but I think it's entirely dependent on
>how 
>>> discovery and configuration is set up for a client, which is 
>>> ultimately orthogonal to registration. The way that I've implemented
>
>>> it in our client is based on the OpenID Connect discovery process, 
>>> which bases everything in the server's configuration off of an 
>>> "issuer" URL. It would be easy enough to point out here that 
>>> discovery and differentiation of different servers is out of scope.
>>
>> At least this should be pointed out. I would rather prefer a 
>> definition how to relate client_id and authz server.
>>
>> I don't think your solution can be generalized for generic OAuth
>since 
>> the issuer is only known to OpenID Connect clients. In my opinion, a 
>> simple, generic concept could be based on the authorization server's 
>> client registration URL. A more sophisticated approach would be to 
>> introduce authorization server meta data discovery (as a subset of 
>>
>http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata),
>
>> which might contain an OAuth authz server id.
>
>I'm not comfortable with specifying a discovery or server 
>differentiation method, but we can at least point out that the means by
>
>which the client differentiates servers is out of scope.

OK, wfm.

>>>> section 1.4.1 f
>>>>
>>>> Why does the client secret expire while the access token ist still 
>>>> valid? Secret and token are stored at the same
>>>> locations so an attacker may obtain both at once.
>>> Secrets are used at the token endpoint, so the attack surface is 
>>> slightly different. Since you can only use the registration access 
>>> token at the registration endpoint, you can use it to rotate your 
>>> other credentials.
>>
>> I understand the mechanism. I don't see the benefit given the
>_slight_ 
>> difference in attack surface. In my opinion, the only difference
>might 
>> be on the server side, between HTTPS termination and actual endpoint 
>> business logic. So it might limit the impact if an attacker, for 
>> example, obtains client secrets from server log files. Is this threat
>
>> worth to use different credentials with different lifecycles?
>
>That's getting into a different question, the question of the utility
>of 
>the registration access token. We need that because not all clients
>have 
>a client_secret (some just don't have any authn, some will use signing 
>or assertions), among other reasons talked about in section 1.3. The 
>fact that their lifecycles are independent simply stems from the fact 
>that they're separate credentials, and that it's more likely desirable 
>to have the client_secret expire in the real world. Also, note that you
>
>don't have to expire either of them. Or you can expire both of them at 
>the same time but have some way to keep an expired credential around
>for 
>one-last-refresh-call or something, you can do that.

I understand. After thinking about it again I think it makes sense to have different credentials in order to keep client mgnt and the OAuth flow independent.

>>>> "token_endpoint_auth_method"
>>>> What is the use case for dynamic registration of public clients? In
>
>>>> my opinion, public clients exist because OAuth 2.0 core does not 
>>>> provided a mechanism to provision secrets to the different
>instances 
>>>> of an installed/native app. Dynamic registration closes this gap,
>so 
>>>> any installed app may retrieve a distinct secret.
>>>
>>> This gap-closing is true for some classes of client that used to
>have 
>>> to be public, like many native apps. But there are still clients
>that 
>>> have no use for a client secret, like in-browser clients that use
>the 
>>> implicit flow. Now if these clients are also talking to multiple
>auth 
>>> servers, they'll each need a client_id at the auth server (because 
>>> there's no practical way to publish a "public" client ID to *all* 
>>> auth servers). A discussion in the security considerations about the
>
>>> limitations and usefulness of this use case is probably worthwhile, 
>>> so I'll make a note to do that.
>>
>> yes, clients using the implicit grant need a way to register. But
>they 
>> don't use the token endpoint. As this is about token endpoint 
>> authentication, I still don't see the need to have a "none" method
>there.
>
>The "none" method is needed because without it, a server will grant
>(and 
>expect) a client_secret from a client that has no business having one 
>(and no need for one).

So you are saying this parameter is used to distinguish public and confidential clients?

>
>>
>>>
>>>>
>>>> "client_secret_post vs client_secret_basic"
>>>> BASIC and POST are essentially the same just different ways to send
>
>>>> the client secret. If an authorization server supports both, both 
>>>> should work for any client. So are both methods treated
>differently?
>>> I agree, and this was one of my original arguments for making this 
>>> field plural (or plural-able), but there hasn't been WG support for 
>>> that so far.
>>
>> I'm not arguing to make it plural. I think the authentication method 
>> is just "client_secret".
>
>That was also an option that was brought up, but in the OIDC WG the 
>counter-argument was (as I recall) that the two are syntactically 
>separate and there's a desire to restrict to a single type, such as 
>disabling client_secret_post. Basically, to make it unambiguous.

Ok. 

Best regards,
Torsten.

>
>>
>>>
>>>>
>>>> "jwks_uri"
>>>> What is this data used for? the OAuth JWT Bearer Token Profiles?
>>>
>>> That's one, but it's really for any higher-level protocol that uses 
>>> signing and encryption. There are several out there that are using 
>>> JOSE on top of OAuth to do things, so we felt it was worthwhile to 
>>> have one standard place to have the client say "here's my public
>key".
>>
>> ok, understood.
>>
>> best regards,
>> Torsten.
>>>
>>>  -- Justin
>>>
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>> Am 24.05.2013 23:10, schrieb Richer, Justin P.:
>>>>> New Dynamic Registration draft is published, incorporating much of
>
>>>>> the discussion from the group this week.
>>>>>
>>>>> Some normative changes that should have minimal impact:
>>>>>   - "expires_at" is now "client_secret_expires_at"
>>>>>   - "issued_at" is now "client_id_issued_at"
>>>>>   - creation of an IANA registry for token_endpoint_auth_method
>>>>>   - removal of two underdefined values from 
>>>>> token_endpoint_auth_method (client_secret_jwt and
>private_key_jwt), 
>>>>> these are now defined in an extension (OpenID Connect
>Registration)
>>>>>
>>>>> And several editorial changes:
>>>>>
>>>>>   - new "client lifecycle" section that describes how different 
>>>>> kinds of clients can use the dynamic registration protocol, how a 
>>>>> client's credentials get refreshed, and the relationship between 
>>>>> the Client Identifier and the Client software
>>>>>   - new "registration tokens and credentials" section describing 
>>>>> the different kinds of tokens and credentials used in the 
>>>>> registration process, what they're for, and why they're all
>separate
>>>>>   - clarified the definitions of several fields like policy_uri
>and 
>>>>> tos_uri
>>>>>
>>>>> Thanks for all the great feedback, and please keep the
>constructive 
>>>>> commentary coming!
>>>>>   -- Justin
>>>>>
>>>>> On May 24, 2013, at 4:36 PM, 
>>>>>   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 2.0 Dynamic Client Registration
>Protocol
>>>>>>     Author(s)       : Justin Richer
>>>>>>                           John Bradley
>>>>>>                           Michael B. Jones
>>>>>>                           Maciej Machulak
>>>>>>     Filename        : draft-ietf-oauth-dyn-reg-11.txt
>>>>>>     Pages           : 34
>>>>>>     Date            : 2013-05-24
>>>>>>
>>>>>> Abstract:
>>>>>>    This specification defines an endpoint and protocol for
>dynamic
>>>>>>    registration of OAuth 2.0 Clients at an Authorization Server
>and
>>>>>>    methods for the dynamically registered client to manage its
>>>>>>    registration.
>>>>>>
>>>>>>
>>>>>> 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-11
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11
>>>>>>
>>>>>>
>>>>>> 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
>>>>
>>>
>>

------29B1BED4HM3NCN0EUQSQ4DVWVBU5JB
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

resending to the list




Von: Torsten Lodderstedt <torsten@lodderstedt.net>

Gesendet: Thu May 30 17:18:48 MESZ 2013

An: Justin Richer <jricher@mitre.org>

Betreff: Re: review comments on draft-ietf-oauth-dyn-reg-11.txt






Hi Justin,

see below :-)

Justin Richer <jricher@mitre.org> schrieb:

Torsten, thanks -- responses inline.

On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
Hi Justin,

comments inline.


section 1.4

How is the client supposed to identify/distinguish authorization 
servers? Based on the Client Registration Endpoint URI? Authorization server identification is necessary in order to map 
client_ids to authorization servers for clients, which are
connected 
to multiple authorization servers.
That's a great question -- but I think it's entirely dependent on
how 
discovery and configuration is set up for a clie
 nt,
which is 
ultimately orthogonal to registration. The way that I've implemented

it in our client is based on the OpenID Connect discovery process, 
which bases everything in the server's configuration off of an 
"issuer" URL. It would be easy enough to point out here that 
discovery and differentiation of different servers is out of scope.

At least this should be pointed out. I would rather prefer a 
definition how to relate client_id and authz server.

I don't think your solution can be generalized for generic OAuth
since 
the issuer is only known to OpenID Connect clients. In my opinion, a 
simple, generic concept could be based on the authorization server's 
client registration URL. A more sophisticated approach would be to 
introduce authorization server me
 ta data
discovery (as a subset of 

http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata),

which might contain an OAuth authz server id.

I'm not comfortable with specifying a discovery or server 
differentiation method, but we can at least point out that the means by

which the client differentiates servers is out of scope.

OK, wfm.

section 1.4.1 f

Why does the client secret expire while the access token ist still 
valid? Secret and token are stored at the same
locations so an attacker may obtain both at once.
Secrets are used at the token endpoint, so the attack surface is 
slightly different. Since you can only use the registration access 
token at the registration endpoint, you can use it to rotate your 
other credentials.

I understand the mechanism. I don't see the benefit given the
_slight_ 
difference in attack surface. In my opinion, the only difference
might 
be on the server side, between HTTPS termination and actual endpoint 
business logic. So it might limit the impact if an attacker, for 
example, obtains client secrets from server log files. Is this threat

worth to use different credentials with different lifecycles?

That's getting into a different question, the question of the utility
of 
the registration access token. We need that because not all clients
have 
a client_secret (some just don't have any authn, some will use signing 
or assertions), among other reasons talked about in section 1.3. The 
fact that their lifecycles are independent simply stems from the fact 
that they're separate credentials, and that it's more likely desirable 
to have the client_secret expire in the real world. Also, note that you

don't have to expire either of them. Or you can expire both of them at 
the same time but hav
 e some
way to keep an expired credential around
for 
one-last-refresh-call or something, you can do that.

I understand. After thinking about it again I think it makes sense to have different credentials in order to keep client mgnt and the OAuth flow independent.

"token_endpoint_auth_method"
What is the use case for dynamic registration of public clients? In

my opinion, public clients exist because OAuth 2.0 core does not 
provided a mechanism to provision secr
 ets to
the different
instances 
of an installed/native app. Dynamic registration closes this gap,
so 
any installed app may retrieve a distinct secret.

This gap-closing is t
 rue for
some classes of client that used to
have 
to be public, like many native apps. But there are still clients
that 
have no use for a client secret, like in-browser clients that use
the 
implicit flow. Now if these clients are also talking to multiple
auth 
servers, they'll each need a client_id at the auth server (because 
there's no practical way to publish a "public" client ID to *all* 
auth servers). A discussion in the security considerations about the

limitations and usefulness of this use case is probably worthwhile, 
so I'll make a note to do that.

yes, clients using the implicit grant need a way to register. But
they 
don't use the token endpoint. As this is about token endpoint 
authenticat
 ion, I
still don't see the need to have a "none" method
there.

The "none" method is needed because without it, a server will grant
(and 
expect) a client_secret from a client that has no business having one 
(and no need for one).

So you are saying this parameter is used to distinguish public and confidential clients?





"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways
  to
send

the client secret. If an authorization server supports both, both 
should work for any client. So are both methods treated
differently?
I agree, and this was one of my original arguments for making this 
field plural (or plural-able), but there hasn't been WG support for 
that so far.

I'm not arguing to make it plural. I think the authentication method 
is just "client_secret".

That was also an option that was brought up, but in the OIDC WG the 
counter-argument was (as I recall) that the two are syntactically 
separate and there's a desire to restrict to a single type, such as 
disabling client_secret_post.
Basically, to make it unambiguous.

Ok. 

Best regards,
Torsten.





"jwks_uri"
What is this data used for? the OAuth JWT Bearer Token Profiles?

That's one, but it's really for any higher-level protocol that uses 
signing and encryption. There are several out there that are using 
JOSE on top of OAuth to do things, so we felt it was worthwhile to 
have one standard place to have the client say "here's my public
key".

ok, understood.

best regards,
Torsten.

-- Justin


best regards,
Torsten.

Am 24.05.2013 23:10, schrieb Richer, Justin P.:
New Dynamic Registration draft is published, incorporating much of

the discussion from the group this week.

Some normative changes that should have minimal impact:
- "expires_at" is now "client_secret_expires_at"
- "issued_at" is now "client_id_issued_at"<
 br />-
creation of an IANA registry for token_endpoint_auth_method
- removal of two underdefined values from 
token_endpoint_auth_method (client_secret_jwt and
private_key_jwt), 
these are now defined in an extension (OpenID Connect
Registration)

And several editorial changes:

- new "client lifecycle" section that describes how different 
kinds of clients can use the dynamic registration protocol, how a 
client's credentials get refreshed, and the relationship between 
the Client Identifier and the Client software
- new "registration tokens and credentials" section describing 
the different kinds of tokens and credentials used in the 
registration process, what they're for, and why they're all
separate
- clarified the definitions of several fields like policy_uri
and 
tos_uri

Thanks for all the great feedback, and please keep the
constructive 
commentary coming!
-- Justin

On May 24, 2013, at 4:36 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 2.0 Dynamic Client Registration
Protocol
Author(s)       : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename        : draft-ietf-oauth-dyn-reg-11.txt
Pages           : 34
Date            : 2013-05-24

Abstract:
This specification defines an endpoint and protocol for
dynamic
registration of OAuth 2.0 Clients at an Authorization Server
and
methods for the dynamically registered client to manage its
registration.


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-11

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


Internet-Drafts are also available by anonymous FTP at:
ft
 p://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




------29B1BED4HM3NCN0EUQSQ4DVWVBU5JB--


From phil.hunt@oracle.com  Fri May 31 07:16:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA92E21F8FB3 for ; Fri, 31 May 2013 07:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.235
X-Spam-Level: 
X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C6MXgygYjsc for ; Fri, 31 May 2013 07:15:57 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BA5F521F89C3 for ; Fri, 31 May 2013 07:15:57 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VEFsvS014899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 14:15:55 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VEFtcN015816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 14:15:56 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VEFtY1015795; Fri, 31 May 2013 14:15:55 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 07:15:54 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-1EB08742-8B74-46BD-AEBD-1435A658309C
Content-Transfer-Encoding: 7bit
Message-Id: <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 10:15:54 -0400
To: "Richer, Justin P." 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 14:16:04 -0000

--Apple-Mail-1EB08742-8B74-46BD-AEBD-1435A658309C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The preference is to have the access token for registration issued by the no=
rmal token server rather then by the registration endpoint.=20

In the current draft it is obtained through a unique process and must outliv=
e the client.=20

Phil

On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:

> I don't understand any of the comments below -- it already *is* an OAuth2 p=
rotected resource without any special handling. Your access tokens can be sh=
ort-lived, long-lived, federated, structured, random blobs ... totally doesn=
't matter. They are access tokens being used to access a normal protected re=
source. Full stop.
>=20
> Anything else is out of scope. The lifecycle discussions at the beginning a=
re merely examples of some ways you *could* use it and are non-normative and=
 non-exhaustive.
>=20
> You seem to be asking for something that's already in the draft.
>=20
>  -- Justin
>=20
> From: Phil Hunt [phil.hunt@oracle.com]
> Sent: Thursday, May 30, 2013 7:31 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt=

>=20
>=20
>=20
> Phil
>=20
> On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:
>=20
>> Comments inline, marked by [JR].
>>=20
>> From: Phil Hunt [phil.hunt@oracle.com]
>> Sent: Thursday, May 30, 2013 5:25 PM
>> To: Richer, Justin P.
>> Cc: John Bradley; oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.tx=
t
>>=20
>> See below.
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>=20
>>> OK, I think see part of the hang up. I have not seen the scenario that y=
ou describe, where you trade a 3rd party token for a "local" token. I have s=
een where access tokens are federated directly at the PR. (Introspection let=
s you do some  good things with that pattern.) But that's neither here nor t=
here, as you can already do what you're asking for and I think I can clear t=
hings up:
>>>=20
>>> In your case, the "3rd party bearer assertion" is simply *not* the Initi=
al Registration Token. It's an assertion that can be used to *get* an Initia=
l Registration Token. The token that you get from the Token Endpoint, in you=
r case, would be "local" from your own AS. Your registration endpoint would l=
ook at this token on the way in, know how to validate it, do whatever else i=
t wants to with it, and process the registration. Then it would issue a Regi=
stration Access Token that to the registering client to use at the RESTful e=
ndpoint. Incidentally, that token would also be "local", just like before.
>>=20
>>> How you (the client/developer) get the actual Initial Registration Token=
 is completely and forever out of scope for the Dynamic Registration spec.
>>=20
>> [PH]  Yes, the issuance of the third party bearer assertion token token w=
ould be out of scope of this spec.
>>=20
>> If however the group decides to except federated direct access tokens as r=
egistration *access* tokens, then I think we have to define federation for a=
ccess tokens first.   For me, I think this is something that should be discu=
ssed in a different charter.
>>=20
>> [JR] It's an access token, plain and simple. The draft doesn't care -- an=
d shouldn't care -- if it's federated or not. I agree, and have been arguing=
 all along, that if you have a use case for federated access tokens, you nee=
d to define the mechanisms for such tokens, and that registration is *not* t=
he place for that definition. It's orthogonal but they can be used together.=
 Let's define them separately but in a compatible way.
> [ph] thats not the impression i get from the draft. As i mentioned earlier=
 using access token for registration is clearer.=20
>>>=20
>>>=20
>>> This all still fits with the current definitions as they are. You don't h=
ave to use federated tokens if you don't want to. I can still use them if I w=
ant to. Everybody's happy! And this is all because we are not defining any c=
ontent or semantics tied to the processing of the Initial Registration Token=
 or calling it an Assertion or anything -- it's up to the AS to process it h=
owever it would normally process an OAuth Access token. So if your AS needs a=
 local token, then you need to use a local token. If you don't want to use s=
tructured foreign tokens as your Initial Registration Tokens, don't. But tha=
t shouldn't preclude others of us from doing so.
>>=20
>> [PH] The difference is where the client is expected to present the federa=
ted (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 m=
ethod in all cases for consistency. =20
>>=20
>> You can choose to short circuit, but I think the draft should follow a co=
nsistent methodology.
>>=20
>> [JR] 6749 section 4.5 (extension grants) is irrelevant to registration as=
 it's talking about access to the token endpoint and not to protected resour=
ces. Additionally, people do use assertions encoded inside of OAuth tokens d=
irectly at protected resources all the time (since OAuth2 tokens are opaque t=
o clients but must be understood by protected resources), but that's *still*=
 completely irrelevant to this discussion because it doesn't matter in terms=
 of the interoperability of the protocol. If you want to use assertions or a=
uth codes or client credentials or magic to get your Initial Registration To=
ken, the dynamic registration protocol doesn't care how you did it. Just lik=
e any other OAuth2 protected resource doesn't care how you got the token. Th=
is abstraction was one of the key insights in how OAuth2 is structured as a f=
ramework and protocol. The important thing here is that if the client gets a=
n Initial Registration Token it knows where to send it and how to use it. Wh=
at I hear you saying is that you don't want to use a federated token as an I=
nitial Registration Token. That's fine! Don't do it -- and you have that opt=
ion precisely because of how we've already written it! If your clients get h=
anded a token that *isn't* an Initial Registration Token and you want them t=
o go through another step to *get* an Initial Registration Token, so be it! B=
ut it doesn't make sense to encode that behavior as required into the regist=
ration protocol, because (as you point out) not everything is going to be an=
 assertion in the first place. Again I say that you can do everything that y=
ou want to do with existing mechanisms or self-contained extensions.
>=20
> [ph] i am referring to the mechanism currently defined that accepts extern=
al assertions in exchange for access tokens within the server.=20
>=20
> When you do it this way all clients are now accessing the reg endpoint wit=
h a short term access token.=20
>=20
> If you want to make federated access tokens a formal approach you need to p=
rofile it since there is no spec for federated access tokens.=20
>=20
> IOW, handle federated access tokens the same way 6749 does which is to say=
 nothing.=20
>=20
> If you do this you can really simplify registration because now it just no=
rmal oauth protected resource without any special handling.=20
>=20
>>=20
>>>=20
>>> If you think it would be helpful, I can add language to the lifecycle di=
scussion to clarify that the Initial Registration Token can be gotten throug=
h any number of means, not just the manual-portal approach that's talked abo=
ut now. Or if you want to write up this specific use case we can add it as a=
nother concrete example.
>>=20
>> [PH] I think there is potential to cut a lot of text out of the spec if w=
e strictly define the registration endpoint as a normal OAuth2 protected end=
point.
>>=20
>> [JR] I don't understand what you're saying here -- it already *is* an OAu=
th2 protected endpoint, like I've pointed out below. All OAuth2 protected en=
dpoints don't care how you get the token, neither does this one. All OAuth2 p=
rotected endpoints don't care (from OAuth2's perspective) how the token is v=
erified or processed, and neither does this one (from the draft's perspectiv=
e). I explicitly want to keep that kind of token and assertion processing *o=
ut* of this draft because it's more useful to build generally applicable mec=
hanisms. If we keep the registration endpoint as an OAuth2 protected endpoin=
t -- like it already is -- then we can inherit whatever mechanisms you want,=
 and that is a very powerful setup.
>>>=20
>>> I will close by pointing out that I have *never* proposed that we dictat=
e that the Registration Endpoint have to accept and process federated tokens=
, and it would be ludicrous to do so. I have been and still am committed to t=
he Initial Registration Token and the Registration Access Token being plain o=
ld opaque-to-the-client OAuth 2 tokens.
>>=20
>> [PH] Agreed.  However, the use case of a 3rd party signer for client appl=
ications is critical to both commercial organizations and open source orgs t=
hat publish software that are deployed by many separate entities.  The clien=
t developer needs to be able to contact the publisher in many cases to obtai=
n a signed assertion. =20
>>=20
>> I believe this is a core use case. =20
>>=20
>> I believe as I've proposed it using the normal 4.5 exchange federated ass=
ertion for local token method, the draft doesn't have to get into the detail=
s of the assertion.  Though that said, I would suggest the draft make some s=
uggestions on the contents of such assertions.
>>=20
>> [JR] You can already do what you want to without mentioning assertions. T=
he current draft doesn't mention assertions at all, either. All talk of use o=
f assertions is outside the scope of registration. You're proposing adding i=
t in, and I'm strongly against that.=20
>>>=20
>>> I think it's possible that you're still conflating the work I'm doing wi=
th the BB+ *extension* to dynamic registration with the dynamic registration=
 document itself. I have never suggested that we pull all the extended BB+ s=
tuff down into Dyn Reg, and in fact I think quite the opposite as I don't be=
lieve it's as generally applicable without the larger BB+ stack (which inclu=
des discovery as well as reliance on policy and other frameworks).=20
>>=20
>> [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have=
 very similar requirements.  As I said above, the use case is a key use case=
.=20
>>=20
>> However I agree, the way you solve it in BB+ is not the way to solve it w=
ithin the draft spec.  I think the BB+ does well inform our discussions thou=
gh.
>>=20
>> [JR] Considering that BB+ manages to do all of this with a cleanly define=
d extension without any changes in the existing draft text, I think that's a=
s strong an argument as anything to keep it defined how it is, and that what=
's there is a sufficient base to build on.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/30/2013 03:54 PM, Phil Hunt wrote:
>>>> Justin,
>>>>=20
>>>> So far, every time an OAuth server has accepted a 3rd party token it ha=
s been a bearer assertion. The common pattern is to exchange that assertion f=
or a an access token issued by the local server for the local resource endpo=
int.
>>>>=20
>>>> That's the pattern I am trying to follow.
>>>>=20
>>>> Going this way means we do not have to define the initial registration t=
oken.
>>>>=20
>>>> If however, you really want to use the initial registration token AS an=
 access token, you are taking us into the question of using federated access=
 tokens.  I prefer not to do that here.
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>>>>=20
>>>>> I don't understand which access token is being talked about here -- is=
 this the Initial Registration Token? Because you can already do everything b=
elow. How you get the Initial Registration token is out of scope precisely s=
o that the AS can decide what that means. We can add language in the lifecyc=
le discussions to bring up the fact that you can get this token from an OAut=
h flow, if you think that'll help clear things up.
>>>>>=20
>>>>> However, the client doesn't register using the client credential flow a=
t all -- it registers using a POST to the registration endpoint, and that PO=
ST might have an OAuth token attached to it. How the client got that OAuth t=
ok=3D

--Apple-Mail-1EB08742-8B74-46BD-AEBD-1435A658309C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint. 

In the current draft it is obtained through a unique process and must outlive the client. 

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:








I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated,
 structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.



Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.



You seem to be asking for something that's already in the draft.



 -- Justin








From: Phil Hunt [phil.hunt@oracle.com]

Sent: Thursday, May 30, 2013 7:31 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt














Phil




On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:












Comments inline, marked by [JR].








From: Phil Hunt [phil.hunt@oracle.com]

Sent: Thursday, May 30, 2013 5:25 PM

To: Richer, Justin P.

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt






See below.







On 2013-05-30, at 2:09 PM, Justin Richer wrote:






OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some
 good things with that pattern.) But that's neither here nor there, as you can already do what you're asking for and I think I can clear things up:



In your case, the "3rd party bearer assertion" is simply *not* the Initial Registration Token. It's an assertion that can be used to *get* an Initial Registration Token. The token that you get from the Token Endpoint, in your case, would be "local" from your
 own AS. Your registration endpoint would look at this token on the way in, know how to validate it, do whatever else it wants to with it, and process the registration. Then it would issue a Registration Access Token that to the registering client to use at
 the RESTful endpoint. Incidentally, that token would also be "local", just like before.








How you (the client/developer) get the actual Initial Registration Token is completely and forever out of scope for the Dynamic Registration spec.











[PH]  Yes, the issuance of the third party bearer assertion token token would be out of scope of this spec.







If however the group decides to except federated direct access tokens as registration *access* tokens, then I think we have to define federation for access tokens first.   For me, I think this is something that should be discussed in a different charter.




[JR] It's an access token, plain and simple. The draft doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you have a use case for federated access
 tokens, you need to define the mechanisms for such tokens, and that registration is *not* the place for that definition. It's orthogonal but they can be used together. Let's define them separately
but in a compatible way. 















[ph] thats not the impression i get from the draft. As i mentioned earlier using access token for registration is clearer. 






















This all still fits with the current definitions as they are. You don't have to use federated tokens if you don't want to. I can still use them if I want to. Everybody's happy! And this is all because we are not defining any content or semantics tied to the
 processing of the Initial Registration Token or calling it an Assertion or anything -- it's up to the AS to process it however it would normally process an OAuth Access token. So if your AS needs a local token, then you need to use a local token. If you don't
 want to use structured foreign tokens as your Initial Registration Tokens, don't. But that shouldn't preclude others of us from doing so.










[PH] The difference is where the client is expected to present the federated (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 method in all cases for consistency.  







You can choose to short circuit, but I think the draft should follow a consistent methodology.




[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as it's talking about access to the token endpoint and not to protected resources. Additionally, people do use assertions encoded inside of OAuth tokens directly at protected resources all
 the time (since OAuth2 tokens are opaque to clients but must be understood by protected resources), but that's *still* completely irrelevant to this discussion because it doesn't matter in terms of the interoperability of the protocol. If you want to use assertions
 or auth codes or client credentials or magic to get your Initial Registration Token, the dynamic registration protocol doesn't care how you did it. Just like any other OAuth2 protected resource doesn't care how you got the token. This abstraction was one of
 the key insights in how OAuth2 is structured as a framework and protocol. The important thing here is that if the client gets an Initial Registration Token it knows where to send it and how to use it. What I hear you saying is that you don't want to use a
 federated token as an Initial Registration Token. That's fine! Don't do it -- and you have that option precisely because of how we've already written it! If your clients get handed a token that *isn't* an Initial Registration Token and you want them to go
 through another step to *get* an Initial Registration Token, so be it! But it doesn't make sense to encode that behavior as required into the registration protocol, because (as you point out) not everything is going to be an assertion in the first place. Again
 I say that you can do everything that you want to do with existing mechanisms or self-contained extensions.



















[ph] i am referring to the mechanism currently defined that accepts external assertions in exchange for access tokens within the server. 






When you do it this way all clients are now accessing the reg endpoint with a short term access token. 







If you want to make federated access tokens a formal approach you need to profile it since there is no spec for federated access tokens. 







IOW, handle federated access tokens the same way 6749 does which is to say nothing. 







If you do this you can really simplify registration because now it just normal oauth protected resource without any special handling. 


























If you think it would be helpful, I can add language to the lifecycle discussion to clarify that the Initial Registration Token can be gotten through any number of means, not just the manual-portal approach that's talked about now. Or if you want to write up
 this specific use case we can add it as another concrete example. 










[PH] I think there is potential to cut a lot of text out of the spec if we strictly define the registration endpoint as a normal OAuth2 protected endpoint.



[JR] I don't understand what you're saying here -- it already *is* an OAuth2 protected endpoint, like I've pointed out below. All OAuth2 protected endpoints don't care how you get the token, neither does this one. All OAuth2 protected endpoints
 don't care (from OAuth2's perspective) how the token is verified or processed, and neither does this one (from the draft's perspective). I explicitly want to keep that kind of token and assertion processing *out* of this draft because it's more useful to build
 generally applicable mechanisms. If we keep the registration endpoint as an OAuth2 protected endpoint -- like it already is -- then we can inherit whatever mechanisms you want, and that is a very powerful setup.






I will close by pointing out that I have *never* proposed that we dictate that the Registration Endpoint have to accept and process federated tokens, and it would be ludicrous to do so. I have been and still am committed to the Initial Registration Token and
 the Registration Access Token being plain old opaque-to-the-client OAuth 2 tokens.











[PH] Agreed.  However, the use case of a 3rd party signer for client applications is critical to both commercial organizations and open source orgs that publish software that are deployed by many separate entities.  The client developer needs to be able to
 contact the publisher in many cases to obtain a signed assertion.  







I believe this is a core use case.  







I believe as I've proposed it using the normal 4.5 exchange federated assertion for local token method, the draft doesn't have to get into the details of the assertion.  Though that said, I would suggest the draft make some suggestions on the contents
 of such assertions.



[JR] You can already do what you want to without mentioning assertions. The current draft doesn't mention assertions at all, either. All talk of use of assertions is outside the scope of registration. You're proposing adding it in, and
 I'm strongly against that. 






I think it's possible that you're still conflating the work I'm doing with the BB+ *extension* to dynamic registration with the dynamic registration document itself. I have never suggested that we pull all the extended BB+ stuff down into Dyn Reg, and in fact
 I think quite the opposite as I don't believe it's as generally applicable without the larger BB+ stack (which includes discovery as well as reliance on policy and other frameworks).











[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have very similar requirements.  As I said above, the use case is a key use case. 







However I agree, the way you solve it in BB+ is not the way to solve it within the draft spec.  I think the BB+ does well inform our discussions though.



[JR] Considering that BB+ manages to do all of this with a cleanly defined extension without any changes in the existing draft text, I think that's as strong an argument as anything to keep it defined how it is, and that what's there is
 a sufficient base to build on.






 -- Justin




On 05/30/2013 03:54 PM, Phil Hunt wrote:




Justin,






So far, every time an OAuth server has accepted a 3rd party token it has been a bearer assertion. The common pattern is to exchange that assertion for a an access token issued by the local server for the local resource endpoint.







That's the pattern I am trying to follow.







Going this way means we do not have to define the initial registration token.







If however, you really want to use the initial registration token AS an access token, you are taking us into the question of using federated access tokens.  I prefer not to do that here.


















On 2013-05-30, at 12:51 PM, Justin Richer wrote:






I don't understand which access token is being talked about here -- is this the Initial Registration Token? Because you can already do everything below. How you get the Initial Registration token is out of scope precisely so that the
 AS can decide what that means. We can add language in the lifecycle discussions to bring up the fact that you can get this token from an OAuth flow, if you think that'll help clear things up.



However, the client doesn't register using the client credential flow at all -- it registers using a POST to the registration endpoint, and that POST might have an OAuth token attached to it. How the client got that OAuth tok=









































--Apple-Mail-1EB08742-8B74-46BD-AEBD-1435A658309C--

From jricher@mitre.org  Fri May 31 07:55:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3D621F9927 for ; Fri, 31 May 2013 07:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.366
X-Spam-Level: 
X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaARlVyylBi1 for ; Fri, 31 May 2013 07:55:46 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B7DDD21F96EA for ; Fri, 31 May 2013 07:55:42 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 31F6A1F090B; Fri, 31 May 2013 10:55:42 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0C0EB1F08BF; Fri, 31 May 2013 10:55:42 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 10:55:41 -0400
Message-ID: <51A8B9C4.8020200@mitre.org>
Date: Fri, 31 May 2013 10:55:00 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>
In-Reply-To: <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>
Content-Type: multipart/alternative; boundary="------------010405050703090307080809"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 14:55:52 -0000

--------------010405050703090307080809
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through 
the normal token server no problem. (The lifecycle writeups don't call 
this out explicitly but I would be willing to do so.) Or you could get 
it elsewhere. Doesn't matter, just like it doesn't matter with any other 
OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from 
the token endpoint would require a lot more work and complexity on 
behalf of both of the client and server. Either you end up with public 
clients getting secrets they shouldn't need or with granting clients 
access to the client_credentials flow when they shouldn't actually have 
it. Plus it adds extra round trips which don't buy you anything.

  -- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:
> The preference is to have the access token for registration issued by 
> the normal token server rather then by the registration endpoint.
>
> In the current draft it is obtained through a unique process and must 
> outlive the client.
>
> Phil
>
> On 2013-05-30, at 19:47, "Richer, Justin P."  > wrote:
>
>> I don't understand any of the comments below -- it already *is* an 
>> OAuth2 protected resource without any special handling. Your access 
>> tokens can be short-lived, long-lived, federated, structured, random 
>> blobs ... totally doesn't matter. They are access tokens being used 
>> to access a normal protected resource. Full stop.
>>
>> Anything else is out of scope. The lifecycle discussions at the 
>> beginning are merely examples of some ways you *could* use it and are 
>> non-normative and non-exhaustive.
>>
>> You seem to be asking for something that's already in the draft.
>>
>>  -- Justin
>>
>> ------------------------------------------------------------------------
>> *From:* Phil Hunt [phil.hunt@oracle.com ]
>> *Sent:* Thursday, May 30, 2013 7:31 PM
>> *To:* Richer, Justin P.
>> *Cc:* John Bradley; oauth@ietf.org  WG
>> *Subject:* Re: [OAUTH-WG] review comments on 
>> draft-ietf-oauth-dyn-reg-11.txt
>>
>>
>>
>> Phil
>>
>> On 2013-05-30, at 16:11, "Richer, Justin P." > > wrote:
>>
>>> Comments inline, marked by [JR].
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Phil Hunt [phil.hunt@oracle.com ]
>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>> *To:* Richer, Justin P.
>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>> draft-ietf-oauth-dyn-reg-11.txt
>>>
>>> See below.
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>
>>>> OK, I think see part of the hang up. I have not seen the scenario 
>>>> that you describe, where you trade a 3rd party token for a "local" 
>>>> token. I have seen where access tokens are federated directly at 
>>>> the PR. (Introspection lets you do some good things with that 
>>>> pattern.) But that's neither here nor there, as you can already do 
>>>> what you're asking for and I think I can clear things up:
>>>>
>>>> In your case, the "3rd party bearer assertion" is simply *not* the 
>>>> Initial Registration Token. It's an assertion that can be used to 
>>>> *get* an Initial Registration Token. The token that you get from 
>>>> the Token Endpoint, in your case, would be "local" from your own 
>>>> AS. Your registration endpoint would look at this token on the way 
>>>> in, know how to validate it, do whatever else it wants to with it, 
>>>> and process the registration. Then it would issue a Registration 
>>>> Access Token that to the registering client to use at the RESTful 
>>>> endpoint. Incidentally, that token would also be "local", just like 
>>>> before.
>>>
>>>> How you (the client/developer) get the actual Initial Registration 
>>>> Token is completely and forever out of scope for the Dynamic 
>>>> Registration spec.
>>>
>>> [PH]  Yes, the issuance of the third party bearer assertion token 
>>> token would be out of scope of this spec.
>>>
>>> If however the group decides to except federated direct access 
>>> tokens as registration *access* tokens, then I think we have to 
>>> define federation for access tokens first.   For me, I think this is 
>>> something that should be discussed in a different charter.
>>>
>>> [JR] It's an access token, plain and simple. The draft doesn't care 
>>> -- and shouldn't care -- if it's federated or not. I agree, and have 
>>> been arguing all along, that if you have a use case for federated 
>>> access tokens, you need to define the mechanisms for such tokens, 
>>> and that registration is *not* the place for that definition.It's 
>>> orthogonal but they can be used together. Let's define them 
>>> separately but ina compatible way.
>>>
>> [ph] thats not the impression i get from the draft. As i mentioned 
>> earlier using access token for registration is clearer.
>>>>
>>>>
>>>> This all still fits with the current definitions as they are. You 
>>>> don't have to use federated tokens if you don't want to. I can 
>>>> still use them if I want to. Everybody's happy! And this is all 
>>>> because we are not defining any content or semantics tied to the 
>>>> processing of the Initial Registration Token or calling it an 
>>>> Assertion or anything -- it's up to the AS to process it however it 
>>>> would normally process an OAuth Access token. So if your AS needs a 
>>>> local token, then you need to use a local token. If you don't want 
>>>> to use structured foreign tokens as your Initial Registration 
>>>> Tokens, don't. But that shouldn't preclude others of us from doing so.
>>>
>>> [PH] The difference is where the client is expected to present the 
>>> federated (aka 3rd party) assertion.  I would rather follow the 
>>> standard 6749 4.5 method in all cases for consistency.
>>>
>>> You can choose to short circuit, but I think the draft should follow 
>>> a consistent methodology.
>>>
>>> [JR] 6749 section 4.5 (extension grants) is irrelevant to 
>>> registration as it's talking about access to the token endpoint and 
>>> not to protected resources. Additionally, people do use assertions 
>>> encoded inside of OAuth tokens directly at protected resources all 
>>> the time (since OAuth2 tokens are opaque to clients but must be 
>>> understood by protected resources), but that's *still* completely 
>>> irrelevant to this discussion because it doesn't matter in terms of 
>>> the interoperability of the protocol. If you want to use assertions 
>>> or auth codes or client credentials or magic to get your Initial 
>>> Registration Token, the dynamic registration protocol doesn't care 
>>> how you did it. Just like any other OAuth2 protected resource 
>>> doesn't care how you got the token. This abstraction was one of the 
>>> key insights in how OAuth2 is structured as a framework and 
>>> protocol. The important thing here is that if the client gets an 
>>> Initial Registration Token it knows where to send it and how to use 
>>> it. What I hear you saying is that you don't want to use a federated 
>>> token as an Initial Registration Token. That's fine! Don't do it -- 
>>> and you have that option precisely because of how we've already 
>>> written it! If your clients get handed a token that *isn't* an 
>>> Initial Registration Token and you want them to go through another 
>>> step to *get* an Initial Registration Token, so be it! But it 
>>> doesn't make sense to encode that behavior as required into the 
>>> registration protocol, because (as you point out) not everything is 
>>> going to be an assertion in the first place. Again I say that you 
>>> can do everything that you want to do with existing mechanisms or 
>>> self-contained extensions.
>>
>> [ph] i am referring to the mechanism currently defined that accepts 
>> external assertions in exchange for access tokens within the server.
>>
>> When you do it this way all clients are now accessing the reg 
>> endpoint with a short term access token.
>>
>> If you want to make federated access tokens a formal approach you 
>> need to profile it since there is no spec for federated access tokens.
>>
>> IOW, handle federated access tokens the same way 6749 does which is 
>> to say nothing.
>>
>> If you do this you can really simplify registration because now it 
>> just normal oauth protected resource without any special handling.
>>
>>>
>>>>
>>>> If you think it would be helpful, I can add language to the 
>>>> lifecycle discussion to clarify that the Initial Registration Token 
>>>> can be gotten through any number of means, not just the 
>>>> manual-portal approach that's talked about now. Or if you want to 
>>>> write up this specific use case we can add it as another concrete 
>>>> example.
>>>
>>> [PH] I think there is potential to cut a lot of text out of the spec 
>>> if we strictly define the registration endpoint as a normal OAuth2 
>>> protected endpoint.
>>>
>>> [JR] I don't understand what you're saying here -- it already *is* 
>>> an OAuth2 protected endpoint, like I've pointed out below. All 
>>> OAuth2 protected endpoints don't care how you get the token, neither 
>>> does this one. All OAuth2 protected endpoints don't care (from 
>>> OAuth2's perspective) how the token is verified or processed, and 
>>> neither does this one (from the draft's perspective). I explicitly 
>>> want to keep that kind of token and assertion processing *out* of 
>>> this draft because it's more useful to build generally applicable 
>>> mechanisms. If we keep the registration endpoint as an OAuth2 
>>> protected endpoint -- like it already is -- then we can inherit 
>>> whatever mechanisms you want, and that is a very powerful setup.
>>>>
>>>> I will close by pointing out that I have *never* proposed that we 
>>>> dictate that the Registration Endpoint have to accept and process 
>>>> federated tokens, and it would be ludicrous to do so. I have been 
>>>> and still am committed to the Initial Registration Token and the 
>>>> Registration Access Token being plain old opaque-to-the-client 
>>>> OAuth 2 tokens.
>>>
>>> [PH] Agreed.  However, the use case of a 3rd party signer for client 
>>> applications is critical to both commercial organizations and open 
>>> source orgs that publish software that are deployed by many separate 
>>> entities.  The client developer needs to be able to contact the 
>>> publisher in many cases to obtain a signed assertion.
>>>
>>> I believe this is a core use case.
>>>
>>> I believe as I've proposed it using the normal 4.5 exchange 
>>> federated assertion for local token method, the draft doesn't have 
>>> to get into the details of the assertion.  Though that said, I would 
>>> suggest the draft make some suggestions on the contents of such 
>>> assertions.
>>>
>>> [JR] You can already do what you want to without mentioning 
>>> assertions. The current draft doesn't mention assertions at all, 
>>> either. All talk of use of assertions is outside the scope of 
>>> registration. You're proposing adding it in, and I'm strongly 
>>> against that.
>>>>
>>>> I think it's possible that you're still conflating the work I'm 
>>>> doing with the BB+ *extension* to dynamic registration with the 
>>>> dynamic registration document itself. I have never suggested that 
>>>> we pull all the extended BB+ stuff down into Dyn Reg, and in fact I 
>>>> think quite the opposite as I don't believe it's as generally 
>>>> applicable without the larger BB+ stack (which includes discovery 
>>>> as well as reliance on policy and other frameworks).
>>>
>>> [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle 
>>> have very similar requirements.  As I said above, the use case is a 
>>> key use case.
>>>
>>> However I agree, the way you solve it in BB+ is not the way to solve 
>>> it within the draft spec.  I think the BB+ does well inform our 
>>> discussions though.
>>>
>>> [JR] Considering that BB+ manages to do all of this with a cleanly 
>>> defined extension without any changes in the existing draft text, I 
>>> think that's as strong an argument as anything to keep it defined 
>>> how it is, and that what's there is a sufficient base to build on.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/30/2013 03:54 PM, Phil Hunt wrote:
>>>>> Justin,
>>>>>
>>>>> So far, every time an OAuth server has accepted a 3rd party token 
>>>>> it has been a bearer assertion. The common pattern is to exchange 
>>>>> that assertion for a an access token issued by the local server 
>>>>> for the local resource endpoint.
>>>>>
>>>>> That's the pattern I am trying to follow.
>>>>>
>>>>> Going this way means we do not have to define the initial 
>>>>> registration token.
>>>>>
>>>>> If however, you really want to use the initial registration token 
>>>>> AS an access token, you are taking us into the question of using 
>>>>> federated access tokens.  I prefer not to do that here.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>>>>>
>>>>>> I don't understand which access token is being talked about here 
>>>>>> -- is this the Initial Registration Token? Because you can 
>>>>>> already do everything below. How you get the Initial Registration 
>>>>>> token is out of scope precisely so that the AS can decide what 
>>>>>> that means. We can add language in the lifecycle discussions to 
>>>>>> bring up the fact that you can get this token from an OAuth flow, 
>>>>>> if you think that'll help clear things up.
>>>>>>
>>>>>> However, the client doesn't register using the client credential 
>>>>>> flow at all -- it registers using a POST to the registration 
>>>>>> endpoint, and that POST might have an OAuth token attached to it. 
>>>>>> How the client got that OAuth tok=


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


  
    
  
  
    Which token are you referring to here?

    

    If it's the Initial Registration Token, then you could get that
    through the normal token server no problem. (The lifecycle writeups
    don't call this out explicitly but I would be willing to do so.) Or
    you could get it elsewhere. Doesn't matter, just like it doesn't
    matter with any other OAuth2 protected resource.

    

    If it's the Registration Access Token, then having the token come
    from the token endpoint would require a lot more work and complexity
    on behalf of both of the client and server. Either you end up with
    public clients getting secrets they shouldn't need or with granting
    clients access to the client_credentials flow when they shouldn't
    actually have it. Plus it adds extra round trips which don't buy you
    anything.

    

     -- Justin

    

    
On 05/31/2013 10:15 AM, Phil Hunt
      wrote:

    

    

      
      
The preference is to have the access token for registration
        issued by the normal token server rather then by the
        registration endpoint. 

      


      

      
In the current draft it is obtained through a unique process
        and must outlive the client. 

      


        Phil

      


        On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>
        wrote:

        

      

      

        

          
I don't understand any of the
            comments below -- it already *is* an OAuth2 protected
            resource without any special handling. Your access tokens
            can be short-lived, long-lived, federated, structured,
            random blobs ... totally doesn't matter. They are access
            tokens being used to access a normal protected resource.
            Full stop.

            

            Anything else is out of scope. The lifecycle discussions at
            the beginning are merely examples of some ways you *could*
            use it and are non-normative and non-exhaustive.

            

            You seem to be asking for something that's already in the
            draft.

            

             -- Justin

            

            

              

              
From:
                  Phil Hunt [phil.hunt@oracle.com]

                  Sent: Thursday, May 30, 2013 7:31 PM

                  To: Richer, Justin P.

                  Cc: John Bradley; oauth@ietf.org WG

                  Subject: Re: [OAUTH-WG] review comments on
                  draft-ietf-oauth-dyn-reg-11.txt

                

              

              

                


                  

                  Phil

                


                  On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org>
                  wrote:

                  

                

                

                

                  

                    
Comments inline, marked by [JR].

                      

                      

                        

                        
From:
                            Phil Hunt [phil.hunt@oracle.com]

                            Sent: Thursday, May 30, 2013 5:25 PM

                            To: Richer, Justin P.

                            Cc: John Bradley; oauth@ietf.org WG

                            Subject: Re: [OAUTH-WG] review
                            comments on draft-ietf-oauth-dyn-reg-11.txt

                          

                        

                        
See below.

                          
                          

                          

                            
On 2013-05-30, at 2:09 PM, Justin
                              Richer wrote:

                            

                            

                              
OK, I think see
                                part of the hang up. I have not seen the
                                scenario that you describe, where you
                                trade a 3rd party token for a "local"
                                token. I have seen where access tokens
                                are federated directly at the PR.
                                (Introspection lets you do some good
                                things with that pattern.) But that's
                                neither here nor there, as you can
                                already do what you're asking for and I
                                think I can clear things up:

                                

                                In your case, the "3rd party bearer
                                assertion" is simply *not* the Initial
                                Registration Token. It's an assertion
                                that can be used to *get* an Initial
                                Registration Token. The token that you
                                get from the Token Endpoint, in your
                                case, would be "local" from your own AS.
                                Your registration endpoint would look at
                                this token on the way in, know how to
                                validate it, do whatever else it wants
                                to with it, and process the
                                registration. Then it would issue a
                                Registration Access Token that to the
                                registering client to use at the RESTful
                                endpoint. Incidentally, that token would
                                also be "local", just like before.

                            

                            

                            

                              
How you (the
                                client/developer) get the actual Initial
                                Registration Token is completely and
                                forever out of scope for the Dynamic
                                Registration spec.
                                

                              

                            

                            


                            

                            [PH]  Yes, the issuance of the third party
                            bearer assertion token token would be out of
                            scope of this spec.

                          


                          

                          
If however the group decides to except
                            federated direct access tokens as
                            registration *access* tokens, then I think
                            we have to define federation for access
                            tokens first.   For me, I think this is
                            something that should be discussed in a
                            different charter.

                          


                            [JR] It's an access
                              token, plain and simple. The draft doesn't
                              care -- and shouldn't care -- if it's
                              federated or not. I agree, and have been
                              arguing all along, that if you have a use
                              case for federated access tokens, you need
                              to define the mechanisms for such tokens,
                              and that registration is *not* the place
                              for that definition.
                                It's orthogonal but
                                  they can be used together. Let's define them
                                    separately
                                    but in a compatible
                                        way. 

                                  

                                

                        

                      

                    

                  

                

                [ph] thats not the impression i get from the draft. As i
                mentioned earlier using access token for registration is
                clearer. 

                

                  

                    

                      

                        

                          

                            

                              


                                

                                This all still fits with the current
                                definitions as they are. You don't have
                                to use federated tokens if you don't
                                want to. I can still use them if I want
                                to. Everybody's happy! And this is all
                                because we are not defining any content
                                or semantics tied to the processing of
                                the Initial Registration Token or
                                calling it an Assertion or anything --
                                it's up to the AS to process it however
                                it would normally process an OAuth
                                Access token. So if your AS needs a
                                local token, then you need to use a
                                local token. If you don't want to use
                                structured foreign tokens as your
                                Initial Registration Tokens, don't. But
                                that shouldn't preclude others of us
                                from doing so.

                              

                            

                            


                            

                            [PH] The difference is where the client is
                            expected to present the federated (aka 3rd
                            party) assertion.  I would rather follow the
                            standard 6749 4.5 method in all cases for
                            consistency.  

                          


                          

                          
You can choose to short circuit, but I
                            think the draft should follow a consistent
                            methodology.

                          


                              [JR] 6749 section 4.5 (extension grants)
                              is irrelevant to registration as it's
                              talking about access to the token endpoint
                              and not to protected resources.
                              Additionally, people do use assertions
                              encoded inside of OAuth tokens directly at
                              protected resources all the time (since
                              OAuth2 tokens are opaque to clients but
                              must be understood by protected
                              resources), but that's *still* completely
                              irrelevant to this discussion because it
                              doesn't matter in terms of the
                              interoperability of the protocol. If you
                              want to use assertions or auth codes or
                              client credentials or magic to get your
                              Initial Registration Token, the dynamic
                              registration protocol doesn't care how you
                              did it. Just like any other OAuth2
                              protected resource doesn't care how you
                              got the token. This abstraction was one of
                              the key insights in how OAuth2 is
                              structured as a framework and protocol.
                              The important thing here is that if the
                              client gets an Initial Registration Token
                              it knows where to send it and how to use
                              it. What I hear you saying is that you
                              don't want to use a federated token as an
                              Initial Registration Token. That's fine!
                              Don't do it -- and you have that option
                              precisely because of how we've already
                              written it! If your clients get handed a
                              token that *isn't* an Initial Registration
                              Token and you want them to go through
                              another step to *get* an Initial
                              Registration Token, so be it! But it
                              doesn't make sense to encode that behavior
                              as required into the registration
                              protocol, because (as you point out) not
                              everything is going to be an assertion in
                              the first place. Again I say that you can
                              do everything that you want to do with
                              existing mechanisms or self-contained
                              extensions.
                            

                          

                        

                      

                    

                  

                

                


                

                [ph] i am referring to the mechanism currently defined
                that accepts external assertions in exchange for access
                tokens within the server. 
                


                

                
When you do it this way all clients are now
                  accessing the reg endpoint with a short term access
                  token. 

                


                

                
If you want to make federated access tokens a
                  formal approach you need to profile it since there is
                  no spec for federated access tokens. 

                


                

                
IOW, handle federated access tokens the same way
                  6749 does which is to say nothing. 

                


                

                
If you do this you can really simplify registration
                  because now it just normal oauth protected resource
                  without any special handling. 

                


                

                

                  

                    

                      

                        

                          

                            


                              

                                


                                  If you think it would be helpful, I
                                  can add language to the lifecycle
                                  discussion to clarify that the Initial
                                  Registration Token can be gotten
                                  through any number of means, not just
                                  the manual-portal approach that's
                                  talked about now. Or if you want to
                                  write up this specific use case we can
                                  add it as another concrete example. 

                                

                              

                              


                              

                              [PH] I think there is potential to cut a
                              lot of text out of the spec if we strictly
                              define the registration endpoint as a
                              normal OAuth2 protected endpoint.

                              

                              [JR] I don't
                                understand what you're saying here -- it
                                already *is* an OAuth2 protected
                                endpoint, like I've pointed out below.
                                All OAuth2 protected endpoints don't
                                care how you get the token, neither does
                                this one. All OAuth2 protected endpoints
                                don't care (from OAuth2's perspective)
                                how the token is verified or processed,
                                and neither does this one (from the
                                draft's perspective). I explicitly want
                                to keep that kind of token and assertion
                                processing *out* of this draft because
                                it's more useful to build generally
                                applicable mechanisms. If we keep the
                                registration endpoint as an OAuth2
                                protected endpoint -- like it already is
                                -- then we can inherit whatever
                                mechanisms you want, and that is a very
                                powerful setup.

                              

                                


                                  I will close by pointing out that I
                                  have *never* proposed that we dictate
                                  that the Registration Endpoint have to
                                  accept and process federated tokens,
                                  and it would be ludicrous to do so. I
                                  have been and still am committed to
                                  the Initial Registration Token and the
                                  Registration Access Token being plain
                                  old opaque-to-the-client OAuth 2
                                  tokens.
                                  

                                

                              

                              


                              

                              [PH] Agreed.  However, the use case of a
                              3rd party signer for client applications
                              is critical to both commercial
                              organizations and open source orgs that
                              publish software that are deployed by many
                              separate entities.  The client developer
                              needs to be able to contact the publisher
                              in many cases to obtain a signed
                              assertion.  

                            


                            

                            
I believe this is a core use case.  

                            


                            

                            
I believe as I've proposed it using the
                              normal 4.5 exchange federated assertion
                              for local token method, the draft doesn't
                              have to get into the details of the
                              assertion.  Though that said, I would
                              suggest the draft make some suggestions on
                              the contents of such assertions.

                              

                              [JR] You can already
                                do what you want to without mentioning
                                assertions. The current draft doesn't
                                mention assertions at all, either. All
                                talk of use of assertions is outside the
                                scope of registration. You're proposing
                                adding it in, and I'm strongly against
                                that. 

                              

                                


                                  I think it's possible that you're
                                  still conflating the work I'm doing
                                  with the BB+ *extension* to dynamic
                                  registration with the dynamic
                                  registration document itself. I have
                                  never suggested that we pull all the
                                  extended BB+ stuff down into Dyn Reg,
                                  and in fact I think quite the opposite
                                  as I don't believe it's as generally
                                  applicable without the larger BB+
                                  stack (which includes discovery as
                                  well as reliance on policy and other
                                  frameworks).
                                  

                                

                              

                              


                              

                              [PH] I'm only using it as an example. Both
                              Cisco (at IIW) and Oracle have very
                              similar requirements.  As I said above,
                              the use case is a key use case. 

                            


                            

                            
However I agree, the way you solve it
                              in BB+ is not the way to solve it within
                              the draft spec.  I think the BB+ does well
                              inform our discussions though.

                              

                              [JR] Considering that
                                BB+ manages to do all of this with a
                                cleanly defined extension without any
                                changes in the existing draft text, I
                                think that's as strong an argument as
                                anything to keep it defined how it is,
                                and that what's there is a sufficient
                                base to build on.

                              

                                


                                   -- Justin

                                  

                                  
On
                                    05/30/2013 03:54 PM, Phil Hunt
                                    wrote:

                                  

                                  
Justin,
                                    


                                    

                                    
So far, every time an OAuth
                                      server has accepted a 3rd party
                                      token it has been a bearer
                                      assertion. The common pattern is
                                      to exchange that assertion for a
                                      an access token issued by the
                                      local server for the local
                                      resource endpoint.

                                    


                                    

                                    
That's the pattern I am trying
                                      to follow.

                                    


                                    

                                    
Going this way means we do not
                                      have to define the initial
                                      registration token.

                                    


                                    

                                    
If however, you really want to
                                      use the initial registration token
                                      AS an access token, you are taking
                                      us into the question of using
                                      federated access tokens.  I prefer
                                      not to do that here.

                                    


                                    

                                    

                                      

                                        

                                          
                                          

                                          

                                            
On 2013-05-30, at 12:51
                                              PM, Justin Richer wrote:

                                            

                                            

                                              
I
                                                don't understand which
                                                access token is being
                                                talked about here -- is
                                                this the Initial
                                                Registration Token?
                                                Because you can already
                                                do everything below. How
                                                you get the Initial
                                                Registration token is
                                                out of scope precisely
                                                so that the AS can
                                                decide what that means.
                                                We can add language in
                                                the lifecycle
                                                discussions to bring up
                                                the fact that you can
                                                get this token from an
                                                OAuth flow, if you think
                                                that'll help clear
                                                things up.

                                                

                                                However, the client
                                                doesn't register using
                                                the client credential
                                                flow at all -- it
                                                registers using a POST
                                                to the registration
                                                endpoint, and that POST
                                                might have an OAuth
                                                token attached to it.
                                                How the client got that
                                                OAuth tok=

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


--------------010405050703090307080809--

From phil.hunt@oracle.com  Fri May 31 08:11:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E372321F9691 for ; Fri, 31 May 2013 08:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPOpI97rIWEF for ; Fri, 31 May 2013 08:10:55 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C25F921F9622 for ; Fri, 31 May 2013 08:10:48 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VFAlpg027001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 15:10:48 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VFAjIW017702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 15:10:46 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VFAjHb003400; Fri, 31 May 2013 15:10:45 GMT
Received: from [25.2.161.219] (/24.114.78.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 08:10:45 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8B9C4.8020200@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-8276FFE9-7A9E-41C7-B8D3-514463E60430
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 11:10:41 -0400
To: Justin Richer 
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 15:11:02 -0000

--Apple-Mail-8276FFE9-7A9E-41C7-B8D3-514463E60430
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Justin,

This is my primary objection! We can't keep it straight. Their should be no s=
uch thing as a registrstion access token!  Just the token the client obtains=
 to update its profile through the normal token request process.=20

Phil

On 2013-05-31, at 10:55, Justin Richer  wrote:

> Which token are you referring to here?
>=20
> If it's the Initial Registration Token, then you could get that through th=
e normal token server no problem. (The lifecycle writeups don't call this ou=
t explicitly but I would be willing to do so.) Or you could get it elsewhere=
. Doesn't matter, just like it doesn't matter with any other OAuth2 protecte=
d resource.
>=20
> If it's the Registration Access Token, then having the token come from the=
 token endpoint would require a lot more work and complexity on behalf of bo=
th of the client and server. Either you end up with public clients getting s=
ecrets they shouldn't need or with granting clients access to the client_cre=
dentials flow when they shouldn't actually have it. Plus it adds extra round=
 trips which don't buy you anything.
>=20
>  -- Justin
>=20
> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>> The preference is to have the access token for registration issued by the=
 normal token server rather then by the registration endpoint.=20
>>=20
>> In the current draft it is obtained through a unique process and must out=
live the client.=20
>>=20
>> Phil
>>=20
>> On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:
>>=20
>>> I don't understand any of the comments below -- it already *is* an OAuth=
2 protected resource without any special handling. Your access tokens can be=
 short-lived, long-lived, federated, structured, random blobs ... totally do=
esn't matter. They are access tokens being used to access a normal protected=
 resource. Full stop.
>>>=20
>>> Anything else is out of scope. The lifecycle discussions at the beginnin=
g are merely examples of some ways you *could* use it and are non-normative a=
nd non-exhaustive.
>>>=20
>>> You seem to be asking for something that's already in the draft.
>>>=20
>>>  -- Justin
>>>=20
>>> From: Phil Hunt [phil.hunt@oracle.com]
>>> Sent: Thursday, May 30, 2013 7:31 PM
>>> To: Richer, Justin P.
>>> Cc: John Bradley; oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.t=
xt
>>>=20
>>>=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:
>>>=20
>>>> Comments inline, marked by [JR].
>>>>=20
>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>> To: Richer, Justin P.
>>>> Cc: John Bradley; oauth@ietf.org WG
>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.=
txt
>>>>=20
>>>> See below.
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>=20
>>>>> OK, I think see part of the hang up. I have not seen the scenario that=
 you describe, where you trade a 3rd party token for a "local" token. I have=
 seen where access tokens are federated directly at the PR. (Introspection l=
ets you do some good things with that pattern.) But that's neither here nor t=
here, as you can already do what you're asking for and I think I can clear t=
hings up:
>>>>>=20
>>>>> In your case, the "3rd party bearer assertion" is simply *not* the Ini=
tial Registration Token. It's an assertion that can be used to *get* an Init=
ial Registration Token. The token that you get from the Token Endpoint, in y=
our case, would be "local" from your own AS. Your registration endpoint woul=
d look at this token on the way in, know how to validate it, do whatever els=
e it wants to with it, and process the                                 regis=
tration. Then it would issue a Registration Access Token that to the registe=
ring client to use at the RESTful                                 endpoint. I=
ncidentally, that token would also be "local", just like before.
>>>>=20
>>>>> How you (the client/developer) get the actual Initial Registration Tok=
en is completely and forever out of scope for the Dynamic Registration spec.=

>>>>=20
>>>> [PH]  Yes, the issuance of the third party bearer assertion token token=
 would be out of scope of this spec.
>>>>=20
>>>> If however the group decides to except federated direct access tokens a=
s registration *access* tokens, then I think we have to define federation fo=
r access tokens first.   For me, I think this is something that should be di=
scussed in a different charter.
>>>>=20
>>>> [JR] It's an access token, plain and simple. The draft doesn't care -- a=
nd shouldn't care -- if it's federated or not. I agree, and have been arguin=
g all along, that if you have a use case for federated access tokens, you ne=
ed to define the mechanisms for such tokens, and that registration is *not* t=
he place for that definition. It's orthogonal but they can be used together.=
 Let's define them separately but in a compatible way.
>>> [ph] thats not the impression i get from the draft. As i mentioned earli=
er using access token for registration is clearer.=20

--Apple-Mail-8276FFE9-7A9E-41C7-B8D3-514463E60430
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Justin,

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token!  Just the token the client obtains to update its profile through the normal token request process. 

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:


  
    
  
  
    Which token are you referring to here?

    

    If it's the Initial Registration Token, then you could get that
    through the normal token server no problem. (The lifecycle writeups
    don't call this out explicitly but I would be willing to do so.) Or
    you could get it elsewhere. Doesn't matter, just like it doesn't
    matter with any other OAuth2 protected resource.

    

    If it's the Registration Access Token, then having the token come
    from the token endpoint would require a lot more work and complexity
    on behalf of both of the client and server. Either you end up with
    public clients getting secrets they shouldn't need or with granting
    clients access to the client_credentials flow when they shouldn't
    actually have it. Plus it adds extra round trips which don't buy you
    anything.

    

     -- Justin

    

    
On 05/31/2013 10:15 AM, Phil Hunt
      wrote:

    

    

      
      
The preference is to have the access token for registration
        issued by the normal token server rather then by the
        registration endpoint. 

      


      

      
In the current draft it is obtained through a unique process
        and must outlive the client. 

      


        Phil

      


        On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>
        wrote:

        

      

      

        

          
I don't understand any of the
            comments below -- it already *is* an OAuth2 protected
            resource without any special handling. Your access tokens
            can be short-lived, long-lived, federated, structured,
            random blobs ... totally doesn't matter. They are access
            tokens being used to access a normal protected resource.
            Full stop.

            

            Anything else is out of scope. The lifecycle discussions at
            the beginning are merely examples of some ways you *could*
            use it and are non-normative and non-exhaustive.

            

            You seem to be asking for something that's already in the
            draft.

            

             -- Justin

            

            

              

              
From:
                  Phil Hunt [phil.hunt@oracle.com]

                  Sent: Thursday, May 30, 2013 7:31 PM

                  To: Richer, Justin P.

                  Cc: John Bradley; oauth@ietf.org WG

                  Subject: Re: [OAUTH-WG] review comments on
                  draft-ietf-oauth-dyn-reg-11.txt

                

              

              

                


                  

                  Phil

                


                  On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org>
                  wrote:

                  

                

                

                

                  

                    
Comments inline, marked by [JR].

                      

                      

                        

                        
From:
                            Phil Hunt [phil.hunt@oracle.com]

                            Sent: Thursday, May 30, 2013 5:25 PM

                            To: Richer, Justin P.

                            Cc: John Bradley; oauth@ietf.org WG

                            Subject: Re: [OAUTH-WG] review
                            comments on draft-ietf-oauth-dyn-reg-11.txt

                          

                        

                        
See below.

                          
                          

                          

                            
On 2013-05-30, at 2:09 PM, Justin
                              Richer wrote:

                            

                            

                              
OK, I think see
                                part of the hang up. I have not seen the
                                scenario that you describe, where you
                                trade a 3rd party token for a "local"
                                token. I have seen where access tokens
                                are federated directly at the PR.
                                (Introspection lets you do some good
                                things with that pattern.) But that's
                                neither here nor there, as you can
                                already do what you're asking for and I
                                think I can clear things up:

                                

                                In your case, the "3rd party bearer
                                assertion" is simply *not* the Initial
                                Registration Token. It's an assertion
                                that can be used to *get* an Initial
                                Registration Token. The token that you
                                get from the Token Endpoint, in your
                                case, would be "local" from your own AS.
                                Your registration endpoint would look at
                                this token on the way in, know how to
                                validate it, do whatever else it wants
                                to with it, and process the
                                registration. Then it would issue a
                                Registration Access Token that to the
                                registering client to use at the RESTful
                                endpoint. Incidentally, that token would
                                also be "local", just like before.

                            

                            

                            

                              
How you (the
                                client/developer) get the actual Initial
                                Registration Token is completely and
                                forever out of scope for the Dynamic
                                Registration spec.
                                

                              

                            

                            


                            

                            [PH]  Yes, the issuance of the third party
                            bearer assertion token token would be out of
                            scope of this spec.

                          


                          

                          
If however the group decides to except
                            federated direct access tokens as
                            registration *access* tokens, then I think
                            we have to define federation for access
                            tokens first.   For me, I think this is
                            something that should be discussed in a
                            different charter.

                          


                            [JR] It's an access
                              token, plain and simple. The draft doesn't
                              care -- and shouldn't care -- if it's
                              federated or not. I agree, and have been
                              arguing all along, that if you have a use
                              case for federated access tokens, you need
                              to define the mechanisms for such tokens,
                              and that registration is *not* the place
                              for that definition.
                                It's orthogonal but
                                  they can be used together. Let's define them
                                    separately
                                    but in a compatible
                                        way. 

                                  

                                

                        

                      

                    

                  

                

                [ph] thats not the impression i get from the draft. As i
                mentioned earlier using access token for registration is
                clearer. 

                

                  

                    

                      

                        

                          

                            

                              

--Apple-Mail-8276FFE9-7A9E-41C7-B8D3-514463E60430--

From jricher@mitre.org  Fri May 31 08:26:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5351521F9455 for ; Fri, 31 May 2013 08:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Level: 
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.613,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bghx-fdxMAnQ for ; Fri, 31 May 2013 08:26:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF821F9344 for ; Fri, 31 May 2013 08:26:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CF551F0956; Fri, 31 May 2013 11:26:15 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F71A1F0954; Fri, 31 May 2013 11:26:15 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 11:26:15 -0400
Message-ID: <51A8C0ED.6040607@mitre.org>
Date: Fri, 31 May 2013 11:25:33 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020802090108080100050404"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 15:26:22 -0000

--------------020802090108080100050404
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Phil,

We *can* keep it straight just fine, but I just need you to be clear 
about which part you're objecting to because the answers are different. 
Please use the terms as defined in the document so that we all know 
which component we're talking about. I'm sure you'd agree than in 
specification work such as this, precision of language and labels is key 
for communication between parties. This is precisely why there's a 
Terminology section right up front, so that when I say "Registration 
Access Token" you can know that I mean a very specific thing, and when I 
say "Initial Registration Token" I mean a very different specific thing. 
So I'm asking you, please, use the defined terms so that we can avoid 
this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses 
to update is profile" *IS* the Registration Access Token. That's all 
that that token is used for. You're not asking for it to go away, you're 
asking for it to come from the Token Endpoint instead of the response 
from the Registration Endpoint. I don't see how the client *can* get it 
from the normal token process without jumping through specialized hoops 
to make that happen. I've implemented the draft the way that it is right 
now, both client and server side, and it works. Others have implemented 
it, too. We've done interop testing, and it works. This is a proven 
pattern and from where I sit there is both rough consensus and running code.

I believe that I've already pointed out how the solutions you've 
proposed so far won't work in practice, for various reasons, many of 
which have already been brought up and discussed previously. If you have 
another way for the client to get its Registration Access Token, please 
propose it; but I haven't seen anything yet that will fly.

  -- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:
> Justin,
>
> This is my primary objection! We can't keep it straight. Their should 
> be no such thing as a registrstion access token!  Just the token the 
> client obtains to update its profile through the normal token request 
> process.
>
> Phil
>
> On 2013-05-31, at 10:55, Justin Richer  > wrote:
>
>> Which token are you referring to here?
>>
>> If it's the Initial Registration Token, then you could get that 
>> through the normal token server no problem. (The lifecycle writeups 
>> don't call this out explicitly but I would be willing to do so.) Or 
>> you could get it elsewhere. Doesn't matter, just like it doesn't 
>> matter with any other OAuth2 protected resource.
>>
>> If it's the Registration Access Token, then having the token come 
>> from the token endpoint would require a lot more work and complexity 
>> on behalf of both of the client and server. Either you end up with 
>> public clients getting secrets they shouldn't need or with granting 
>> clients access to the client_credentials flow when they shouldn't 
>> actually have it. Plus it adds extra round trips which don't buy you 
>> anything.
>>
>>  -- Justin
>>
>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>> The preference is to have the access token for registration issued 
>>> by the normal token server rather then by the registration endpoint.
>>>
>>> In the current draft it is obtained through a unique process and 
>>> must outlive the client.
>>>
>>> Phil
>>>
>>> On 2013-05-30, at 19:47, "Richer, Justin P." >> > wrote:
>>>
>>>> I don't understand any of the comments below -- it already *is* an 
>>>> OAuth2 protected resource without any special handling. Your access 
>>>> tokens can be short-lived, long-lived, federated, structured, 
>>>> random blobs ... totally doesn't matter. They are access tokens 
>>>> being used to access a normal protected resource. Full stop.
>>>>
>>>> Anything else is out of scope. The lifecycle discussions at the 
>>>> beginning are merely examples of some ways you *could* use it and 
>>>> are non-normative and non-exhaustive.
>>>>
>>>> You seem to be asking for something that's already in the draft.
>>>>
>>>>  -- Justin
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Phil Hunt [phil.hunt@oracle.com ]
>>>> *Sent:* Thursday, May 30, 2013 7:31 PM
>>>> *To:* Richer, Justin P.
>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>
>>>>
>>>>
>>>> Phil
>>>>
>>>> On 2013-05-30, at 16:11, "Richer, Justin P." >>> > wrote:
>>>>
>>>>> Comments inline, marked by [JR].
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Phil Hunt [phil.hunt@oracle.com ]
>>>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>>>> *To:* Richer, Justin P.
>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>
>>>>> See below.
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>
>>>>>> OK, I think see part of the hang up. I have not seen the scenario 
>>>>>> that you describe, where you trade a 3rd party token for a 
>>>>>> "local" token. I have seen where access tokens are federated 
>>>>>> directly at the PR. (Introspection lets you do some good things 
>>>>>> with that pattern.) But that's neither here nor there, as you can 
>>>>>> already do what you're asking for and I think I can clear things up:
>>>>>>
>>>>>> In your case, the "3rd party bearer assertion" is simply *not* 
>>>>>> the Initial Registration Token. It's an assertion that can be 
>>>>>> used to *get* an Initial Registration Token. The token that you 
>>>>>> get from the Token Endpoint, in your case, would be "local" from 
>>>>>> your own AS. Your registration endpoint would look at this token 
>>>>>> on the way in, know how to validate it, do whatever else it wants 
>>>>>> to with it, and process the registration. Then it would issue a 
>>>>>> Registration Access Token that to the registering client to use 
>>>>>> at the RESTful endpoint. Incidentally, that token would also be 
>>>>>> "local", just like before.
>>>>>
>>>>>> How you (the client/developer) get the actual Initial 
>>>>>> Registration Token is completely and forever out of scope for the 
>>>>>> Dynamic Registration spec.
>>>>>
>>>>> [PH]  Yes, the issuance of the third party bearer assertion token 
>>>>> token would be out of scope of this spec.
>>>>>
>>>>> If however the group decides to except federated direct access 
>>>>> tokens as registration *access* tokens, then I think we have to 
>>>>> define federation for access tokens first.   For me, I think this 
>>>>> is something that should be discussed in a different charter.
>>>>>
>>>>> [JR] It's an access token, plain and simple. The draft doesn't 
>>>>> care -- and shouldn't care -- if it's federated or not. I agree, 
>>>>> and have been arguing all along, that if you have a use case for 
>>>>> federated access tokens, you need to define the mechanisms for 
>>>>> such tokens, and that registration is *not* the place for that 
>>>>> definition.It's orthogonal but they can be used together. Let's 
>>>>> define them separately but ina compatible way.
>>>>>
>>>> [ph] thats not the impression i get from the draft. As i mentioned 
>>>> earlier using access token for registration is clearer.


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


  
    
  
  
    Phil,

    

    We *can* keep it straight just fine, but I just need you to be clear
    about which part you're objecting to because the answers are
    different. Please use the terms as defined in the document so that
    we all know which component we're talking about. I'm sure you'd
    agree than in specification work such as this, precision of language
    and labels is key for communication between parties. This is
    precisely why there's a Terminology section right up front, so that
    when I say "Registration Access Token" you can know that I mean a
    very specific thing, and when I say "Initial Registration Token" I
    mean a very different specific thing. So I'm asking you, please, use
    the defined terms so that we can avoid this unnecessary confusion.

    

    But anyway, what you're talking about below, "the token the client
    uses to update is profile" *IS* the Registration Access Token.
    That's all that that token is used for. You're not asking for it to
    go away, you're asking for it to come from the Token Endpoint
    instead of the response from the Registration Endpoint. I don't see
    how the client *can* get it from the normal token process without
    jumping through specialized hoops to make that happen. I've
    implemented the draft the way that it is right now, both client and
    server side, and it works. Others have implemented it, too. We've
    done interop testing, and it works. This is a proven pattern and
    from where I sit there is both rough consensus and running code.

    

    I believe that I've already pointed out how the solutions you've
    proposed so far won't work in practice, for various reasons, many of
    which have already been brought up and discussed previously. If you
    have another way for the client to get its Registration Access
    Token, please propose it; but I haven't seen anything yet that will
    fly.

    

     -- Justin

    

    
On 05/31/2013 11:10 AM, Phil Hunt
      wrote:

    

    

      
      
Justin,

      


      

      
This is my primary objection! We can't keep it straight.
        Their should be no such thing as a registrstion access token!
         Just the token the client obtains to update its profile through
        the normal token request process. 

        

        Phil

      


        On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

      

        
 Which token are you referring to here?

          

          If it's the Initial Registration Token, then you could get
          that through the normal token server no problem. (The
          lifecycle writeups don't call this out explicitly but I would
          be willing to do so.) Or you could get it elsewhere. Doesn't
          matter, just like it doesn't matter with any other OAuth2
          protected resource.

          

          If it's the Registration Access Token, then having the token
          come from the token endpoint would require a lot more work and
          complexity on behalf of both of the client and server. Either
          you end up with public clients getting secrets they shouldn't
          need or with granting clients access to the client_credentials
          flow when they shouldn't actually have it. Plus it adds extra
          round trips which don't buy you anything.

          

           -- Justin

          

          
On 05/31/2013 10:15 AM, Phil Hunt
            wrote:

          

          

            
The preference is to have the access token for
              registration issued by the normal token server rather then
              by the registration endpoint. 

            


            

            
In the current draft it is obtained through a unique
              process and must outlive the client. 

            


              Phil

            


              On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>

              wrote:

              

            

            

              

                
I don't understand any of
                  the comments below -- it already *is* an OAuth2
                  protected resource without any special handling. Your
                  access tokens can be short-lived, long-lived,
                  federated, structured, random blobs ... totally
                  doesn't matter. They are access tokens being used to
                  access a normal protected resource. Full stop.

                  

                  Anything else is out of scope. The lifecycle
                  discussions at the beginning are merely examples of
                  some ways you *could* use it and are non-normative and
                  non-exhaustive.

                  

                  You seem to be asking for something that's already in
                  the draft.

                  

                   -- Justin

                  

                  

                    

                    
From:
                        Phil Hunt [phil.hunt@oracle.com]

                        Sent: Thursday, May 30, 2013 7:31 PM

                        To: Richer, Justin P.

                        Cc: John Bradley; oauth@ietf.org
                        WG

                        Subject: Re: [OAUTH-WG] review comments
                        on draft-ietf-oauth-dyn-reg-11.txt

                      

                    

                    

                      


                        

                        Phil

                      


                        On 2013-05-30, at 16:11, "Richer, Justin P."
                        <jricher@mitre.org>
                        wrote:

                        

                      

                      

                      

                        

                          
Comments inline, marked by
                              [JR].

                            

                            

                              

                              
From:
                                  Phil Hunt [phil.hunt@oracle.com]

                                  Sent: Thursday, May 30, 2013
                                  5:25 PM

                                  To: Richer, Justin P.

                                  Cc: John Bradley; oauth@ietf.org
                                  WG

                                  Subject: Re: [OAUTH-WG] review
                                  comments on
                                  draft-ietf-oauth-dyn-reg-11.txt

                                

                              

                              
See below.

                                
                                

                                

                                  
On 2013-05-30, at 2:09 PM, Justin
                                    Richer wrote:

                                  

                                  

                                    
OK, I think
                                      see part of the hang up. I have
                                      not seen the scenario that you
                                      describe, where you trade a 3rd
                                      party token for a "local" token. I
                                      have seen where access tokens are
                                      federated directly at the PR.
                                      (Introspection lets you do some
                                      good things with that pattern.)
                                      But that's neither here nor there,
                                      as you can already do what you're
                                      asking for and I think I can clear
                                      things up:

                                      

                                      In your case, the "3rd party
                                      bearer assertion" is simply *not*
                                      the Initial Registration Token.
                                      It's an assertion that can be used
                                      to *get* an Initial Registration
                                      Token. The token that you get from
                                      the Token Endpoint, in your case,
                                      would be "local" from your own AS.
                                      Your registration endpoint would
                                      look at this token on the way in,
                                      know how to validate it, do
                                      whatever else it wants to with it,
                                      and process the registration. Then
                                      it would issue a Registration
                                      Access Token that to the
                                      registering client to use at the
                                      RESTful endpoint. Incidentally,
                                      that token would also be "local",
                                      just like before.

                                  

                                  

                                  

                                    
How you (the
                                      client/developer) get the actual
                                      Initial Registration Token is
                                      completely and forever out of
                                      scope for the Dynamic Registration
                                      spec. 

                                    

                                  

                                  


                                  

                                  [PH]  Yes, the issuance of the third
                                  party bearer assertion token token
                                  would be out of scope of this spec.

                                


                                

                                
If however the group decides to
                                  except federated direct access tokens
                                  as registration *access* tokens, then
                                  I think we have to define federation
                                  for access tokens first.   For me, I
                                  think this is something that should be
                                  discussed in a different charter.

                                


                                  [JR] It's an
                                    access token, plain and simple. The
                                    draft doesn't care -- and shouldn't
                                    care -- if it's federated or not. I
                                    agree,
                                    and have been arguing all along,
                                    that if you have a use case for
                                    federated access tokens, you need to
                                    define the mechanisms for such
                                    tokens, and that registration is
                                    *not* the place for that definition. It's orthogonal but they can
                                        be used together. Let's define them
                                          separately but in a
                                              compatible way. 

                                        

                                      

                              

                            

                          

                        

                      

                      [ph] thats not the impression i get from the
                      draft. As i mentioned earlier using access token
                      for registration is clearer. 

                      

                        

                          

                            

                              

                                

                                  
 

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


--------------020802090108080100050404--

From phil.hunt@oracle.com  Fri May 31 09:28:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3121F8FAF for ; Fri, 31 May 2013 09:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.58
X-Spam-Level: 
X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.819, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs-w6wqfAc+U for ; Fri, 31 May 2013 09:28:26 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F521F87CD for ; Fri, 31 May 2013 09:28:22 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VGSJnj018579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 16:28:20 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VGSKv6000467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 16:28:20 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VGSKvR000463; Fri, 31 May 2013 16:28:20 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 09:28:19 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  ! <51A8C0ED.6040607@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8C0ED.6040607@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-50F20398-83B0-4D92-A1BC-9A02322DA15E
Content-Transfer-Encoding: 7bit
Message-Id: <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 12:28:18 -0400
To: Justin Richer 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 16:28:32 -0000

--Apple-Mail-50F20398-83B0-4D92-A1BC-9A02322DA15E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I disagree.=20

There is absolutely no need for a registration access token.=20

Get rid of it and just use access tokens as per 6749. If you can't follow 67=
49 and need new issuing methods, what are others to say regarding inventing n=
ew methods?

I have not heard a good reason for the special process or one good enough to=
 warrant a new method for issuing an access token. Does the broader group re=
alize this is what the spec says?

Yes, i heard a lot saying OIDC does it this way. But that is a political rea=
son, not a technical reason. Still, compatibility is always a strong objecti=
ve.  Even so, oidc could keep using their method just fine. There is no obli=
gation here to do the same.=20

The only reason so far was expiry of client creds. Well, why not require the=
 client to update prior to expiry? It makes no sense to have another token w=
ith longer expiry. B'sides, even expired the client can re-register from scr=
atch.=20

Why force the client to persist multiple tokens and creds? That is far far t=
oo complex.=20

Finally if you get rid of registration access token the spec size will drop r=
oughly in half IMO. This suggests simplicity to me.=20

Apologies for my rant. Maybe we should park this for now. We are going in ci=
rcles.=20

Phil

On 2013-05-31, at 11:25, Justin Richer  wrote:

> Phil,
>=20
> We *can* keep it straight just fine, but I just need you to be clear about=
 which part you're objecting to because the answers are different. Please us=
e the terms as defined in the document so that we all know which component w=
e're talking about. I'm sure you'd agree than in specification work such as t=
his, precision of language and labels is key for communication between parti=
es. This is precisely why there's a Terminology section right up front, so t=
hat when I say "Registration Access Token" you can know that I mean a very s=
pecific thing, and when I say "Initial Registration Token" I mean a very dif=
ferent specific thing. So I'm asking you, please, use the defined terms so t=
hat we can avoid this unnecessary confusion.
>=20
> But anyway, what you're talking about below, "the token the client uses to=
 update is profile" *IS* the Registration Access Token. That's all that that=
 token is used for. You're not asking for it to go away, you're asking for i=
t to come from the Token Endpoint instead of the response from the Registrat=
ion Endpoint. I don't see how the client *can* get it from the normal token p=
rocess without jumping through specialized hoops to make that happen. I've i=
mplemented the draft the way that it is right now, both client and server si=
de, and it works. Others have implemented it, too. We've done interop testin=
g, and it works. This is a proven pattern and from where I sit there is both=
 rough consensus and running code.
>=20
> I believe that I've already pointed out how the solutions you've proposed s=
o far won't work in practice, for various reasons, many of which have alread=
y been brought up and discussed previously. If you have another way for the c=
lient to get its Registration Access Token, please propose it; but I haven't=
 seen anything yet that will fly.
>=20
>  -- Justin
>=20
> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>> Justin,
>>=20
>> This is my primary objection! We can't keep it straight. Their should be n=
o such thing as a registrstion access token!  Just the token the client obta=
ins to update its profile through the normal token request process.=20
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>=20
>>> Which token are you referring to here?
>>>=20
>>> If it's the Initial Registration Token, then you could get that through t=
he normal token server no problem. (The lifecycle writeups don't call this o=
ut explicitly but I would be willing to do so.) Or you could get it elsewher=
e. Doesn't matter, just like it doesn't matter with any other OAuth2 protect=
ed resource.
>>>=20
>>> If it's the Registration Access Token, then having the token come from t=
he token endpoint would require a lot more work and complexity on behalf of b=
oth of the client and server. Either you end up with public clients getting s=
ecrets they shouldn't need or with granting clients access to the client_cre=
dentials flow when they shouldn't actually have it. Plus it adds extra round=
 trips which don't buy you anything.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 10:15 AM, Phil Hunt             wrote:
>>>> The preference is to have the access token for registration issued by t=
he normal token server rather then by the registration endpoint.=20
>>>>=20
>>>> In the current draft it is obtained through a unique process and must o=
utlive the client.=20
>>>>=20
>>>> Phil
>>>>=20
>>>> On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:=

>>>>=20
>>>>> I don't understand any of the comments below -- it already *is* an OAu=
th2 protected resource without any special handling. Your access tokens can b=
e short-lived, long-lived,                   federated, structured, random b=
lobs ... totally doesn't matter. They are access tokens being used to access=
 a normal protected resource. Full stop.
>>>>>=20
>>>>> Anything else is out of scope. The lifecycle discussions at the beginn=
ing are merely examples of some ways you *could* use it and are non-normativ=
e and non-exhaustive.
>>>>>=20
>>>>> You seem to be asking for something that's already in the draft.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>> Sent: Thursday, May 30, 2013 7:31 PM
>>>>> To: Richer, Justin P.
>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11=
.txt
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> On 2013-05-30, at 16:11, "Richer, Justin P."  wrote=
:
>>>>>=20
>>>>>> Comments inline, marked by [JR].
>>>>>>=20
>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>>>> To: Richer, Justin P.
>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-1=
1.txt
>>>>>>=20
>>>>>> See below.
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>=20
>>>>>>> OK, I think see part of the hang up. I have not seen the scenario th=
at you describe, where you trade a 3rd                                      =
 party token for a "local" token. I have seen where access tokens are federa=
ted directly at the PR. (Introspection lets you do some good things with tha=
t pattern.)

--Apple-Mail-50F20398-83B0-4D92-A1BC-9A02322DA15E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I disagree. 

=

There is absolutely no need for a registration access token. 

Get rid of it and just use access tokens as per 6749. I=
f you can't follow 6749 and need new issuing methods, what are others to say=
 regarding inventing new methods?

I have not heard a=
 good reason for the special process or one good enough to warrant a new met=
hod for issuing an access token. Does the broader group realize this is what=
 the spec says?

Yes, i heard a lot saying OIDC does=
 it this way. But that is a political reason, not a technical reason. Still,=
 compatibility is always a strong objective.  Even so, oidc could keep u=
sing their method just fine. There is no obligation here to do the same.&nbs=
p;

The only reason so far was expiry of client cred=
s. Well, why not require the client to update prior to expiry? It makes no s=
ense to have another token with longer expiry. B'sides, even expired the cli=
ent can re-register from scratch. 

Why force t=
he client to persist multiple tokens and creds? That is far far too complex.=
 

Finally if you get rid of registration acces=
s token the spec size will drop roughly in half IMO. This suggests simplicit=
y to me. 

Apologies for my rant. Maybe we shou=
ld park this for now. We are going in circles. 

Phil
<=
br>On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:


 =20
    
 =20
 =20
    Phil,

    

    We *can* keep it straight just fine, but I just need you to be clear
    about which part you're objecting to because the answers are
    different. Please use the terms as defined in the document so that
    we all know which component we're talking about. I'm sure you'd
    agree than in specification work such as this, precision of language
    and labels is key for communication between parties. This is
    precisely why there's a Terminology section right up front, so that
    when I say "Registration Access Token" you can know that I mean a
    very specific thing, and when I say "Initial Registration Token" I
    mean a very different specific thing. So I'm asking you, please, use
    the defined terms so that we can avoid this unnecessary confusion.

    

    But anyway, what you're talking about below, "the token the client
    uses to update is profile" *IS* the Registration Access Token.
    That's all that that token is used for. You're not asking for it to
    go away, you're asking for it to come from the Token Endpoint
    instead of the response from the Registration Endpoint. I don't see
    how the client *can* get it from the normal token process without
    jumping through specialized hoops to make that happen. I've
    implemented the draft the way that it is right now, both client and
    server side, and it works. Others have implemented it, too. We've
    done interop testing, and it works. This is a proven pattern and
    from where I sit there is both rough consensus and running code.

    

    I believe that I've already pointed out how the solutions you've
    proposed so far won't work in practice, for various reasons, many of
    which have already been brought up and discussed previously. If you
    have another way for the client to get its Registration Access
    Token, please propose it; but I haven't seen anything yet that will
    fly.

    

     -- Justin

    

    
On 05/31/2013 11:10 AM, Phil Hunt
      wrote:

    

    

      
      
Justin,

      


      

      
This is my primary objection! We can't keep it straight.
        Their should be no such thing as a registrstion access token!
         Just the token the client obtains to update its profile throug=
h
        the normal token request process. 

        

        Phil

      


        On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

      

        
 Which token are you referring to here?

          

          If it's the Initial Registration Token, then you could get
          that through the normal token server no problem. (The
          lifecycle writeups don't call this out explicitly but I would
          be willing to do so.) Or you could get it elsewhere. Doesn't
          matter, just like it doesn't matter with any other OAuth2
          protected resource.

          

          If it's the Registration Access Token, then having the token
          come from the token endpoint would require a lot more work and
          complexity on behalf of both of the client and server. Either
          you end up with public clients getting secrets they shouldn't
          need or with granting clients access to the client_credentials
          flow when they shouldn't actually have it. Plus it adds extra
          round trips which don't buy you anything.

          

           -- Justin

          

          
On 05/31/2013 10:15 AM, Phil Hunt
            wrote:

          

          

            
The preference is to have the access token for
              registration issued by the normal token server rather then
              by the registration endpoint. 

            


            

            
In the current draft it is obtained through a unique
              process and must outlive the client. 

            


              Phil

            


              On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>

              wrote:

              

            

            

              

                
I don't understand any of
                  the comments below -- it already *is* an OAuth2
                  protected resource without any special handling. Your
                  access tokens can be short-lived, long-lived,
                  federated, structured, random blobs ... totally
                  doesn't matter. They are access tokens being used to
                  access a normal protected resource. Full stop.

                  

                  Anything else is out of scope. The lifecycle
                  discussions at the beginning are merely examples of
                  some ways you *could* use it and are non-normative and
                  non-exhaustive.

                  

                  You seem to be asking for something that's already in
                  the draft.

                  

                   -- Justin

                  

                  

                    

                    
From:
                        Phil Hunt [phil.hunt@oracle.com]

                        Sent: Thursday, May 30, 2013 7:31 PM

                        To: Richer, Justin P.

                        Cc: John Bradley; oauth@ietf.org
                        WG

                        Subject: Re: [OAUTH-WG] review comments
                        on draft-ietf-oauth-dyn-reg-11.txt

                      

                    

                    

                      


                        

                        Phil

                      


                        On 2013-05-30, at 16:11, "Richer, Justin P."
                        <jricher@mitre.org>
                        wrote:

                        

                      

                      

                      

                        

                          
Comments inline, marked by
                              [JR].

                            

                            

                              

                              
From:
                                  Phil Hunt [phil.hunt@oracle.com=
]

                                  Sent: Thursday, May 30, 2013
                                  5:25 PM

                                  To: Richer, Justin P.

                                  Cc: John Bradley; oauth@ietf.org
                                  WG

                                  Subject: Re: [OAUTH-WG] review
                                  comments on
                                  draft-ietf-oauth-dyn-reg-11.txt

                                

                              

                              
See below.

                                

                                      
                                

                                

                                  
On 2013-05-30, at 2:09 PM, Justin
                                    Richer wrote:

                                  

                                  

                                    
OK, I think
                                      see part of the hang up. I have
                                      not seen the scenario that you
                                      describe, where you trade a 3rd
                                      party token for a "local" token. I
                                      have seen where access tokens are
                                      federated directly at the PR.
                                      (Introspection lets you do some
                                      good things with that pattern.)
                     
=

=

--Apple-Mail-50F20398-83B0-4D92-A1BC-9A02322DA15E--

From jricher@mitre.org  Fri May 31 09:35:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9721F8B64 for ; Fri, 31 May 2013 09:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAbOXDh4Ntne for ; Fri, 31 May 2013 09:35:26 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F37D21F86D5 for ; Fri, 31 May 2013 09:35:26 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7BDE1F09BF; Fri, 31 May 2013 12:35:25 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8B63B1F09C0; Fri, 31 May 2013 12:35:25 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 12:35:24 -0400
Message-ID: <51A8D123.3090103@mitre.org>
Date: Fri, 31 May 2013 12:34:43 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  ! <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>
In-Reply-To: <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>
Content-Type: multipart/alternative; boundary="------------040307050704000703040408"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 16:35:32 -0000

--------------040307050704000703040408
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

I agree that we are going in circles, since I just was going to bring up 
my counter argument of "what about clients with no credentials?" again, 
which *still* isn't addressed by what you suggest doing, below. I also 
believe that getting rid of the Registration Access Token but using some 
other token method would actually make the spec larger, though I'd be 
glad to review a concrete counter-proposal if you'd like to write one. 
And the fact that OIDC is doing it this way, and considered but rejected 
the way that you're describing, should say something to the WG here 
about whether or not this is the right choice. Rough consensus and 
running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll 
move to the next draft in the last call process shortly, as I have a 
handful of non-normative editorial changes that I need to make, thanks 
to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to 
future feedback.

  -- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:
> I disagree.
>
> There is absolutely no need for a registration access token.
>
> Get rid of it and just use access tokens as per 6749. If you can't 
> follow 6749 and need new issuing methods, what are others to say 
> regarding inventing new methods?
>
> I have not heard a good reason for the special process or one good 
> enough to warrant a new method for issuing an access token. Does the 
> broader group realize this is what the spec says?
>
> Yes, i heard a lot saying OIDC does it this way. But that is a 
> political reason, not a technical reason. Still, compatibility is 
> always a strong objective.  Even so, oidc could keep using their 
> method just fine. There is no obligation here to do the same.
>
> The only reason so far was expiry of client creds. Well, why not 
> require the client to update prior to expiry? It makes no sense to 
> have another token with longer expiry. B'sides, even expired the 
> client can re-register from scratch.
>
> Why force the client to persist multiple tokens and creds? That is far 
> far too complex.
>
> Finally if you get rid of registration access token the spec size will 
> drop roughly in half IMO. This suggests simplicity to me.
>
> Apologies for my rant. Maybe we should park this for now. We are going 
> in circles.
>
> Phil
>
> On 2013-05-31, at 11:25, Justin Richer  > wrote:
>
>> Phil,
>>
>> We *can* keep it straight just fine, but I just need you to be clear 
>> about which part you're objecting to because the answers are 
>> different. Please use the terms as defined in the document so that we 
>> all know which component we're talking about. I'm sure you'd agree 
>> than in specification work such as this, precision of language and 
>> labels is key for communication between parties. This is precisely 
>> why there's a Terminology section right up front, so that when I say 
>> "Registration Access Token" you can know that I mean a very specific 
>> thing, and when I say "Initial Registration Token" I mean a very 
>> different specific thing. So I'm asking you, please, use the defined 
>> terms so that we can avoid this unnecessary confusion.
>>
>> But anyway, what you're talking about below, "the token the client 
>> uses to update is profile" *IS* the Registration Access Token. That's 
>> all that that token is used for. You're not asking for it to go away, 
>> you're asking for it to come from the Token Endpoint instead of the 
>> response from the Registration Endpoint. I don't see how the client 
>> *can* get it from the normal token process without jumping through 
>> specialized hoops to make that happen. I've implemented the draft the 
>> way that it is right now, both client and server side, and it works. 
>> Others have implemented it, too. We've done interop testing, and it 
>> works. This is a proven pattern and from where I sit there is both 
>> rough consensus and running code.
>>
>> I believe that I've already pointed out how the solutions you've 
>> proposed so far won't work in practice, for various reasons, many of 
>> which have already been brought up and discussed previously. If you 
>> have another way for the client to get its Registration Access Token, 
>> please propose it; but I haven't seen anything yet that will fly.
>>
>>  -- Justin
>>
>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>> Justin,
>>>
>>> This is my primary objection! We can't keep it straight. Their 
>>> should be no such thing as a registrstion access token!  Just the 
>>> token the client obtains to update its profile through the normal 
>>> token request process.
>>>
>>> Phil
>>>
>>> On 2013-05-31, at 10:55, Justin Richer >> > wrote:
>>>
>>>> Which token are you referring to here?
>>>>
>>>> If it's the Initial Registration Token, then you could get that 
>>>> through the normal token server no problem. (The lifecycle writeups 
>>>> don't call this out explicitly but I would be willing to do so.) Or 
>>>> you could get it elsewhere. Doesn't matter, just like it doesn't 
>>>> matter with any other OAuth2 protected resource.
>>>>
>>>> If it's the Registration Access Token, then having the token come 
>>>> from the token endpoint would require a lot more work and 
>>>> complexity on behalf of both of the client and server. Either you 
>>>> end up with public clients getting secrets they shouldn't need or 
>>>> with granting clients access to the client_credentials flow when 
>>>> they shouldn't actually have it. Plus it adds extra round trips 
>>>> which don't buy you anything.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>> The preference is to have the access token for registration issued 
>>>>> by the normal token server rather then by the registration endpoint.
>>>>>
>>>>> In the current draft it is obtained through a unique process and 
>>>>> must outlive the client.
>>>>>
>>>>> Phil
>>>>>
>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." >>>> > wrote:
>>>>>
>>>>>> I don't understand any of the comments below -- it already *is* 
>>>>>> an OAuth2 protected resource without any special handling. Your 
>>>>>> access tokens can be short-lived, long-lived, federated, 
>>>>>> structured, random blobs ... totally doesn't matter. They are 
>>>>>> access tokens being used to access a normal protected resource. 
>>>>>> Full stop.
>>>>>>
>>>>>> Anything else is out of scope. The lifecycle discussions at the 
>>>>>> beginning are merely examples of some ways you *could* use it and 
>>>>>> are non-normative and non-exhaustive.
>>>>>>
>>>>>> You seem to be asking for something that's already in the draft.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>> ]
>>>>>> *Sent:* Thursday, May 30, 2013 7:31 PM
>>>>>> *To:* Richer, Justin P.
>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." >>>>> > wrote:
>>>>>>
>>>>>>> Comments inline, marked by [JR].
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>>> ]
>>>>>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>>>>>> *To:* Richer, Justin P.
>>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>
>>>>>>> See below.
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com 
>>>>>>> phil.hunt@oracle.com 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>> OK, I think see part of the hang up. I have not seen the 
>>>>>>>> scenario that you describe, where you trade a 3rd party token 
>>>>>>>> for a "local" token. I have seen where access tokens are 
>>>>>>>> federated directly at the PR. (Introspection lets you do some 
>>>>>>>> good things with that pattern.)


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


  
    
  
  
    I agree that we are going in circles, since I just was going to
    bring up my counter argument of "what about clients with no
    credentials?" again, which *still* isn't addressed by what you
    suggest doing, below. I also believe that getting rid of the
    Registration Access Token but using some other token method would
    actually make the spec larger, though I'd be glad to review a
    concrete counter-proposal if you'd like to write one. And the fact
    that OIDC is doing it this way, and considered but rejected the way
    that you're describing, should say something to the WG here about
    whether or not this is the right choice. Rough consensus and running
    code, after all.

    

    Regardless, I agree to park this issue and leave the text as is.
    We'll move to the next draft in the last call process shortly, as I
    have a handful of non-normative editorial changes that I need to
    make, thanks to feedback from a few folks.

    

    Again, thanks for your thorough review, Phil, and I look forward to
    future feedback.

    

     -- Justin

    

    
On 05/31/2013 12:28 PM, Phil Hunt
      wrote:

    

    

      
      
I disagree. 

      


      

      
There is absolutely no need for a registration access token. 

      


      

      
Get rid of it and just use access tokens as per 6749. If you
        can't follow 6749 and need new issuing methods, what are others
        to say regarding inventing new methods?

      


      

      
I have not heard a good reason for the special process or one
        good enough to warrant a new method for issuing an access token.
        Does the broader group realize this is what the spec says?

      


      

      
Yes, i heard a lot saying OIDC does it this way. But that is
        a political reason, not a technical reason. Still, compatibility
        is always a strong objective.  Even so, oidc could keep using
        their method just fine. There is no obligation here to do the
        same. 

      


      

      
The only reason so far was expiry of client creds. Well, why
        not require the client to update prior to expiry? It makes no
        sense to have another token with longer expiry. B'sides, even
        expired the client can re-register from scratch. 

      


      

      
Why force the client to persist multiple tokens and creds?
        That is far far too complex. 

      


      

      
Finally if you get rid of registration access token the spec
        size will drop roughly in half IMO. This suggests simplicity to
        me. 

      


      

      
Apologies for my rant. Maybe we should park this for now. We
        are going in circles. 

        

        Phil

      


        On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

      

        
 Phil,

          

          We *can* keep it straight just fine, but I just need you to be
          clear about which part you're objecting to because the answers
          are different. Please use the terms as defined in the document
          so that we all know which component we're talking about. I'm
          sure you'd agree than in specification work such as this,
          precision of language and labels is key for communication
          between parties. This is precisely why there's a Terminology
          section right up front, so that when I say "Registration
          Access Token" you can know that I mean a very specific thing,
          and when I say "Initial Registration Token" I mean a very
          different specific thing. So I'm asking you, please, use the
          defined terms so that we can avoid this unnecessary confusion.

          

          But anyway, what you're talking about below, "the token the
          client uses to update is profile" *IS* the Registration Access
          Token. That's all that that token is used for. You're not
          asking for it to go away, you're asking for it to come from
          the Token Endpoint instead of the response from the
          Registration Endpoint. I don't see how the client *can* get it
          from the normal token process without jumping through
          specialized hoops to make that happen. I've implemented the
          draft the way that it is right now, both client and server
          side, and it works. Others have implemented it, too. We've
          done interop testing, and it works. This is a proven pattern
          and from where I sit there is both rough consensus and running
          code.

          

          I believe that I've already pointed out how the solutions
          you've proposed so far won't work in practice, for various
          reasons, many of which have already been brought up and
          discussed previously. If you have another way for the client
          to get its Registration Access Token, please propose it; but I
          haven't seen anything yet that will fly.

          

           -- Justin

          

          
On 05/31/2013 11:10 AM, Phil Hunt
            wrote:

          

          

            
Justin,

            


            

            
This is my primary objection! We can't keep it
              straight. Their should be no such thing as a registrstion
              access token!  Just the token the client obtains to update
              its profile through the normal token request process. 

              

              Phil

            


              On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

            

              
 Which token are you referring to here?

                

                If it's the Initial Registration Token, then you could
                get that through the normal token server no problem.
                (The lifecycle writeups don't call this out explicitly
                but I would be willing to do so.) Or you could get it
                elsewhere. Doesn't matter, just like it doesn't matter
                with any other OAuth2 protected resource.

                

                If it's the Registration Access Token, then having the
                token come from the token endpoint would require a lot
                more work and complexity on behalf of both of the client
                and server. Either you end up with public clients
                getting secrets they shouldn't need or with granting
                clients access to the client_credentials flow when they
                shouldn't actually have it. Plus it adds extra round
                trips which don't buy you anything.

                

                 -- Justin

                

                
On 05/31/2013 10:15 AM,
                  Phil Hunt wrote:

                

                

                  
The preference is to have the access token for
                    registration issued by the normal token server
                    rather then by the registration endpoint. 

                  


                  

                  
In the current draft it is obtained through a
                    unique process and must outlive the client. 

                  


                    Phil

                  


                    On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>


                    wrote:

                    

                  

                  

                    

                      
I don't
                        understand any of the comments below -- it
                        already *is* an OAuth2 protected resource
                        without any special handling. Your access tokens
                        can be short-lived, long-lived, federated,
                        structured, random blobs ... totally doesn't
                        matter. They are access tokens being used to
                        access a normal protected resource. Full stop.

                        

                        Anything else is out of scope. The lifecycle
                        discussions at the beginning are merely examples
                        of some ways you *could* use it and are
                        non-normative and non-exhaustive.

                        

                        You seem to be asking for something that's
                        already in the draft.

                        

                         -- Justin

                        

                        

                          

                          
From:
                              Phil Hunt [phil.hunt@oracle.com]

                              Sent: Thursday, May 30, 2013 7:31
                              PM

                              To: Richer, Justin P.

                              Cc: John Bradley; oauth@ietf.org
                              WG

                              Subject: Re: [OAUTH-WG] review
                              comments on
                              draft-ietf-oauth-dyn-reg-11.txt

                            

                          

                          

                            


                              

                              Phil

                            


                              On 2013-05-30, at 16:11, "Richer, Justin
                              P." <jricher@mitre.org>

                              wrote:

                              

                            

                            

                            

                              

                                
Comments
                                    inline, marked by [JR].

                                  

                                  

                                    

                                    
From: Phil Hunt
                                        [phil.hunt@oracle.com]

                                        Sent: Thursday, May 30,
                                        2013 5:25 PM

                                        To: Richer, Justin P.

                                        Cc: John Bradley; oauth@ietf.org
                                        WG

                                        Subject: Re: [OAUTH-WG]
                                        review comments on
                                        draft-ietf-oauth-dyn-reg-11.txt

                                      

                                    

                                    
See below.

                                      
                                      

                                      

                                        
On 2013-05-30, at 2:09 PM,
                                          Justin Richer wrote:

                                        

                                        

                                          
OK, I
                                            think see part of the hang
                                            up. I have not seen the
                                            scenario that you describe,
                                            where you trade a 3rd party
                                            token for a "local" token. I
                                            have seen where access
                                            tokens are federated
                                            directly at the PR.
                                            (Introspection lets you do
                                            some good things with that
                                            pattern.) 

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


--------------040307050704000703040408--

From phil.hunt@oracle.com  Fri May 31 09:58:42 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA721F9050 for ; Fri, 31 May 2013 09:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.58
X-Spam-Level: 
X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.819, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7uLc43niiAf for ; Fri, 31 May 2013 09:58:36 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 28F7821F8C4C for ; Fri, 31 May 2013 09:58:36 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VGwXgT019683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 16:58:33 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VGwYAX018596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 16:58:34 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VGwXl6008635; Fri, 31 May 2013 16:58:33 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 09:58:33 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <9F86FCC6-E737-4086-8821-81A94AEC4BE2@oracle.com> <54C61883-4A00-441E-B6DB-2B4156B969F4@ve7jtb.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8D123.3090103@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-80355891-7158-4F4D-900A-B70299353205
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 12:58:33 -0400
To: Justin Richer 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 16:58:42 -0000

--Apple-Mail-80355891-7158-4F4D-900A-B70299353205
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Yes. I specified the trivial solution to anonymous clients earlier.

Even simpler. You don't need an access token to create a new resource. You j=
ust need one to access one. That is just basic security config.=20

Phil

On 2013-05-31, at 12:34, Justin Richer  wrote:

> I agree that we are going in circles, since I just was going to bring up m=
y counter argument of "what about clients with no credentials?" again, which=
 *still* isn't addressed by what you suggest doing, below. I also believe th=
at getting rid of the Registration Access Token but using some other token m=
ethod would actually make the spec larger, though I'd be glad to review a co=
ncrete counter-proposal if you'd like to write one. And the fact that OIDC i=
s doing it this way, and considered but rejected the way that you're describ=
ing, should say something to the WG here about whether or not this is the ri=
ght choice. Rough consensus and running code, after all.
>=20
> Regardless, I agree to park this issue and leave the text as is. We'll mov=
e to the next draft in the last call process shortly, as I have a handful of=
 non-normative editorial changes that I need to make, thanks to feedback fro=
m a few folks.
>=20
> Again, thanks for your thorough review, Phil, and I look forward to future=
 feedback.
>=20
>  -- Justin
>=20
> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>> I disagree.=20
>>=20
>> There is absolutely no need for a registration access token.=20
>>=20
>> Get rid of it and just use access tokens as per 6749. If you can't follow=
 6749 and need new issuing methods, what are others to say regarding inventi=
ng new methods?
>>=20
>> I have not heard a good reason for the special process or one good enough=
 to warrant a new method for issuing an access token. Does the broader group=
 realize this is what the spec says?
>>=20
>> Yes, i heard a lot saying OIDC does it this way. But that is a political r=
eason, not a technical reason. Still, compatibility is always a strong objec=
tive.  Even so, oidc could keep using their method just fine. There is no ob=
ligation here to do the same.=20
>>=20
>> The only reason so far was expiry of client creds. Well, why not require t=
he client to update prior to expiry? It makes no sense to have another token=
 with longer expiry. B'sides, even expired the client can re-register from s=
cratch.=20
>>=20
>> Why force the client to persist multiple tokens and creds? That is far fa=
r too complex.=20
>>=20
>> Finally if you get rid of registration access token the spec size will dr=
op roughly in half IMO. This suggests simplicity to me.=20
>>=20
>> Apologies for my rant. Maybe we should park this for now. We are going in=
 circles.=20
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 11:25, Justin Richer  wrote:
>>=20
>>> Phil,
>>>=20
>>> We *can* keep it straight just fine, but I just need you to be clear abo=
ut which part you're objecting to because the answers are different. Please u=
se the terms as defined in the document so that we all know which component w=
e're talking about. I'm sure you'd agree than in specification work such as t=
his, precision of language and labels is key for communication between parti=
es. This is precisely why there's a Terminology section right up front, so t=
hat when I say "Registration Access Token" you can know that I mean a very s=
pecific thing, and when I say "Initial Registration Token" I mean a very dif=
ferent specific thing. So I'm asking you, please, use the defined terms so t=
hat we can avoid this unnecessary confusion.
>>>=20
>>> But anyway, what you're talking about below, "the token the client uses t=
o update is profile" *IS* the Registration Access Token. That's all that tha=
t token is used for. You're not asking for it to go away, you're asking for i=
t to come from the Token Endpoint instead of the response from the Registrat=
ion Endpoint. I don't see how the client *can* get it from the normal token p=
rocess without jumping through specialized hoops to make that happen. I've i=
mplemented the draft the way that it is right now, both client and server si=
de, and it works. Others have implemented it, too. We've done interop testin=
g, and it works. This is a proven pattern and from where I sit there is both=
 rough consensus and running code.
>>>=20
>>> I believe that I've already pointed out how the solutions you've propose=
d so far won't work in practice, for various reasons, many of which have alr=
eady been brought up and discussed previously. If you have another way for t=
he client to get its Registration Access Token, please propose it; but I hav=
en't seen anything yet that will fly.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 11:10 AM, Phil Hunt             wrote:
>>>> Justin,
>>>>=20
>>>> This is my primary objection! We can't keep it straight. Their should b=
e no such thing as a registrstion access token!  Just the token the client o=
btains to update its profile through the normal token request process.=20
>>>>=20
>>>> Phil
>>>>=20
>>>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>>>=20
>>>>> Which token are you referring to here?
>>>>>=20
>>>>> If it's the Initial Registration Token, then you could get that throug=
h the normal token server no problem. (The lifecycle writeups don't call thi=
s out explicitly but I would be willing to do so.) Or you could get it elsew=
here. Doesn't matter, just like it doesn't matter with any other OAuth2 prot=
ected resource.
>>>>>=20
>>>>> If it's the Registration Access Token, then having the token come from=
 the token endpoint would require a lot more work and complexity on behalf o=
f both of the client and server. Either you end up with public clients getti=
ng secrets they shouldn't need or with granting clients access to the client=
_credentials flow when they shouldn't actually have it. Plus it adds extra r=
ound trips which don't buy you anything.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>> The preference is to have the access token for registration issued by=
 the normal token server rather then by the registration endpoint.=20
>>>>>>=20
>>>>>> In the current draft it is obtained through a unique process and must=
 outlive the client.=20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P."  wrot=
e:
>>>>>>=20
>>>>>>> I don't understand any of the comments below -- it already *is* an O=
Auth2 protected resource without any special handling. Your access tokens ca=
n be short-lived, long-lived, federated, structured, random blobs ... totall=
y doesn't matter. They are access tokens being used to access a normal prote=
cted resource. Full stop.
>>>>>>>=20
>>>>>>> Anything else is out of scope. The lifecycle discussions at the begi=
nning are merely examples of some ways you *could* use it and are non-normat=
ive and non-exhaustive.
>>>>>>>=20
>>>>>>> You seem to be asking for something that's already in the draft.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>> Sent: Thursday, May 30, 2013 7:31 PM
>>>>>>> To: Richer, Justin P.
>>>>>>> Cc: John Bradley; oauth@ietf.org                               WG
>>>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-=
11.txt
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P."  wro=
te:
>>>>>>>=20
>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>=20
>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>>>>>> To: Richer, Justin P.
>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg=
-11.txt
>>>>>>>>=20
>>>>>>>> See below.
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>=20
>>>>>>>>> OK, I think see part of the hang                                  =
           up. I have not seen the scenario that you describe, where you tra=
de a 3rd party token for a "local" token. I have seen where access tokens ar=
e federated directly at the PR. (Introspection lets you do some good things w=
ith that pattern.)
>=20

--Apple-Mail-80355891-7158-4F4D-900A-B70299353205
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Yes. I specified the trivial solution to anonymous clients earlier.

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config. 

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:


  
    
  
  
    I agree that we are going in circles, since I just was going to
    bring up my counter argument of "what about clients with no
    credentials?" again, which *still* isn't addressed by what you
    suggest doing, below. I also believe that getting rid of the
    Registration Access Token but using some other token method would
    actually make the spec larger, though I'd be glad to review a
    concrete counter-proposal if you'd like to write one. And the fact
    that OIDC is doing it this way, and considered but rejected the way
    that you're describing, should say something to the WG here about
    whether or not this is the right choice. Rough consensus and running
    code, after all.

    

    Regardless, I agree to park this issue and leave the text as is.
    We'll move to the next draft in the last call process shortly, as I
    have a handful of non-normative editorial changes that I need to
    make, thanks to feedback from a few folks.

    

    Again, thanks for your thorough review, Phil, and I look forward to
    future feedback.

    

     -- Justin

    

    
On 05/31/2013 12:28 PM, Phil Hunt
      wrote:

    

    

      
      
I disagree. 

      


      

      
There is absolutely no need for a registration access token. 

      


      

      
Get rid of it and just use access tokens as per 6749. If you
        can't follow 6749 and need new issuing methods, what are others
        to say regarding inventing new methods?

      


      

      
I have not heard a good reason for the special process or one
        good enough to warrant a new method for issuing an access token.
        Does the broader group realize this is what the spec says?

      


      

      
Yes, i heard a lot saying OIDC does it this way. But that is
        a political reason, not a technical reason. Still, compatibility
        is always a strong objective.  Even so, oidc could keep using
        their method just fine. There is no obligation here to do the
        same. 

      


      

      
The only reason so far was expiry of client creds. Well, why
        not require the client to update prior to expiry? It makes no
        sense to have another token with longer expiry. B'sides, even
        expired the client can re-register from scratch. 

      


      

      
Why force the client to persist multiple tokens and creds?
        That is far far too complex. 

      


      

      
Finally if you get rid of registration access token the spec
        size will drop roughly in half IMO. This suggests simplicity to
        me. 

      


      

      
Apologies for my rant. Maybe we should park this for now. We
        are going in circles. 

        

        Phil

      


        On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

      

        
 Phil,

          

          We *can* keep it straight just fine, but I just need you to be
          clear about which part you're objecting to because the answers
          are different. Please use the terms as defined in the document
          so that we all know which component we're talking about. I'm
          sure you'd agree than in specification work such as this,
          precision of language and labels is key for communication
          between parties. This is precisely why there's a Terminology
          section right up front, so that when I say "Registration
          Access Token" you can know that I mean a very specific thing,
          and when I say "Initial Registration Token" I mean a very
          different specific thing. So I'm asking you, please, use the
          defined terms so that we can avoid this unnecessary confusion.

          

          But anyway, what you're talking about below, "the token the
          client uses to update is profile" *IS* the Registration Access
          Token. That's all that that token is used for. You're not
          asking for it to go away, you're asking for it to come from
          the Token Endpoint instead of the response from the
          Registration Endpoint. I don't see how the client *can* get it
          from the normal token process without jumping through
          specialized hoops to make that happen. I've implemented the
          draft the way that it is right now, both client and server
          side, and it works. Others have implemented it, too. We've
          done interop testing, and it works. This is a proven pattern
          and from where I sit there is both rough consensus and running
          code.

          

          I believe that I've already pointed out how the solutions
          you've proposed so far won't work in practice, for various
          reasons, many of which have already been brought up and
          discussed previously. If you have another way for the client
          to get its Registration Access Token, please propose it; but I
          haven't seen anything yet that will fly.

          

           -- Justin

          

          
On 05/31/2013 11:10 AM, Phil Hunt
            wrote:

          

          

            
Justin,

            


            

            
This is my primary objection! We can't keep it
              straight. Their should be no such thing as a registrstion
              access token!  Just the token the client obtains to update
              its profile through the normal token request process. 

              

              Phil

            


              On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

            

              
 Which token are you referring to here?

                

                If it's the Initial Registration Token, then you could
                get that through the normal token server no problem.
                (The lifecycle writeups don't call this out explicitly
                but I would be willing to do so.) Or you could get it
                elsewhere. Doesn't matter, just like it doesn't matter
                with any other OAuth2 protected resource.

                

                If it's the Registration Access Token, then having the
                token come from the token endpoint would require a lot
                more work and complexity on behalf of both of the client
                and server. Either you end up with public clients
                getting secrets they shouldn't need or with granting
                clients access to the client_credentials flow when they
                shouldn't actually have it. Plus it adds extra round
                trips which don't buy you anything.

                

                 -- Justin

                

                
On 05/31/2013 10:15 AM,
                  Phil Hunt wrote:

                

                

                  
The preference is to have the access token for
                    registration issued by the normal token server
                    rather then by the registration endpoint. 

                  


                  

                  
In the current draft it is obtained through a
                    unique process and must outlive the client. 

                  


                    Phil

                  


                    On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org>


                    wrote:

                    

                  

                  

                    

                      
I don't
                        understand any of the comments below -- it
                        already *is* an OAuth2 protected resource
                        without any special handling. Your access tokens
                        can be short-lived, long-lived, federated,
                        structured, random blobs ... totally doesn't
                        matter. They are access tokens being used to
                        access a normal protected resource. Full stop.

                        

                        Anything else is out of scope. The lifecycle
                        discussions at the beginning are merely examples
                        of some ways you *could* use it and are
                        non-normative and non-exhaustive.

                        

                        You seem to be asking for something that's
                        already in the draft.

                        

                         -- Justin

                        

                        

                          

                          
From:
                              Phil Hunt [phil.hunt@oracle.com]

                              Sent: Thursday, May 30, 2013 7:31
                              PM

                              To: Richer, Justin P.

                              Cc: John Bradley; oauth@ietf.org
                              WG

                              Subject: Re: [OAUTH-WG] review
                              comments on
                              draft-ietf-oauth-dyn-reg-11.txt

                            

                          

                          

                            


                              

                              Phil

                            


                              On 2013-05-30, at 16:11, "Richer, Justin
                              P." <jricher@mitre.org>

                              wrote:

                              

                            

                            

                            

                              

                                
Comments
                                    inline, marked by [JR].

                                  

                                  

                                    

                                    
From: Phil Hunt
                                        [phil.hunt@oracle.com]

                                        Sent: Thursday, May 30,
                                        2013 5:25 PM

                                        To: Richer, Justin P.

                                        Cc: John Bradley; oauth@ietf.org
                                        WG

                                        Subject: Re: [OAUTH-WG]
                                        review comments on
                                        draft-ietf-oauth-dyn-reg-11.txt

                                      

                                    

                                    
See below.

                                      
                                      

                                      

                                        
On 2013-05-30, at 2:09 PM,
                                          Justin Richer wrote:

                                        

                                        

                                          
OK, I
                                            think see part of the hang
                                            up. I have not seen the
                                            scenario that you describe,
                                            where you trade a 3rd party
                                            token for a "local" token. I
                                            have seen where access
                                            tokens are federated
                                            directly at the PR.
                                            (Introspection lets you do
                                            some good things with that
                                            pattern.) 

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  



--Apple-Mail-80355891-7158-4F4D-900A-B70299353205--

From jricher@mitre.org  Fri May 31 10:42:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F213F21F8E79 for ; Fri, 31 May 2013 10:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33xmZDfx4N3n for ; Fri, 31 May 2013 10:42:00 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFDA21F8E8C for ; Fri, 31 May 2013 10:41:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7CAD52650043; Fri, 31 May 2013 13:41:59 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 650792650040; Fri, 31 May 2013 13:41:59 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 13:41:58 -0400
Message-ID: <51A8E0BD.9090908@mitre.org>
Date: Fri, 31 May 2013 13:41:17 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050201050207000503030709"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 17:42:06 -0000

--------------050201050207000503030709
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

But the outstanding question is: how do you get the access token to 
access the created resource (IE: the Registration Access Token)? You 
can't use the client_credentials flow for a client with no credentials!

  -- Justin


On 05/31/2013 12:58 PM, Phil Hunt wrote:
> Yes. I specified the trivial solution to anonymous clients earlier.
>
> Even simpler. You don't need an access token to create a new resource. 
> You just need one to access one. That is just basic security config.
>
> Phil
>
> On 2013-05-31, at 12:34, Justin Richer  > wrote:
>
>> I agree that we are going in circles, since I just was going to bring 
>> up my counter argument of "what about clients with no credentials?" 
>> again, which *still* isn't addressed by what you suggest doing, 
>> below. I also believe that getting rid of the Registration Access 
>> Token but using some other token method would actually make the spec 
>> larger, though I'd be glad to review a concrete counter-proposal if 
>> you'd like to write one. And the fact that OIDC is doing it this way, 
>> and considered but rejected the way that you're describing, should 
>> say something to the WG here about whether or not this is the right 
>> choice. Rough consensus and running code, after all.
>>
>> Regardless, I agree to park this issue and leave the text as is. 
>> We'll move to the next draft in the last call process shortly, as I 
>> have a handful of non-normative editorial changes that I need to 
>> make, thanks to feedback from a few folks.
>>
>> Again, thanks for your thorough review, Phil, and I look forward to 
>> future feedback.
>>
>>  -- Justin
>>
>> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>> I disagree.
>>>
>>> There is absolutely no need for a registration access token.
>>>
>>> Get rid of it and just use access tokens as per 6749. If you can't 
>>> follow 6749 and need new issuing methods, what are others to say 
>>> regarding inventing new methods?
>>>
>>> I have not heard a good reason for the special process or one good 
>>> enough to warrant a new method for issuing an access token. Does the 
>>> broader group realize this is what the spec says?
>>>
>>> Yes, i heard a lot saying OIDC does it this way. But that is a 
>>> political reason, not a technical reason. Still, compatibility is 
>>> always a strong objective.  Even so, oidc could keep using their 
>>> method just fine. There is no obligation here to do the same.
>>>
>>> The only reason so far was expiry of client creds. Well, why not 
>>> require the client to update prior to expiry? It makes no sense to 
>>> have another token with longer expiry. B'sides, even expired the 
>>> client can re-register from scratch.
>>>
>>> Why force the client to persist multiple tokens and creds? That is 
>>> far far too complex.
>>>
>>> Finally if you get rid of registration access token the spec size 
>>> will drop roughly in half IMO. This suggests simplicity to me.
>>>
>>> Apologies for my rant. Maybe we should park this for now. We are 
>>> going in circles.
>>>
>>> Phil
>>>
>>> On 2013-05-31, at 11:25, Justin Richer >> > wrote:
>>>
>>>> Phil,
>>>>
>>>> We *can* keep it straight just fine, but I just need you to be 
>>>> clear about which part you're objecting to because the answers are 
>>>> different. Please use the terms as defined in the document so that 
>>>> we all know which component we're talking about. I'm sure you'd 
>>>> agree than in specification work such as this, precision of 
>>>> language and labels is key for communication between parties. This 
>>>> is precisely why there's a Terminology section right up front, so 
>>>> that when I say "Registration Access Token" you can know that I 
>>>> mean a very specific thing, and when I say "Initial Registration 
>>>> Token" I mean a very different specific thing. So I'm asking you, 
>>>> please, use the defined terms so that we can avoid this unnecessary 
>>>> confusion.
>>>>
>>>> But anyway, what you're talking about below, "the token the client 
>>>> uses to update is profile" *IS* the Registration Access Token. 
>>>> That's all that that token is used for. You're not asking for it to 
>>>> go away, you're asking for it to come from the Token Endpoint 
>>>> instead of the response from the Registration Endpoint. I don't see 
>>>> how the client *can* get it from the normal token process without 
>>>> jumping through specialized hoops to make that happen. I've 
>>>> implemented the draft the way that it is right now, both client and 
>>>> server side, and it works. Others have implemented it, too. We've 
>>>> done interop testing, and it works. This is a proven pattern and 
>>>> from where I sit there is both rough consensus and running code.
>>>>
>>>> I believe that I've already pointed out how the solutions you've 
>>>> proposed so far won't work in practice, for various reasons, many 
>>>> of which have already been brought up and discussed previously. If 
>>>> you have another way for the client to get its Registration Access 
>>>> Token, please propose it; but I haven't seen anything yet that will 
>>>> fly.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>>>> Justin,
>>>>>
>>>>> This is my primary objection! We can't keep it straight. Their 
>>>>> should be no such thing as a registrstion access token!  Just the 
>>>>> token the client obtains to update its profile through the normal 
>>>>> token request process.
>>>>>
>>>>> Phil
>>>>>
>>>>> On 2013-05-31, at 10:55, Justin Richer >>>> > wrote:
>>>>>
>>>>>> Which token are you referring to here?
>>>>>>
>>>>>> If it's the Initial Registration Token, then you could get that 
>>>>>> through the normal token server no problem. (The lifecycle 
>>>>>> writeups don't call this out explicitly but I would be willing to 
>>>>>> do so.) Or you could get it elsewhere. Doesn't matter, just like 
>>>>>> it doesn't matter with any other OAuth2 protected resource.
>>>>>>
>>>>>> If it's the Registration Access Token, then having the token come 
>>>>>> from the token endpoint would require a lot more work and 
>>>>>> complexity on behalf of both of the client and server. Either you 
>>>>>> end up with public clients getting secrets they shouldn't need or 
>>>>>> with granting clients access to the client_credentials flow when 
>>>>>> they shouldn't actually have it. Plus it adds extra round trips 
>>>>>> which don't buy you anything.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>>> The preference is to have the access token for registration 
>>>>>>> issued by the normal token server rather then by the 
>>>>>>> registration endpoint.
>>>>>>>
>>>>>>> In the current draft it is obtained through a unique process and 
>>>>>>> must outlive the client.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." >>>>>> > wrote:
>>>>>>>
>>>>>>>> I don't understand any of the comments below -- it already *is* 
>>>>>>>> an OAuth2 protected resource without any special handling. Your 
>>>>>>>> access tokens can be short-lived, long-lived, federated, 
>>>>>>>> structured, random blobs ... totally doesn't matter. They are 
>>>>>>>> access tokens being used to access a normal protected resource. 
>>>>>>>> Full stop.
>>>>>>>>
>>>>>>>> Anything else is out of scope. The lifecycle discussions at the 
>>>>>>>> beginning are merely examples of some ways you *could* use it 
>>>>>>>> and are non-normative and non-exhaustive.
>>>>>>>>
>>>>>>>> You seem to be asking for something that's already in the draft.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>>>> ]
>>>>>>>> *Sent:* Thursday, May 30, 2013 7:31 PM
>>>>>>>> *To:* Richer, Justin P.
>>>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>>>>> ]
>>>>>>>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>>>>>>>> *To:* Richer, Justin P.
>>>>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>
>>>>>>>>> See below.
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>>
>>>>>>>>>> OK, I think see part of the hang up. I have not seen the 
>>>>>>>>>> scenario that you describe, where you trade a 3rd party token 
>>>>>>>>>> for a "local" token. I have seen where access tokens are 
>>>>>>>>>> federated directly at the PR. (Introspection lets you do some 
>>>>>>>>>> good things with that pattern.)
>>


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


  
    
  
  
    But the outstanding question is: how do you get the access token to
    access the created resource (IE: the Registration Access Token)? You
    can't use the client_credentials flow for a client with no
    credentials!

    

     -- Justin

    

    

    
On 05/31/2013 12:58 PM, Phil Hunt
      wrote:

    

    

      
      
Yes. I specified the trivial solution to anonymous clients
        earlier.

      


      

      
Even simpler. You don't need an access token to create a new
        resource. You just need one to access one. That is just basic
        security config. 

      


        Phil

      


        On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

        
 I agree that we are going in circles, since I just was
          going to bring up my counter argument of "what about clients
          with no credentials?" again, which *still* isn't addressed by
          what you suggest doing, below. I also believe that getting rid
          of the Registration Access Token but using some other token
          method would actually make the spec larger, though I'd be glad
          to review a concrete counter-proposal if you'd like to write
          one. And the fact that OIDC is doing it this way, and
          considered but rejected the way that you're describing, should
          say something to the WG here about whether or not this is the
          right choice. Rough consensus and running code, after all.

          

          Regardless, I agree to park this issue and leave the text as
          is. We'll move to the next draft in the last call process
          shortly, as I have a handful of non-normative editorial
          changes that I need to make, thanks to feedback from a few
          folks.

          

          Again, thanks for your thorough review, Phil, and I look
          forward to future feedback.

          

           -- Justin

          

          
On 05/31/2013 12:28 PM, Phil Hunt
            wrote:

          

          

            
I disagree. 

            


            

            
There is absolutely no need for a registration access
              token. 

            


            

            
Get rid of it and just use access tokens as per 6749.
              If you can't follow 6749 and need new issuing methods,
              what are others to say regarding inventing new methods?

            


            

            
I have not heard a good reason for the special process
              or one good enough to warrant a new method for issuing an
              access token. Does the broader group realize this is what
              the spec says?

            


            

            
Yes, i heard a lot saying OIDC does it this way. But
              that is a political reason, not a technical reason. Still,
              compatibility is always a strong objective.  Even so, oidc
              could keep using their method just fine. There is no
              obligation here to do the same. 

            


            

            
The only reason so far was expiry of client creds.
              Well, why not require the client to update prior to
              expiry? It makes no sense to have another token with
              longer expiry. B'sides, even expired the client can
              re-register from scratch. 

            


            

            
Why force the client to persist multiple tokens and
              creds? That is far far too complex. 

            


            

            
Finally if you get rid of registration access token the
              spec size will drop roughly in half IMO. This suggests
              simplicity to me. 

            


            

            
Apologies for my rant. Maybe we should park this for
              now. We are going in circles. 

              

              Phil

            


              On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

            

              
 Phil,

                

                We *can* keep it straight just fine, but I just need you
                to be clear about which part you're objecting to because
                the answers are different. Please use the terms as
                defined in the document so that we all know which
                component we're talking about. I'm sure you'd agree than
                in specification work such as this, precision of
                language and labels is key for communication between
                parties. This is precisely why there's a Terminology
                section right up front, so that when I say "Registration
                Access Token" you can know that I mean a very specific
                thing, and when I say "Initial Registration Token" I
                mean a very different specific thing. So I'm asking you,
                please, use the defined terms so that we can avoid this
                unnecessary confusion.

                

                But anyway, what you're talking about below, "the token
                the client uses to update is profile" *IS* the
                Registration Access Token. That's all that that token is
                used for. You're not asking for it to go away, you're
                asking for it to come from the Token Endpoint instead of
                the response from the Registration Endpoint. I don't see
                how the client *can* get it from the normal token
                process without jumping through specialized hoops to
                make that happen. I've implemented the draft the way
                that it is right now, both client and server side, and
                it works. Others have implemented it, too. We've done
                interop testing, and it works. This is a proven pattern
                and from where I sit there is both rough consensus and
                running code.

                

                I believe that I've already pointed out how the
                solutions you've proposed so far won't work in practice,
                for various reasons, many of which have already been
                brought up and discussed previously. If you have another
                way for the client to get its Registration Access Token,
                please propose it; but I haven't seen anything yet that
                will fly.

                

                 -- Justin

                

                
On 05/31/2013 11:10 AM,
                  Phil Hunt wrote:

                

                

                  
Justin,

                  


                  

                  
This is my primary objection! We can't keep it
                    straight. Their should be no such thing as a
                    registrstion access token!  Just the token the
                    client obtains to update its profile through the
                    normal token request process. 

                    

                    Phil

                  


                    On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>


                    wrote:

                    

                  

                  

                  

                    
 Which token are you referring to here?

                      

                      If it's the Initial Registration Token, then you
                      could get that through the normal token server no
                      problem. (The lifecycle writeups don't call this
                      out explicitly but I would be willing to do so.)
                      Or you could get it elsewhere. Doesn't matter,
                      just like it doesn't matter with any other OAuth2
                      protected resource.

                      

                      If it's the Registration Access Token, then having
                      the token come from the token endpoint would
                      require a lot more work and complexity on behalf
                      of both of the client and server. Either you end
                      up with public clients getting secrets they
                      shouldn't need or with granting clients access to
                      the client_credentials flow when they shouldn't
                      actually have it. Plus it adds extra round trips
                      which don't buy you anything.

                      

                       -- Justin

                      

                      
On 05/31/2013 10:15
                        AM, Phil Hunt wrote:

                      

                      

                        
The preference is to have the access token
                          for registration issued by the normal token
                          server rather then by the registration
                          endpoint. 

                        


                        

                        
In the current draft it is obtained through
                          a unique process and must outlive the client. 

                        


                          Phil

                        


                          On 2013-05-30, at 19:47, "Richer, Justin P."
                          <jricher@mitre.org>



                          wrote:

                          

                        

                        

                          

                            
I
                              don't understand any of the comments below
                              -- it already *is* an OAuth2 protected
                              resource without any special handling.
                              Your access tokens can be short-lived,
                              long-lived, federated, structured, random
                              blobs ... totally doesn't matter. They are
                              access tokens being used to access a
                              normal protected resource. Full stop.

                              

                              Anything else is out of scope. The
                              lifecycle discussions at the beginning are
                              merely examples of some ways you *could*
                              use it and are non-normative and
                              non-exhaustive.

                              

                              You seem to be asking for something that's
                              already in the draft.

                              

                               -- Justin

                              

                              

                                

                                
From: Phil Hunt [phil.hunt@oracle.com]

                                    Sent: Thursday, May 30, 2013
                                    7:31 PM

                                    To: Richer, Justin P.

                                    Cc: John Bradley; oauth@ietf.org
                                    WG

                                    Subject: Re: [OAUTH-WG]
                                    review comments on
                                    draft-ietf-oauth-dyn-reg-11.txt

                                  

                                

                                

                                  


                                    

                                    Phil

                                  


                                    On 2013-05-30, at 16:11, "Richer,
                                    Justin P." <jricher@mitre.org>


                                    wrote:

                                    

                                  

                                  

                                  

                                    

                                      
Comments
                                          inline, marked by [JR].

                                        

                                        

                                          

                                          
From:
                                              Phil Hunt [phil.hunt@oracle.com]

                                              Sent: Thursday, May
                                              30, 2013 5:25 PM

                                              To: Richer, Justin
                                              P.

                                              Cc: John Bradley; oauth@ietf.org
                                              WG

                                              Subject: Re:
                                              [OAUTH-WG] review comments
                                              on
                                              draft-ietf-oauth-dyn-reg-11.txt

                                            

                                          

                                          
See below.

                                            
                                            

                                            

                                              
On 2013-05-30, at
                                                2:09 PM, Justin Richer
                                                wrote:

                                              

                                              

                                                
OK,
                                                  I think see part of
                                                  the hang up. I have
                                                  not seen the scenario
                                                  that you describe,
                                                  where you trade a 3rd
                                                  party token for a
                                                  "local" token. I have
                                                  seen where access
                                                  tokens are federated
                                                  directly at the PR.
                                                  (Introspection lets
                                                  you do some good
                                                  things with that
                                                  pattern.) 

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

          

        

      

    

    

  


--------------050201050207000503030709--

From phil.hunt@oracle.com  Fri May 31 10:57:00 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A09121F8E8C for ; Fri, 31 May 2013 10:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.091
X-Spam-Level: 
X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=1.511,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DQcyjxplUDI for ; Fri, 31 May 2013 10:56:54 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA29821F90CD for ; Fri, 31 May 2013 10:56:53 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VHuouG020080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 17:56:51 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VHuplS026762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 17:56:51 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VHuo2c026311; Fri, 31 May 2013 17:56:50 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 10:56:49 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2674C9F9-0C49-4EC3-A69D-20AAC35E8AB8@oracle.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8E0BD.9090908@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-F3015264-5E23-45E8-9AB2-060F9F04230F
Content-Transfer-Encoding: 7bit
Message-Id: <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 13:56:49 -0400
To: Justin Richer 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 17:57:00 -0000

--Apple-Mail-F3015264-5E23-45E8-9AB2-060F9F04230F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Well the only client that wouldn't have a credential is an implicit client. A=
n implicit client is transient and so would never update.=20

Besides, as i have stated, implicit clients should not use dyn reg.=20

Phil

On 2013-05-31, at 13:41, Justin Richer  wrote:

> But the outstanding question is: how do you get the access token to access=
 the created resource (IE: the Registration Access Token)? You can't use the=
 client_credentials flow for a client with no credentials!
>=20
>  -- Justin
>=20
>=20
> On 05/31/2013 12:58 PM, Phil Hunt wrote:
>> Yes. I specified the trivial solution to anonymous clients earlier.
>>=20
>> Even simpler. You don't need an access token to create a new resource. Yo=
u just need one to access one. That is just basic security config.=20
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 12:34, Justin Richer  wrote:
>>=20
>>> I agree that we are going in circles, since I just was going to bring up=
 my counter argument of "what about clients with no credentials?" again, whi=
ch *still* isn't addressed by what you suggest doing, below. I also believe t=
hat getting rid of the Registration Access Token but using some other token m=
ethod would actually make the spec larger, though I'd be glad to review a co=
ncrete counter-proposal if you'd like to write one. And the fact that OIDC i=
s doing it this way, and considered but rejected the way that you're describ=
ing, should say something to the WG here about whether or not this is the ri=
ght choice. Rough consensus and running code, after all.
>>>=20
>>> Regardless, I agree to park this issue and leave the text as is. We'll m=
ove to the next draft in the last call process shortly, as I have a handful o=
f non-normative editorial changes that I need to make, thanks to feedback fr=
om a few folks.
>>>=20
>>> Again, thanks for your thorough review, Phil, and I look forward to futu=
re feedback.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 12:28 PM, Phil Hunt             wrote:
>>>> I disagree.=20
>>>>=20
>>>> There is absolutely no need for a registration access token.=20
>>>>=20
>>>> Get rid of it and just use access tokens as per 6749. If you can't foll=
ow 6749 and need new issuing methods, what are others to say regarding inven=
ting new methods?
>>>>=20
>>>> I have not heard a good reason for the special process or one good enou=
gh to warrant a new method for issuing an access token. Does the broader gro=
up realize this is what the spec says?
>>>>=20
>>>> Yes, i heard a lot saying OIDC does it this way. But that is a politica=
l reason, not a technical reason. Still, compatibility is always a strong ob=
jective.  Even so, oidc could keep using their method just fine. There is no=
 obligation here to do the same.=20
>>>>=20
>>>> The only reason so far was expiry of client creds. Well, why not requir=
e the client to update prior to               expiry? It makes no sense to h=
ave another token with longer expiry. B'sides, even expired the client can r=
e-register from scratch.=20
>>>>=20
>>>> Why force the client to persist multiple tokens and creds? That is far f=
ar too complex.=20
>>>>=20
>>>> Finally if you get rid of registration access token the spec size will d=
rop roughly in half IMO. This suggests simplicity to me.=20
>>>>=20
>>>> Apologies for my rant. Maybe we should park this for now. We are going i=
n circles.=20
>>>>=20
>>>> Phil
>>>>=20
>>>> On 2013-05-31, at 11:25, Justin Richer  wrote:
>>>>=20
>>>>> Phil,
>>>>>=20
>>>>> We *can* keep it straight just fine, but I just need you to be clear a=
bout which part you're objecting to because the answers are different. Pleas=
e use the terms as defined in the document so that we all know which compone=
nt we're talking about. I'm sure you'd agree than                 in specifi=
cation work such as this, precision of language and labels is key for commun=
ication between parties. This is precisely why there's a Terminology section=
 right up front, so that when I say "Registration Access Token" you can know=
 that I mean a very specific thing, and when I say "Initial Registration Tok=
en" I mean a very different specific thing. So I'm asking you, please, use t=
he defined terms so that we can avoid this unnecessary confusion.
>>>>>=20
>>>>> But anyway, what you're talking about below, "the token the client use=
s to update is profile" *IS* the                 Registration Access Token. T=
hat's all that that token is used for. You're not asking for it to go away, y=
ou're asking for it to come from the Token Endpoint instead of the response f=
rom the Registration Endpoint. I don't see                 how the client *c=
an* get it from the normal token process without jumping through specialized=
 hoops to make that happen. I've implemented the draft the way that it is ri=
ght now, both client and server side, and it works. Others have implemented i=
t, too. We've done interop testing, and it works. This is a proven pattern  =
               and from where I sit there is both rough consensus and runnin=
g code.
>>>>>=20
>>>>> I believe that I've already pointed out how the solutions you've propo=
sed so far won't work in practice, for various reasons, many of which have a=
lready been brought up and discussed previously. If you have another way for=
 the client to get its Registration Access Token, please propose it; but I h=
aven't seen anything yet that will fly.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>>>>> Justin,
>>>>>>=20
>>>>>> This is my primary objection! We can't keep it straight. Their should=
 be no such thing as a registrstion access token!  Just the token the client=
 obtains to update its profile through the normal token request process.=20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>>>>>=20
>>>>>>> Which token are you referring to here?
>>>>>>>=20
>>>>>>> If it's the Initial Registration Token, then you could get that thro=
ugh the normal token server no problem. (The lifecycle writeups don't call t=
his out explicitly but I would be willing to do so.) Or you could get it els=
ewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 pr=
otected resource.
>>>>>>>=20
>>>>>>> If it's the Registration Access Token, then having the token come fr=
om the token endpoint would require a lot more work and complexity on behalf=
 of both of the client and server. Either you end up with public clients get=
ting secrets they shouldn't need or with granting clients access to the clie=
nt_credentials flow when they shouldn't actually have it. Plus it adds extra=
 round trips which don't buy you anything.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>>>> The preference is to have the access token for registration issued b=
y the normal token server rather then by the registration endpoint.=20
>>>>>>>>=20
>>>>>>>> In the current draft it is obtained through a unique process and mu=
st outlive the client.=20
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P."  wr=
ote:
>>>>>>>>=20
>>>>>>>>> I don't understand any of the comments below -- it already *is* an=
 OAuth2 protected resource without any special handling. Your access tokens c=
an be short-lived, long-lived, federated, structured, random blobs ... total=
ly doesn't matter. They are access tokens being used to access a normal prot=
ected resource. Full stop.
>>>>>>>>>=20
>>>>>>>>> Anything else is out of scope. The lifecycle discussions at the be=
ginning are merely examples of some ways you *could* use it and are non-norm=
ative and non-exhaustive.
>>>>>>>>>=20
>>>>>>>>> You seem to be asking for something that's already in the draft.
>>>>>>>>>=20
>>>>>>>>>  -- Justin
>>>>>>>>>=20
>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>> Sent: Thursday, May 30, 2013                                     7=
:31 PM
>>>>>>>>> To: Richer, Justin P.
>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-re=
g-11.txt
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P."  w=
rote:
>>>>>>>>>=20
>>>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>>>=20
>>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>>>>>>>> To: Richer, Justin P.
>>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-r=
eg-11.txt
>>>>>>>>>>=20
>>>>>>>>>> See below.
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com
>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>>>=20
>>>>>>>>>>> OK, I think see part of the hang up. I have not seen the scenari=
o that you describe, where you trade a 3rd party token for a "local" token. I=
 have seen where access tokens are federated directly at the PR. (Introspect=
ion lets                                                   you do some good t=
hings with that pattern.)
>=20

--Apple-Mail-F3015264-5E23-45E8-9AB2-060F9F04230F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update. 

Besides, as i have stated, implicit clients should not use dyn reg. 

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:


  
    
  
  
    But the outstanding question is: how do you get the access token to
    access the created resource (IE: the Registration Access Token)? You
    can't use the client_credentials flow for a client with no
    credentials!

    

     -- Justin

    

    

    
On 05/31/2013 12:58 PM, Phil Hunt
      wrote:

    

    

      
      
Yes. I specified the trivial solution to anonymous clients
        earlier.

      


      

      
Even simpler. You don't need an access token to create a new
        resource. You just need one to access one. That is just basic
        security config. 

      


        Phil

      


        On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

        
 I agree that we are going in circles, since I just was
          going to bring up my counter argument of "what about clients
          with no credentials?" again, which *still* isn't addressed by
          what you suggest doing, below. I also believe that getting rid
          of the Registration Access Token but using some other token
          method would actually make the spec larger, though I'd be glad
          to review a concrete counter-proposal if you'd like to write
          one. And the fact that OIDC is doing it this way, and
          considered but rejected the way that you're describing, should
          say something to the WG here about whether or not this is the
          right choice. Rough consensus and running code, after all.

          

          Regardless, I agree to park this issue and leave the text as
          is. We'll move to the next draft in the last call process
          shortly, as I have a handful of non-normative editorial
          changes that I need to make, thanks to feedback from a few
          folks.

          

          Again, thanks for your thorough review, Phil, and I look
          forward to future feedback.

          

           -- Justin

          

          
On 05/31/2013 12:28 PM, Phil Hunt
            wrote:

          

          

            
I disagree. 

            


            

            
There is absolutely no need for a registration access
              token. 

            


            

            
Get rid of it and just use access tokens as per 6749.
              If you can't follow 6749 and need new issuing methods,
              what are others to say regarding inventing new methods?

            


            

            
I have not heard a good reason for the special process
              or one good enough to warrant a new method for issuing an
              access token. Does the broader group realize this is what
              the spec says?

            


            

            
Yes, i heard a lot saying OIDC does it this way. But
              that is a political reason, not a technical reason. Still,
              compatibility is always a strong objective.  Even so, oidc
              could keep using their method just fine. There is no
              obligation here to do the same. 

            


            

            
The only reason so far was expiry of client creds.
              Well, why not require the client to update prior to
              expiry? It makes no sense to have another token with
              longer expiry. B'sides, even expired the client can
              re-register from scratch. 

            


            

            
Why force the client to persist multiple tokens and
              creds? That is far far too complex. 

            


            

            
Finally if you get rid of registration access token the
              spec size will drop roughly in half IMO. This suggests
              simplicity to me. 

            


            

            
Apologies for my rant. Maybe we should park this for
              now. We are going in circles. 

              

              Phil

            


              On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

            

              
 Phil,

                

                We *can* keep it straight just fine, but I just need you
                to be clear about which part you're objecting to because
                the answers are different. Please use the terms as
                defined in the document so that we all know which
                component we're talking about. I'm sure you'd agree than
                in specification work such as this, precision of
                language and labels is key for communication between
                parties. This is precisely why there's a Terminology
                section right up front, so that when I say "Registration
                Access Token" you can know that I mean a very specific
                thing, and when I say "Initial Registration Token" I
                mean a very different specific thing. So I'm asking you,
                please, use the defined terms so that we can avoid this
                unnecessary confusion.

                

                But anyway, what you're talking about below, "the token
                the client uses to update is profile" *IS* the
                Registration Access Token. That's all that that token is
                used for. You're not asking for it to go away, you're
                asking for it to come from the Token Endpoint instead of
                the response from the Registration Endpoint. I don't see
                how the client *can* get it from the normal token
                process without jumping through specialized hoops to
                make that happen. I've implemented the draft the way
                that it is right now, both client and server side, and
                it works. Others have implemented it, too. We've done
                interop testing, and it works. This is a proven pattern
                and from where I sit there is both rough consensus and
                running code.

                

                I believe that I've already pointed out how the
                solutions you've proposed so far won't work in practice,
                for various reasons, many of which have already been
                brought up and discussed previously. If you have another
                way for the client to get its Registration Access Token,
                please propose it; but I haven't seen anything yet that
                will fly.

                

                 -- Justin

                

                
On 05/31/2013 11:10 AM,
                  Phil Hunt wrote:

                

                

                  
Justin,

                  


                  

                  
This is my primary objection! We can't keep it
                    straight. Their should be no such thing as a
                    registrstion access token!  Just the token the
                    client obtains to update its profile through the
                    normal token request process. 

                    

                    Phil

                  


                    On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>


                    wrote:

                    

                  

                  

                  

                    
 Which token are you referring to here?

                      

                      If it's the Initial Registration Token, then you
                      could get that through the normal token server no
                      problem. (The lifecycle writeups don't call this
                      out explicitly but I would be willing to do so.)
                      Or you could get it elsewhere. Doesn't matter,
                      just like it doesn't matter with any other OAuth2
                      protected resource.

                      

                      If it's the Registration Access Token, then having
                      the token come from the token endpoint would
                      require a lot more work and complexity on behalf
                      of both of the client and server. Either you end
                      up with public clients getting secrets they
                      shouldn't need or with granting clients access to
                      the client_credentials flow when they shouldn't
                      actually have it. Plus it adds extra round trips
                      which don't buy you anything.

                      

                       -- Justin

                      

                      
On 05/31/2013 10:15
                        AM, Phil Hunt wrote:

                      

                      

                        
The preference is to have the access token
                          for registration issued by the normal token
                          server rather then by the registration
                          endpoint. 

                        


                        

                        
In the current draft it is obtained through
                          a unique process and must outlive the client. 

                        


                          Phil

                        


                          On 2013-05-30, at 19:47, "Richer, Justin P."
                          <jricher@mitre.org>



                          wrote:

                          

                        

                        

                          

                            
I
                              don't understand any of the comments below
                              -- it already *is* an OAuth2 protected
                              resource without any special handling.
                              Your access tokens can be short-lived,
                              long-lived, federated, structured, random
                              blobs ... totally doesn't matter. They are
                              access tokens being used to access a
                              normal protected resource. Full stop.

                              

                              Anything else is out of scope. The
                              lifecycle discussions at the beginning are
                              merely examples of some ways you *could*
                              use it and are non-normative and
                              non-exhaustive.

                              

                              You seem to be asking for something that's
                              already in the draft.

                              

                               -- Justin

                              

                              

                                

                                
From: Phil Hunt [phil.hunt@oracle.com]

                                    Sent: Thursday, May 30, 2013
                                    7:31 PM

                                    To: Richer, Justin P.

                                    Cc: John Bradley; oauth@ietf.org
                                    WG

                                    Subject: Re: [OAUTH-WG]
                                    review comments on
                                    draft-ietf-oauth-dyn-reg-11.txt

                                  

                                

                                

                                  


                                    

                                    Phil

                                  


                                    On 2013-05-30, at 16:11, "Richer,
                                    Justin P." <jricher@mitre.org>


                                    wrote:

                                    

                                  

                                  

                                  

                                    

                                      
Comments
                                          inline, marked by [JR].

                                        

                                        

                                          

                                          
From:
                                              Phil Hunt [phil.hunt@oracle.com]

                                              Sent: Thursday, May
                                              30, 2013 5:25 PM

                                              To: Richer, Justin
                                              P.

                                              Cc: John Bradley; oauth@ietf.org
                                              WG

                                              Subject: Re:
                                              [OAUTH-WG] review comments
                                              on
                                              draft-ietf-oauth-dyn-reg-11.txt

                                            

                                          

                                          
See below.

                                            
                                            

                                            

                                              
On 2013-05-30, at
                                                2:09 PM, Justin Richer
                                                wrote:

                                              

                                              

                                                
OK,
                                                  I think see part of
                                                  the hang up. I have
                                                  not seen the scenario
                                                  that you describe,
                                                  where you trade a 3rd
                                                  party token for a
                                                  "local" token. I have
                                                  seen where access
                                                  tokens are federated
                                                  directly at the PR.
                                                  (Introspection lets
                                                  you do some good
                                                  things with that
                                                  pattern.) 

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

          

        

      

    

    

  



--Apple-Mail-F3015264-5E23-45E8-9AB2-060F9F04230F--

From jricher@mitre.org  Fri May 31 10:58:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1237721F8E8C for ; Fri, 31 May 2013 10:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level: 
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5KGpWBc42DE for ; Fri, 31 May 2013 10:58:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0C89321F8DE4 for ; Fri, 31 May 2013 10:58:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A47402650068; Fri, 31 May 2013 13:58:52 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 74AF02650046; Fri, 31 May 2013 13:58:52 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 13:58:52 -0400
Message-ID: <51A8E4B2.1030309@mitre.org>
Date: Fri, 31 May 2013 13:58:10 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com>
In-Reply-To: <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com>
Content-Type: multipart/alternative; boundary="------------060403020305070004060207"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 17:58:59 -0000

--------------060403020305070004060207
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

I'm not willing to write out an entire class of clients from this spec, 
especially when we have stated use cases for them doing dynamic 
registration.

I'm sorry, but your proposed solution will simply not work.

  -- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:
> Well the only client that wouldn't have a credential is an implicit 
> client. An implicit client is transient and so would never update.
>
> Besides, as i have stated, implicit clients should not use dyn reg.
>
> Phil
>
> On 2013-05-31, at 13:41, Justin Richer  > wrote:
>
>> But the outstanding question is: how do you get the access token to 
>> access the created resource (IE: the Registration Access Token)? You 
>> can't use the client_credentials flow for a client with no credentials!
>>
>>  -- Justin
>>
>>
>> On 05/31/2013 12:58 PM, Phil Hunt wrote:
>>> Yes. I specified the trivial solution to anonymous clients earlier.
>>>
>>> Even simpler. You don't need an access token to create a new 
>>> resource. You just need one to access one. That is just basic 
>>> security config.
>>>
>>> Phil
>>>
>>> On 2013-05-31, at 12:34, Justin Richer >> > wrote:
>>>
>>>> I agree that we are going in circles, since I just was going to 
>>>> bring up my counter argument of "what about clients with no 
>>>> credentials?" again, which *still* isn't addressed by what you 
>>>> suggest doing, below. I also believe that getting rid of the 
>>>> Registration Access Token but using some other token method would 
>>>> actually make the spec larger, though I'd be glad to review a 
>>>> concrete counter-proposal if you'd like to write one. And the fact 
>>>> that OIDC is doing it this way, and considered but rejected the way 
>>>> that you're describing, should say something to the WG here about 
>>>> whether or not this is the right choice. Rough consensus and 
>>>> running code, after all.
>>>>
>>>> Regardless, I agree to park this issue and leave the text as is. 
>>>> We'll move to the next draft in the last call process shortly, as I 
>>>> have a handful of non-normative editorial changes that I need to 
>>>> make, thanks to feedback from a few folks.
>>>>
>>>> Again, thanks for your thorough review, Phil, and I look forward to 
>>>> future feedback.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>>>> I disagree.
>>>>>
>>>>> There is absolutely no need for a registration access token.
>>>>>
>>>>> Get rid of it and just use access tokens as per 6749. If you can't 
>>>>> follow 6749 and need new issuing methods, what are others to say 
>>>>> regarding inventing new methods?
>>>>>
>>>>> I have not heard a good reason for the special process or one good 
>>>>> enough to warrant a new method for issuing an access token. Does 
>>>>> the broader group realize this is what the spec says?
>>>>>
>>>>> Yes, i heard a lot saying OIDC does it this way. But that is a 
>>>>> political reason, not a technical reason. Still, compatibility is 
>>>>> always a strong objective.  Even so, oidc could keep using their 
>>>>> method just fine. There is no obligation here to do the same.
>>>>>
>>>>> The only reason so far was expiry of client creds. Well, why not 
>>>>> require the client to update prior to expiry? It makes no sense to 
>>>>> have another token with longer expiry. B'sides, even expired the 
>>>>> client can re-register from scratch.
>>>>>
>>>>> Why force the client to persist multiple tokens and creds? That is 
>>>>> far far too complex.
>>>>>
>>>>> Finally if you get rid of registration access token the spec size 
>>>>> will drop roughly in half IMO. This suggests simplicity to me.
>>>>>
>>>>> Apologies for my rant. Maybe we should park this for now. We are 
>>>>> going in circles.
>>>>>
>>>>> Phil
>>>>>
>>>>> On 2013-05-31, at 11:25, Justin Richer >>>> > wrote:
>>>>>
>>>>>> Phil,
>>>>>>
>>>>>> We *can* keep it straight just fine, but I just need you to be 
>>>>>> clear about which part you're objecting to because the answers 
>>>>>> are different. Please use the terms as defined in the document so 
>>>>>> that we all know which component we're talking about. I'm sure 
>>>>>> you'd agree than in specification work such as this, precision of 
>>>>>> language and labels is key for communication between parties. 
>>>>>> This is precisely why there's a Terminology section right up 
>>>>>> front, so that when I say "Registration Access Token" you can 
>>>>>> know that I mean a very specific thing, and when I say "Initial 
>>>>>> Registration Token" I mean a very different specific thing. So 
>>>>>> I'm asking you, please, use the defined terms so that we can 
>>>>>> avoid this unnecessary confusion.
>>>>>>
>>>>>> But anyway, what you're talking about below, "the token the 
>>>>>> client uses to update is profile" *IS* the Registration Access 
>>>>>> Token. That's all that that token is used for. You're not asking 
>>>>>> for it to go away, you're asking for it to come from the Token 
>>>>>> Endpoint instead of the response from the Registration Endpoint. 
>>>>>> I don't see how the client *can* get it from the normal token 
>>>>>> process without jumping through specialized hoops to make that 
>>>>>> happen. I've implemented the draft the way that it is right now, 
>>>>>> both client and server side, and it works. Others have 
>>>>>> implemented it, too. We've done interop testing, and it works. 
>>>>>> This is a proven pattern and from where I sit there is both rough 
>>>>>> consensus and running code.
>>>>>>
>>>>>> I believe that I've already pointed out how the solutions you've 
>>>>>> proposed so far won't work in practice, for various reasons, many 
>>>>>> of which have already been brought up and discussed previously. 
>>>>>> If you have another way for the client to get its Registration 
>>>>>> Access Token, please propose it; but I haven't seen anything yet 
>>>>>> that will fly.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>>>>>> Justin,
>>>>>>>
>>>>>>> This is my primary objection! We can't keep it straight. Their 
>>>>>>> should be no such thing as a registrstion access token!  Just 
>>>>>>> the token the client obtains to update its profile through the 
>>>>>>> normal token request process.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On 2013-05-31, at 10:55, Justin Richer >>>>>> > wrote:
>>>>>>>
>>>>>>>> Which token are you referring to here?
>>>>>>>>
>>>>>>>> If it's the Initial Registration Token, then you could get that 
>>>>>>>> through the normal token server no problem. (The lifecycle 
>>>>>>>> writeups don't call this out explicitly but I would be willing 
>>>>>>>> to do so.) Or you could get it elsewhere. Doesn't matter, just 
>>>>>>>> like it doesn't matter with any other OAuth2 protected resource.
>>>>>>>>
>>>>>>>> If it's the Registration Access Token, then having the token 
>>>>>>>> come from the token endpoint would require a lot more work and 
>>>>>>>> complexity on behalf of both of the client and server. Either 
>>>>>>>> you end up with public clients getting secrets they shouldn't 
>>>>>>>> need or with granting clients access to the client_credentials 
>>>>>>>> flow when they shouldn't actually have it. Plus it adds extra 
>>>>>>>> round trips which don't buy you anything.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>>>>> The preference is to have the access token for registration 
>>>>>>>>> issued by the normal token server rather then by the 
>>>>>>>>> registration endpoint.
>>>>>>>>>
>>>>>>>>> In the current draft it is obtained through a unique process 
>>>>>>>>> and must outlive the client.
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." 
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I don't understand any of the comments below -- it already 
>>>>>>>>>> *is* an OAuth2 protected resource without any special 
>>>>>>>>>> handling. Your access tokens can be short-lived, long-lived, 
>>>>>>>>>> federated, structured, random blobs ... totally doesn't 
>>>>>>>>>> matter. They are access tokens being used to access a normal 
>>>>>>>>>> protected resource. Full stop.
>>>>>>>>>>
>>>>>>>>>> Anything else is out of scope. The lifecycle discussions at 
>>>>>>>>>> the beginning are merely examples of some ways you *could* 
>>>>>>>>>> use it and are non-normative and non-exhaustive.
>>>>>>>>>>
>>>>>>>>>> You seem to be asking for something that's already in the draft.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>>>>>> ]
>>>>>>>>>> *Sent:* Thursday, May 30, 2013 7:31 PM
>>>>>>>>>> *To:* Richer, Justin P.
>>>>>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." 
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>> *From:* Phil Hunt [phil.hunt@oracle.com 
>>>>>>>>>>> ]
>>>>>>>>>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>>>>>>>>>> *To:* Richer, Justin P.
>>>>>>>>>>> *Cc:* John Bradley; oauth@ietf.org  WG
>>>>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>>
>>>>>>>>>>> See below.
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> @independentid
>>>>>>>>>>> www.independentid.com 
>>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>>>>
>>>>>>>>>>>> OK, I think see part of the hang up. I have not seen the 
>>>>>>>>>>>> scenario that you describe, where you trade a 3rd party 
>>>>>>>>>>>> token for a "local" token. I have seen where access tokens 
>>>>>>>>>>>> are federated directly at the PR. (Introspection lets you 
>>>>>>>>>>>> do some good things with that pattern.)
>>>>
>>


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


  
    
  
  
    I'm not willing to write out an entire class of clients from this
    spec, especially when we have stated use cases for them doing
    dynamic registration.

    

    I'm sorry, but your proposed solution will simply not work.

    

     -- Justin

    

    
On 05/31/2013 01:56 PM, Phil Hunt
      wrote:

    

    

      
      
Well the only client that wouldn't have a credential is an
        implicit client. An implicit client is transient and so would
        never update. 

        

        Besides, as i have stated, implicit clients should not use dyn
        reg. 

      


        Phil

      


        On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

        
 But the outstanding question is: how do you get the access
          token to access the created resource (IE: the Registration
          Access Token)? You can't use the client_credentials flow for a
          client with no credentials!

          

           -- Justin

          

          

          
On 05/31/2013 12:58 PM, Phil Hunt
            wrote:

          

          

            
Yes. I specified the trivial solution to anonymous
              clients earlier.

            


            

            
Even simpler. You don't need an access token to create
              a new resource. You just need one to access one. That is
              just basic security config. 

            


              Phil

            


              On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

              
 I agree that we are going in circles, since I just
                was going to bring up my counter argument of "what about
                clients with no credentials?" again, which *still* isn't
                addressed by what you suggest doing, below. I also
                believe that getting rid of the Registration Access
                Token but using some other token method would actually
                make the spec larger, though I'd be glad to review a
                concrete counter-proposal if you'd like to write one.
                And the fact that OIDC is doing it this way, and
                considered but rejected the way that you're describing,
                should say something to the WG here about whether or not
                this is the right choice. Rough consensus and running
                code, after all.

                

                Regardless, I agree to park this issue and leave the
                text as is. We'll move to the next draft in the last
                call process shortly, as I have a handful of
                non-normative editorial changes that I need to make,
                thanks to feedback from a few folks.

                

                Again, thanks for your thorough review, Phil, and I look
                forward to future feedback.

                

                 -- Justin

                

                
On 05/31/2013 12:28 PM,
                  Phil Hunt wrote:

                

                

                  
I disagree. 

                  


                  

                  
There is absolutely no need for a registration
                    access token. 

                  


                  

                  
Get rid of it and just use access tokens as per
                    6749. If you can't follow 6749 and need new issuing
                    methods, what are others to say regarding inventing
                    new methods?

                  


                  

                  
I have not heard a good reason for the special
                    process or one good enough to warrant a new method
                    for issuing an access token. Does the broader group
                    realize this is what the spec says?

                  


                  

                  
Yes, i heard a lot saying OIDC does it this way.
                    But that is a political reason, not a technical
                    reason. Still, compatibility is always a strong
                    objective.  Even so, oidc could keep using their
                    method just fine. There is no obligation here to do
                    the same. 

                  


                  

                  
The only reason so far was expiry of client
                    creds. Well, why not require the client to update
                    prior to expiry? It makes no sense to have another
                    token with longer expiry. B'sides, even expired the
                    client can re-register from scratch. 

                  


                  

                  
Why force the client to persist multiple tokens
                    and creds? That is far far too complex. 

                  


                  

                  
Finally if you get rid of registration access
                    token the spec size will drop roughly in half IMO.
                    This suggests simplicity to me. 

                  


                  

                  
Apologies for my rant. Maybe we should park this
                    for now. We are going in circles. 

                    

                    Phil

                  


                    On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>


                    wrote:

                    

                  

                  

                  

                    
 Phil,

                      

                      We *can* keep it straight just fine, but I just
                      need you to be clear about which part you're
                      objecting to because the answers are different.
                      Please use the terms as defined in the document so
                      that we all know which component we're talking
                      about. I'm sure you'd agree than in specification
                      work such as this, precision of language and
                      labels is key for communication between parties.
                      This is precisely why there's a Terminology
                      section right up front, so that when I say
                      "Registration Access Token" you can know that I
                      mean a very specific thing, and when I say
                      "Initial Registration Token" I mean a very
                      different specific thing. So I'm asking you,
                      please, use the defined terms so that we can avoid
                      this unnecessary confusion.

                      

                      But anyway, what you're talking about below, "the
                      token the client uses to update is profile" *IS*
                      the Registration Access Token. That's all that
                      that token is used for. You're not asking for it
                      to go away, you're asking for it to come from the
                      Token Endpoint instead of the response from the
                      Registration Endpoint. I don't see how the client
                      *can* get it from the normal token process without
                      jumping through specialized hoops to make that
                      happen. I've implemented the draft the way that it
                      is right now, both client and server side, and it
                      works. Others have implemented it, too. We've done
                      interop testing, and it works. This is a proven
                      pattern and from where I sit there is both rough
                      consensus and running code.

                      

                      I believe that I've already pointed out how the
                      solutions you've proposed so far won't work in
                      practice, for various reasons, many of which have
                      already been brought up and discussed previously.
                      If you have another way for the client to get its
                      Registration Access Token, please propose it; but
                      I haven't seen anything yet that will fly.

                      

                       -- Justin

                      

                      
On 05/31/2013 11:10
                        AM, Phil Hunt wrote:

                      

                      

                        
Justin,

                        


                        

                        
This is my primary objection! We can't keep
                          it straight. Their should be no such thing as
                          a registrstion access token!  Just the token
                          the client obtains to update its profile
                          through the normal token request process. 

                          

                          Phil

                        


                          On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>



                          wrote:

                          

                        

                        

                        

                          
 Which token are you referring to here?

                            

                            If it's the Initial Registration Token, then
                            you could get that through the normal token
                            server no problem. (The lifecycle writeups
                            don't call this out explicitly but I would
                            be willing to do so.) Or you could get it
                            elsewhere. Doesn't matter, just like it
                            doesn't matter with any other OAuth2
                            protected resource.

                            

                            If it's the Registration Access Token, then
                            having the token come from the token
                            endpoint would require a lot more work and
                            complexity on behalf of both of the client
                            and server. Either you end up with public
                            clients getting secrets they shouldn't need
                            or with granting clients access to the
                            client_credentials flow when they shouldn't
                            actually have it. Plus it adds extra round
                            trips which don't buy you anything.

                            

                             -- Justin

                            

                            
On 05/31/2013
                              10:15 AM, Phil Hunt wrote:

                            

                            

                              
The preference is to have the access
                                token for registration issued by the
                                normal token server rather then by the
                                registration endpoint. 

                              


                              

                              
In the current draft it is obtained
                                through a unique process and must
                                outlive the client. 

                              


                                Phil

                              


                                On 2013-05-30, at 19:47, "Richer, Justin
                                P." <jricher@mitre.org>




                                wrote:

                                

                              

                              

                                

                                  
I don't
                                    understand any of the comments below
                                    -- it already *is* an OAuth2
                                    protected resource without any
                                    special handling. Your access tokens
                                    can be short-lived, long-lived,
                                    federated, structured, random blobs
                                    ... totally doesn't matter. They are
                                    access tokens being used to access a
                                    normal protected resource. Full
                                    stop.

                                    

                                    Anything else is out of scope. The
                                    lifecycle discussions at the
                                    beginning are merely examples of
                                    some ways you *could* use it and are
                                    non-normative and non-exhaustive.

                                    

                                    You seem to be asking for something
                                    that's already in the draft.

                                    

                                     -- Justin

                                    

                                    

                                      

                                      
From: Phil
                                          Hunt [phil.hunt@oracle.com]

                                          Sent: Thursday, May 30,
                                          2013 7:31 PM

                                          To: Richer, Justin P.

                                          Cc: John Bradley; oauth@ietf.org
                                          WG

                                          Subject: Re: [OAUTH-WG]
                                          review comments on
                                          draft-ietf-oauth-dyn-reg-11.txt

                                        

                                      

                                      

                                        


                                          

                                          Phil

                                        


                                          On 2013-05-30, at 16:11,
                                          "Richer, Justin P." <jricher@mitre.org>



                                          wrote:

                                          

                                        

                                        

                                        

                                          

                                            
Comments
                                                inline, marked by [JR].

                                              

                                              

                                                

                                                
From:
                                                    Phil Hunt [phil.hunt@oracle.com]

                                                    Sent:
                                                    Thursday, May 30,
                                                    2013 5:25 PM

                                                    To: Richer,
                                                    Justin P.

                                                    Cc: John
                                                    Bradley; oauth@ietf.org WG

                                                    Subject: Re:
                                                    [OAUTH-WG] review
                                                    comments on
                                                    draft-ietf-oauth-dyn-reg-11.txt

                                                  

                                                

                                                
See below.

                                                  
                                                  

                                                  

                                                    
On 2013-05-30,
                                                      at 2:09 PM, Justin
                                                      Richer wrote:

                                                    

                                                    

                                                      
OK,

                                                        I think see part
                                                        of the hang up.
                                                        I have not seen
                                                        the scenario
                                                        that you
                                                        describe, where
                                                        you trade a 3rd
                                                        party token for
                                                        a "local" token.
                                                        I have seen
                                                        where access
                                                        tokens are
                                                        federated
                                                        directly at the
                                                        PR.
                                                        (Introspection
                                                        lets you do some
                                                        good things with
                                                        that pattern.) 

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------060403020305070004060207--

From phil.hunt@oracle.com  Fri May 31 11:04:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0321F904B for ; Fri, 31 May 2013 11:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.595
X-Spam-Level: 
X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[AWL=1.007,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k66fiRe6QmUl for ; Fri, 31 May 2013 11:04:44 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C458621F8633 for ; Fri, 31 May 2013 11:04:43 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VI4g6S023764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 18:04:43 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VI4fVl007347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 18:04:41 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VI4ekG015150; Fri, 31 May 2013 18:04:40 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 11:04:39 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! 030309@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8E4B2.1030309@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-307E9BE4-625C-4566-A489-9D03D67A72A2
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 14:04:40 -0400
To: Justin Richer 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 18:04:50 -0000

--Apple-Mail-307E9BE4-625C-4566-A489-9D03D67A72A2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

-1

Phil

On 2013-05-31, at 13:58, Justin Richer  wrote:

> I'm not willing to write out an entire class of clients from this spec, es=
pecially when we have stated use cases for them doing dynamic registration.
>=20
> I'm sorry, but your proposed solution will simply not work.
>=20
>  -- Justin
>=20
> On 05/31/2013 01:56 PM, Phil Hunt wrote:
>> Well the only client that wouldn't have a credential is an implicit clien=
t. An implicit client is transient and so would never update.=20
>>=20
>> Besides, as i have stated, implicit clients should not use dyn reg.=20
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 13:41, Justin Richer  wrote:
>>=20
>>> But the outstanding question is: how do you get the access token to acce=
ss the created resource (IE: the Registration Access Token)? You can't use t=
he client_credentials flow for a client with no credentials!
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> On 05/31/2013 12:58 PM, Phil Hunt             wrote:
>>>> Yes. I specified the trivial solution to anonymous clients earlier.
>>>>=20
>>>> Even simpler. You don't need an access token to create a new resource. Y=
ou just need one to access one. That is just basic security config.=20
>>>>=20
>>>> Phil
>>>>=20
>>>> On 2013-05-31, at 12:34, Justin Richer  wrote:
>>>>=20
>>>>> I agree that we are going in circles, since I just was going to bring u=
p my counter argument of "what about clients with no credentials?" again, wh=
ich *still* isn't addressed by what you suggest doing, below. I also believe=
 that getting rid of the Registration Access Token but using some other toke=
n method would actually make the spec larger, though I'd be glad to review a=
 concrete counter-proposal if you'd like to write one. And the fact that OID=
C is doing it this way, and considered but rejected the way that you're desc=
ribing, should say something to the WG here about whether or not this is the=
 right choice. Rough consensus and running code, after all.
>>>>>=20
>>>>> Regardless, I agree to park this issue and leave the text as is. We'll=
 move to the next draft in the last call process shortly, as I have a handfu=
l of non-normative editorial changes that I need to make, thanks to feedback=
 from a few folks.
>>>>>=20
>>>>> Again, thanks for your thorough review, Phil, and I look forward to fu=
ture feedback.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>>>>> I disagree.=20
>>>>>>=20
>>>>>> There is absolutely no need for a registration access token.=20
>>>>>>=20
>>>>>> Get rid of it and just use access tokens as per 6749. If you can't fo=
llow 6749 and need new issuing methods, what are others to say regarding inv=
enting new methods?
>>>>>>=20
>>>>>> I have not heard a good reason for the special process or one good en=
ough to warrant a new method for issuing an access token. Does the broader g=
roup                     realize this is what the spec says?
>>>>>>=20
>>>>>> Yes, i heard a lot saying OIDC does it this way. But that is a politi=
cal reason, not a technical                     reason. Still, compatibility=
 is always a strong objective.  Even so, oidc could keep using their method j=
ust fine. There is no obligation here to do the same.=20
>>>>>>=20
>>>>>> The only reason so far was expiry of client creds. Well, why not requ=
ire the client to update prior to expiry? It makes no sense to have another t=
oken with longer expiry. B'sides, even expired the client can re-register fr=
om scratch.=20
>>>>>>=20
>>>>>> Why force the client to persist multiple tokens and creds? That is fa=
r far too complex.=20
>>>>>>=20
>>>>>> Finally if you get rid of registration access token the spec size wil=
l drop roughly in half IMO. This suggests simplicity to me.=20
>>>>>>=20
>>>>>> Apologies for my rant. Maybe we should park this for now. We are goin=
g in circles.=20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On 2013-05-31, at 11:25, Justin Richer  wrote:
>>>>>>=20
>>>>>>> Phil,
>>>>>>>=20
>>>>>>> We *can* keep it straight just fine, but I just need you to be clear=
 about which part you're objecting to because the answers are different. Ple=
ase use the terms as defined in the document so that we all know which compo=
nent we're talking about. I'm sure you'd agree than in specification work su=
ch as this, precision of language and labels is key for communication betwee=
n parties. This is precisely why there's a Terminology section right up fron=
t, so that when I say "Registration Access Token" you can know that I mean a=
 very specific thing, and when I say "Initial Registration Token" I mean a v=
ery different specific thing. So I'm asking you, please, use the defined ter=
ms so that we can avoid this unnecessary confusion.
>>>>>>>=20
>>>>>>> But anyway, what you're talking about below, "the token the client u=
ses to update is profile" *IS* the Registration Access Token. That's all tha=
t that token is used for. You're not asking for it to go away, you're asking=
 for it to come from the Token Endpoint instead of the response from the Reg=
istration Endpoint. I don't see how the client *can* get it from the normal t=
oken process without jumping through specialized hoops to make that happen. I=
've implemented the draft the way that it is right now, both client and serv=
er side, and it works. Others have implemented it, too. We've done interop t=
esting, and it works. This is a proven pattern and from where I sit there is=
 both rough consensus and running code.
>>>>>>>=20
>>>>>>> I believe that I've already pointed out how the solutions you've pro=
posed so far won't work in practice, for various reasons, many of which have=
 already been brought up and discussed previously. If you have another way f=
or the client to get its Registration Access Token, please propose it; but I=
 haven't seen anything yet that will fly.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>>>>>>> Justin,
>>>>>>>>=20
>>>>>>>> This is my primary objection! We can't keep it straight. Their shou=
ld be no such thing as a registrstion access token!  Just the token the clie=
nt obtains to update its profile through the normal token request process.=20=

>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>>>>>>>=20
>>>>>>>>> Which token are you referring to here?
>>>>>>>>>=20
>>>>>>>>> If it's the Initial Registration Token, then you could get that th=
rough the normal token server no problem. (The lifecycle writeups don't call=
 this out explicitly but I would be willing to do so.) Or you could get it e=
lsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 p=
rotected resource.
>>>>>>>>>=20
>>>>>>>>> If it's the Registration Access Token, then having the token come f=
rom the token endpoint would require a lot more work and                    =
         complexity on behalf of both of the client and server. Either you e=
nd up with public clients getting secrets they shouldn't need               =
              or with granting clients access to the client_credentials flow=
 when they shouldn't actually have it. Plus it adds extra round trips which d=
on't buy you anything.
>>>>>>>>>=20
>>>>>>>>>  -- Justin
>>>>>>>>>=20
>>>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>>>>>> The preference is to have the access token for registration issue=
d by the normal token server rather then by the registration endpoint.=20
>>>>>>>>>>=20
>>>>>>>>>> In the current draft it is obtained through a unique process and m=
ust outlive the client.=20
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P."  w=
rote:
>>>>>>>>>>=20
>>>>>>>>>>> I don't understand any of the comments below -- it already *is* a=
n OAuth2 protected resource without any special handling. Your access tokens=
 can be short-lived, long-lived, federated, structured, random blobs ... tot=
ally doesn't matter. They are access tokens being used to access a normal pr=
otected resource. Full stop.
>>>>>>>>>>>=20
>>>>>>>>>>> Anything else is out of scope. The lifecycle discussions at the b=
eginning are merely examples of some ways you *could* use it and are non-nor=
mative and non-exhaustive.
>>>>>>>>>>>=20
>>>>>>>>>>> You seem to be asking for something that's already in the draft.=

>>>>>>>>>>>=20
>>>>>>>>>>>  -- Justin
>>>>>>>>>>>=20
>>>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>>>> Sent: Thursday, May 30, 2013 7:31 PM
>>>>>>>>>>> To: Richer, Justin P.
>>>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>>>> Subject: Re: [OAUTH-WG]                                         =
  review comments on draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Phil
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." =
 wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>>>>>=20
>>>>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>>>>>>>>>> To: Richer, Justin P.
>>>>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on                     =
                                draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>>>=20
>>>>>>>>>>>> See below.
>>>>>>>>>>>> Phil
>>>>>>>>>>>>=20
>>>>>>>>>>>> @independentid
>>>>>>>>>>>> www.independentid.com
>>>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> OK, I think see part of the hang up. I have not seen the scena=
rio that you describe, where you trade a 3rd party token for a "local" token=
. I have seen                                                         where a=
ccess tokens are federated directly at the PR. (Introspection lets you do so=
me good things with that pattern.)
>=20

--Apple-Mail-307E9BE4-625C-4566-A489-9D03D67A72A2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


-1

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:


  
    
  
  
    I'm not willing to write out an entire class of clients from this
    spec, especially when we have stated use cases for them doing
    dynamic registration.

    

    I'm sorry, but your proposed solution will simply not work.

    

     -- Justin

    

    
On 05/31/2013 01:56 PM, Phil Hunt
      wrote:

    

    

      
      
Well the only client that wouldn't have a credential is an
        implicit client. An implicit client is transient and so would
        never update. 

        

        Besides, as i have stated, implicit clients should not use dyn
        reg. 

      


        Phil

      


        On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

        
 But the outstanding question is: how do you get the access
          token to access the created resource (IE: the Registration
          Access Token)? You can't use the client_credentials flow for a
          client with no credentials!

          

           -- Justin

          

          

          
On 05/31/2013 12:58 PM, Phil Hunt
            wrote:

          

          

            
Yes. I specified the trivial solution to anonymous
              clients earlier.

            


            

            
Even simpler. You don't need an access token to create
              a new resource. You just need one to access one. That is
              just basic security config. 

            


              Phil

            


              On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

              
 I agree that we are going in circles, since I just
                was going to bring up my counter argument of "what about
                clients with no credentials?" again, which *still* isn't
                addressed by what you suggest doing, below. I also
                believe that getting rid of the Registration Access
                Token but using some other token method would actually
                make the spec larger, though I'd be glad to review a
                concrete counter-proposal if you'd like to write one.
                And the fact that OIDC is doing it this way, and
                considered but rejected the way that you're describing,
                should say something to the WG here about whether or not
                this is the right choice. Rough consensus and running
                code, after all.

                

                Regardless, I agree to park this issue and leave the
                text as is. We'll move to the next draft in the last
                call process shortly, as I have a handful of
                non-normative editorial changes that I need to make,
                thanks to feedback from a few folks.

                

                Again, thanks for your thorough review, Phil, and I look
                forward to future feedback.

                

                 -- Justin

                

                
On 05/31/2013 12:28 PM,
                  Phil Hunt wrote:

                

                

                  
I disagree. 

                  


                  

                  
There is absolutely no need for a registration
                    access token. 

                  


                  

                  
Get rid of it and just use access tokens as per
                    6749. If you can't follow 6749 and need new issuing
                    methods, what are others to say regarding inventing
                    new methods?

                  


                  

                  
I have not heard a good reason for the special
                    process or one good enough to warrant a new method
                    for issuing an access token. Does the broader group
                    realize this is what the spec says?

                  


                  

                  
Yes, i heard a lot saying OIDC does it this way.
                    But that is a political reason, not a technical
                    reason. Still, compatibility is always a strong
                    objective.  Even so, oidc could keep using their
                    method just fine. There is no obligation here to do
                    the same. 

                  


                  

                  
The only reason so far was expiry of client
                    creds. Well, why not require the client to update
                    prior to expiry? It makes no sense to have another
                    token with longer expiry. B'sides, even expired the
                    client can re-register from scratch. 

                  


                  

                  
Why force the client to persist multiple tokens
                    and creds? That is far far too complex. 

                  


                  

                  
Finally if you get rid of registration access
                    token the spec size will drop roughly in half IMO.
                    This suggests simplicity to me. 

                  


                  

                  
Apologies for my rant. Maybe we should park this
                    for now. We are going in circles. 

                    

                    Phil

                  


                    On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>


                    wrote:

                    

                  

                  

                  

                    
 Phil,

                      

                      We *can* keep it straight just fine, but I just
                      need you to be clear about which part you're
                      objecting to because the answers are different.
                      Please use the terms as defined in the document so
                      that we all know which component we're talking
                      about. I'm sure you'd agree than in specification
                      work such as this, precision of language and
                      labels is key for communication between parties.
                      This is precisely why there's a Terminology
                      section right up front, so that when I say
                      "Registration Access Token" you can know that I
                      mean a very specific thing, and when I say
                      "Initial Registration Token" I mean a very
                      different specific thing. So I'm asking you,
                      please, use the defined terms so that we can avoid
                      this unnecessary confusion.

                      

                      But anyway, what you're talking about below, "the
                      token the client uses to update is profile" *IS*
                      the Registration Access Token. That's all that
                      that token is used for. You're not asking for it
                      to go away, you're asking for it to come from the
                      Token Endpoint instead of the response from the
                      Registration Endpoint. I don't see how the client
                      *can* get it from the normal token process without
                      jumping through specialized hoops to make that
                      happen. I've implemented the draft the way that it
                      is right now, both client and server side, and it
                      works. Others have implemented it, too. We've done
                      interop testing, and it works. This is a proven
                      pattern and from where I sit there is both rough
                      consensus and running code.

                      

                      I believe that I've already pointed out how the
                      solutions you've proposed so far won't work in
                      practice, for various reasons, many of which have
                      already been brought up and discussed previously.
                      If you have another way for the client to get its
                      Registration Access Token, please propose it; but
                      I haven't seen anything yet that will fly.

                      

                       -- Justin

                      

                      
On 05/31/2013 11:10
                        AM, Phil Hunt wrote:

                      

                      

                        
Justin,

                        


                        

                        
This is my primary objection! We can't keep
                          it straight. Their should be no such thing as
                          a registrstion access token!  Just the token
                          the client obtains to update its profile
                          through the normal token request process. 

                          

                          Phil

                        


                          On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>



                          wrote:

                          

                        

                        

                        

                          
 Which token are you referring to here?

                            

                            If it's the Initial Registration Token, then
                            you could get that through the normal token
                            server no problem. (The lifecycle writeups
                            don't call this out explicitly but I would
                            be willing to do so.) Or you could get it
                            elsewhere. Doesn't matter, just like it
                            doesn't matter with any other OAuth2
                            protected resource.

                            

                            If it's the Registration Access Token, then
                            having the token come from the token
                            endpoint would require a lot more work and
                            complexity on behalf of both of the client
                            and server. Either you end up with public
                            clients getting secrets they shouldn't need
                            or with granting clients access to the
                            client_credentials flow when they shouldn't
                            actually have it. Plus it adds extra round
                            trips which don't buy you anything.

                            

                             -- Justin

                            

                            
On 05/31/2013
                              10:15 AM, Phil Hunt wrote:

                            

                            

                              
The preference is to have the access
                                token for registration issued by the
                                normal token server rather then by the
                                registration endpoint. 

                              


                              

                              
In the current draft it is obtained
                                through a unique process and must
                                outlive the client. 

                              


                                Phil

                              


                                On 2013-05-30, at 19:47, "Richer, Justin
                                P." <jricher@mitre.org>




                                wrote:

                                

                              

                              

                                

                                  
I don't
                                    understand any of the comments below
                                    -- it already *is* an OAuth2
                                    protected resource without any
                                    special handling. Your access tokens
                                    can be short-lived, long-lived,
                                    federated, structured, random blobs
                                    ... totally doesn't matter. They are
                                    access tokens being used to access a
                                    normal protected resource. Full
                                    stop.

                                    

                                    Anything else is out of scope. The
                                    lifecycle discussions at the
                                    beginning are merely examples of
                                    some ways you *could* use it and are
                                    non-normative and non-exhaustive.

                                    

                                    You seem to be asking for something
                                    that's already in the draft.

                                    

                                     -- Justin

                                    

                                    

                                      

                                      
From: Phil
                                          Hunt [phil.hunt@oracle.com]

                                          Sent: Thursday, May 30,
                                          2013 7:31 PM

                                          To: Richer, Justin P.

                                          Cc: John Bradley; oauth@ietf.org
                                          WG

                                          Subject: Re: [OAUTH-WG]
                                          review comments on
                                          draft-ietf-oauth-dyn-reg-11.txt

                                        

                                      

                                      

                                        


                                          

                                          Phil

                                        


                                          On 2013-05-30, at 16:11,
                                          "Richer, Justin P." <jricher@mitre.org>



                                          wrote:

                                          

                                        

                                        

                                        

                                          

                                            
Comments
                                                inline, marked by [JR].

                                              

                                              

                                                

                                                
From:
                                                    Phil Hunt [phil.hunt@oracle.com]

                                                    Sent:
                                                    Thursday, May 30,
                                                    2013 5:25 PM

                                                    To: Richer,
                                                    Justin P.

                                                    Cc: John
                                                    Bradley; oauth@ietf.org WG

                                                    Subject: Re:
                                                    [OAUTH-WG] review
                                                    comments on
                                                    draft-ietf-oauth-dyn-reg-11.txt

                                                  

                                                

                                                
See below.

                                                  
                                                  

                                                  

                                                    
On 2013-05-30,
                                                      at 2:09 PM, Justin
                                                      Richer wrote:

                                                    

                                                    

                                                      
OK,

                                                        I think see part
                                                        of the hang up.
                                                        I have not seen
                                                        the scenario
                                                        that you
                                                        describe, where
                                                        you trade a 3rd
                                                        party token for
                                                        a "local" token.
                                                        I have seen
                                                        where access
                                                        tokens are
                                                        federated
                                                        directly at the
                                                        PR.
                                                        (Introspection
                                                        lets you do some
                                                        good things with
                                                        that pattern.) 

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  



--Apple-Mail-307E9BE4-625C-4566-A489-9D03D67A72A2--

From phil.hunt@oracle.com  Fri May 31 11:11:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8954821F8E2C for ; Fri, 31 May 2013 11:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.847
X-Spam-Level: 
X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=0.756,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkt61EOjZKgk for ; Fri, 31 May 2013 11:11:26 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEF21F8EF7 for ; Fri, 31 May 2013 11:11:17 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VIBG6n030640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 18:11:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VIBFJg013529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 18:11:16 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VIBEgr029392; Fri, 31 May 2013 18:11:14 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 11:11:13 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! 030309@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8E4B2.1030309@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-D6CAC5D9-7244-48F5-A96E-CAAA215D86A8
Content-Transfer-Encoding: 7bit
Message-Id: <75C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 14:11:13 -0400
To: Justin Richer 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 18:11:32 -0000

--Apple-Mail-D6CAC5D9-7244-48F5-A96E-CAAA215D86A8
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

To be clear.=20

It is two separate issues.=20

1. Anonymous clients can easily be handled through policy config.=20

2. Support for implicit clients needs to be discussed. The current proposal c=
reates large negative value for the service provider and most would never al=
low in current form. Yes it gives each execution instance a new id, but that=
 isnt what sp's want. It is a huge attack and management headache. Eliminate=
 or propose a different solution.=20

Phil

On 2013-05-31, at 13:58, Justin Richer  wrote:

> I'm not willing to write out an entire class of clients from this spec, es=
pecially when we have stated use cases for them doing dynamic registration.
>=20
> I'm sorry, but your proposed solution will simply not work.
>=20
>  -- Justin
>=20
> On 05/31/2013 01:56 PM, Phil Hunt wrote:
>> Well the only client that wouldn't have a credential is an implicit clien=
t. An implicit client is transient and so would never update.=20
>>=20
>> Besides, as i have stated, implicit clients should not use dyn reg.=20
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 13:41, Justin Richer  wrote:
>>=20
>>> But the outstanding question is: how do you get the access token to acce=
ss the created resource (IE: the Registration Access Token)? You can't use t=
he client_credentials flow for a client with no credentials!
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> On 05/31/2013 12:58 PM, Phil Hunt             wrote:
>>>> Yes. I specified the trivial solution to anonymous clients earlier.
>>>>=20
>>>> Even simpler. You don't need an access token to create a new resource. Y=
ou just need one to access one. That is just basic security config.=20
>>>>=20
>>>> Phil
>>>>=20
>>>> On 2013-05-31, at 12:34, Justin Richer  wrote:
>>>>=20
>>>>> I agree that we are going in circles, since I just was going to bring u=
p my counter argument of "what about clients with no credentials?" again, wh=
ich *still* isn't addressed by what you suggest doing, below. I also believe=
 that getting rid of the Registration Access Token but using some other toke=
n method would actually make the spec larger, though I'd be glad to review a=
 concrete counter-proposal if you'd like to write one. And the fact that OID=
C is doing it this way, and considered but rejected the way that you're desc=
ribing, should say something to the WG here about whether or not this is the=
 right choice. Rough consensus and running code, after all.
>>>>>=20
>>>>> Regardless, I agree to park this issue and leave the text as is. We'll=
 move to the next draft in the last call process shortly, as I have a handfu=
l of non-normative editorial changes that I need to make, thanks to feedback=
 from a few folks.
>>>>>=20
>>>>> Again, thanks for your thorough review, Phil, and I look forward to fu=
ture feedback.
>>>>>=20
>>>>>  -- Justin
>>>>>=20
>>>>> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>>>>> I disagree.=20
>>>>>>=20
>>>>>> There is absolutely no need for a registration access token.=20
>>>>>>=20
>>>>>> Get rid of it and just use access tokens as per 6749. If you can't fo=
llow 6749 and need new issuing methods, what are others to say regarding inv=
enting new methods?
>>>>>>=20
>>>>>> I have not heard a good reason for the special process or one good en=
ough to warrant a new method for issuing an access token. Does the broader g=
roup                     realize this is what the spec says?
>>>>>>=20
>>>>>> Yes, i heard a lot saying OIDC does it this way. But that is a politi=
cal reason, not a technical                     reason. Still, compatibility=
 is always a strong objective.  Even so, oidc could keep using their method j=
ust fine. There is no obligation here to do the same.=20
>>>>>>=20
>>>>>> The only reason so far was expiry of client creds. Well, why not requ=
ire the client to update prior to expiry? It makes no sense to have another t=
oken with longer expiry. B'sides, even expired the client can re-register fr=
om scratch.=20
>>>>>>=20
>>>>>> Why force the client to persist multiple tokens and creds? That is fa=
r far too complex.=20
>>>>>>=20
>>>>>> Finally if you get rid of registration access token the spec size wil=
l drop roughly in half IMO. This suggests simplicity to me.=20
>>>>>>=20
>>>>>> Apologies for my rant. Maybe we should park this for now. We are goin=
g in circles.=20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On 2013-05-31, at 11:25, Justin Richer  wrote:
>>>>>>=20
>>>>>>> Phil,
>>>>>>>=20
>>>>>>> We *can* keep it straight just fine, but I just need you to be clear=
 about which part you're objecting to because the answers are different. Ple=
ase use the terms as defined in the document so that we all know which compo=
nent we're talking about. I'm sure you'd agree than in specification work su=
ch as this, precision of language and labels is key for communication betwee=
n parties. This is precisely why there's a Terminology section right up fron=
t, so that when I say "Registration Access Token" you can know that I mean a=
 very specific thing, and when I say "Initial Registration Token" I mean a v=
ery different specific thing. So I'm asking you, please, use the defined ter=
ms so that we can avoid this unnecessary confusion.
>>>>>>>=20
>>>>>>> But anyway, what you're talking about below, "the token the client u=
ses to update is profile" *IS* the Registration Access Token. That's all tha=
t that token is used for. You're not asking for it to go away, you're asking=
 for it to come from the Token Endpoint instead of the response from the Reg=
istration Endpoint. I don't see how the client *can* get it from the normal t=
oken process without jumping through specialized hoops to make that happen. I=
've implemented the draft the way that it is right now, both client and serv=
er side, and it works. Others have implemented it, too. We've done interop t=
esting, and it works. This is a proven pattern and from where I sit there is=
 both rough consensus and running code.
>>>>>>>=20
>>>>>>> I believe that I've already pointed out how the solutions you've pro=
posed so far won't work in practice, for various reasons, many of which have=
 already been brought up and discussed previously. If you have another way f=
or the client to get its Registration Access Token, please propose it; but I=
 haven't seen anything yet that will fly.
>>>>>>>=20
>>>>>>>  -- Justin
>>>>>>>=20
>>>>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>>>>>>> Justin,
>>>>>>>>=20
>>>>>>>> This is my primary objection! We can't keep it straight. Their shou=
ld be no such thing as a registrstion access token!  Just the token the clie=
nt obtains to update its profile through the normal token request process.=20=

>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>>>>>>>=20
>>>>>>>>> Which token are you referring to here?
>>>>>>>>>=20
>>>>>>>>> If it's the Initial Registration Token, then you could get that th=
rough the normal token server no problem. (The lifecycle writeups don't call=
 this out explicitly but I would be willing to do so.) Or you could get it e=
lsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 p=
rotected resource.
>>>>>>>>>=20
>>>>>>>>> If it's the Registration Access Token, then having the token come f=
rom the token endpoint would require a lot more work and                    =
         complexity on behalf of both of the client and server. Either you e=
nd up with public clients getting secrets they shouldn't need               =
              or with granting clients access to the client_credentials flow=
 when they shouldn't actually have it. Plus it adds extra round trips which d=
on't buy you anything.
>>>>>>>>>=20
>>>>>>>>>  -- Justin
>>>>>>>>>=20
>>>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>>>>>>>>> The preference is to have the access token for registration issue=
d by the normal token server rather then by the registration endpoint.=20
>>>>>>>>>>=20
>>>>>>>>>> In the current draft it is obtained through a unique process and m=
ust outlive the client.=20
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P."  w=
rote:
>>>>>>>>>>=20
>>>>>>>>>>> I don't understand any of the comments below -- it already *is* a=
n OAuth2 protected resource without any special handling. Your access tokens=
 can be short-lived, long-lived, federated, structured, random blobs ... tot=
ally doesn't matter. They are access tokens being used to access a normal pr=
otected resource. Full stop.
>>>>>>>>>>>=20
>>>>>>>>>>> Anything else is out of scope. The lifecycle discussions at the b=
eginning are merely examples of some ways you *could* use it and are non-nor=
mative and non-exhaustive.
>>>>>>>>>>>=20
>>>>>>>>>>> You seem to be asking for something that's already in the draft.=

>>>>>>>>>>>=20
>>>>>>>>>>>  -- Justin
>>>>>>>>>>>=20
>>>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>>>> Sent: Thursday, May 30, 2013 7:31 PM
>>>>>>>>>>> To: Richer, Justin P.
>>>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>>>> Subject: Re: [OAUTH-WG]                                         =
  review comments on draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Phil
>>>>>>>>>>>=20
>>>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." =
 wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Comments inline, marked by [JR].
>>>>>>>>>>>>=20
>>>>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com]
>>>>>>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>>>>>>>>>> To: Richer, Justin P.
>>>>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG
>>>>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on                     =
                                draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>>>>>>=20
>>>>>>>>>>>> See below.
>>>>>>>>>>>> Phil
>>>>>>>>>>>>=20
>>>>>>>>>>>> @independentid
>>>>>>>>>>>> www.independentid.com
>>>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> OK, I think see part of the hang up. I have not seen the scena=
rio that you describe, where you trade a 3rd party token for a "local" token=
. I have seen                                                         where a=
ccess tokens are federated directly at the PR. (Introspection lets you do so=
me good things with that pattern.)
>=20

--Apple-Mail-D6CAC5D9-7244-48F5-A96E-CAAA215D86A8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


To be clear. 

It is two separate issues. 

1. Anonymous clients can easily be handled through policy config. 

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution. 

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:


  
    
  
  
    I'm not willing to write out an entire class of clients from this
    spec, especially when we have stated use cases for them doing
    dynamic registration.

    

    I'm sorry, but your proposed solution will simply not work.

    

     -- Justin

    

    
On 05/31/2013 01:56 PM, Phil Hunt
      wrote:

    

    

      
      
Well the only client that wouldn't have a credential is an
        implicit client. An implicit client is transient and so would
        never update. 

        

        Besides, as i have stated, implicit clients should not use dyn
        reg. 

      


        Phil

      


        On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>
        wrote:

        

      

      

        
 But the outstanding question is: how do you get the access
          token to access the created resource (IE: the Registration
          Access Token)? You can't use the client_credentials flow for a
          client with no credentials!

          

           -- Justin

          

          

          
On 05/31/2013 12:58 PM, Phil Hunt
            wrote:

          

          

            
Yes. I specified the trivial solution to anonymous
              clients earlier.

            


            

            
Even simpler. You don't need an access token to create
              a new resource. You just need one to access one. That is
              just basic security config. 

            


              Phil

            


              On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>

              wrote:

              

            

            

              
 I agree that we are going in circles, since I just
                was going to bring up my counter argument of "what about
                clients with no credentials?" again, which *still* isn't
                addressed by what you suggest doing, below. I also
                believe that getting rid of the Registration Access
                Token but using some other token method would actually
                make the spec larger, though I'd be glad to review a
                concrete counter-proposal if you'd like to write one.
                And the fact that OIDC is doing it this way, and
                considered but rejected the way that you're describing,
                should say something to the WG here about whether or not
                this is the right choice. Rough consensus and running
                code, after all.

                

                Regardless, I agree to park this issue and leave the
                text as is. We'll move to the next draft in the last
                call process shortly, as I have a handful of
                non-normative editorial changes that I need to make,
                thanks to feedback from a few folks.

                

                Again, thanks for your thorough review, Phil, and I look
                forward to future feedback.

                

                 -- Justin

                

                
On 05/31/2013 12:28 PM,
                  Phil Hunt wrote:

                

                

                  
I disagree. 

                  


                  

                  
There is absolutely no need for a registration
                    access token. 

                  


                  

                  
Get rid of it and just use access tokens as per
                    6749. If you can't follow 6749 and need new issuing
                    methods, what are others to say regarding inventing
                    new methods?

                  


                  

                  
I have not heard a good reason for the special
                    process or one good enough to warrant a new method
                    for issuing an access token. Does the broader group
                    realize this is what the spec says?

                  


                  

                  
Yes, i heard a lot saying OIDC does it this way.
                    But that is a political reason, not a technical
                    reason. Still, compatibility is always a strong
                    objective.  Even so, oidc could keep using their
                    method just fine. There is no obligation here to do
                    the same. 

                  


                  

                  
The only reason so far was expiry of client
                    creds. Well, why not require the client to update
                    prior to expiry? It makes no sense to have another
                    token with longer expiry. B'sides, even expired the
                    client can re-register from scratch. 

                  


                  

                  
Why force the client to persist multiple tokens
                    and creds? That is far far too complex. 

                  


                  

                  
Finally if you get rid of registration access
                    token the spec size will drop roughly in half IMO.
                    This suggests simplicity to me. 

                  


                  

                  
Apologies for my rant. Maybe we should park this
                    for now. We are going in circles. 

                    

                    Phil

                  


                    On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org>


                    wrote:

                    

                  

                  

                  

                    
 Phil,

                      

                      We *can* keep it straight just fine, but I just
                      need you to be clear about which part you're
                      objecting to because the answers are different.
                      Please use the terms as defined in the document so
                      that we all know which component we're talking
                      about. I'm sure you'd agree than in specification
                      work such as this, precision of language and
                      labels is key for communication between parties.
                      This is precisely why there's a Terminology
                      section right up front, so that when I say
                      "Registration Access Token" you can know that I
                      mean a very specific thing, and when I say
                      "Initial Registration Token" I mean a very
                      different specific thing. So I'm asking you,
                      please, use the defined terms so that we can avoid
                      this unnecessary confusion.

                      

                      But anyway, what you're talking about below, "the
                      token the client uses to update is profile" *IS*
                      the Registration Access Token. That's all that
                      that token is used for. You're not asking for it
                      to go away, you're asking for it to come from the
                      Token Endpoint instead of the response from the
                      Registration Endpoint. I don't see how the client
                      *can* get it from the normal token process without
                      jumping through specialized hoops to make that
                      happen. I've implemented the draft the way that it
                      is right now, both client and server side, and it
                      works. Others have implemented it, too. We've done
                      interop testing, and it works. This is a proven
                      pattern and from where I sit there is both rough
                      consensus and running code.

                      

                      I believe that I've already pointed out how the
                      solutions you've proposed so far won't work in
                      practice, for various reasons, many of which have
                      already been brought up and discussed previously.
                      If you have another way for the client to get its
                      Registration Access Token, please propose it; but
                      I haven't seen anything yet that will fly.

                      

                       -- Justin

                      

                      
On 05/31/2013 11:10
                        AM, Phil Hunt wrote:

                      

                      

                        
Justin,

                        


                        

                        
This is my primary objection! We can't keep
                          it straight. Their should be no such thing as
                          a registrstion access token!  Just the token
                          the client obtains to update its profile
                          through the normal token request process. 

                          

                          Phil

                        


                          On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org>



                          wrote:

                          

                        

                        

                        

                          
 Which token are you referring to here?

                            

                            If it's the Initial Registration Token, then
                            you could get that through the normal token
                            server no problem. (The lifecycle writeups
                            don't call this out explicitly but I would
                            be willing to do so.) Or you could get it
                            elsewhere. Doesn't matter, just like it
                            doesn't matter with any other OAuth2
                            protected resource.

                            

                            If it's the Registration Access Token, then
                            having the token come from the token
                            endpoint would require a lot more work and
                            complexity on behalf of both of the client
                            and server. Either you end up with public
                            clients getting secrets they shouldn't need
                            or with granting clients access to the
                            client_credentials flow when they shouldn't
                            actually have it. Plus it adds extra round
                            trips which don't buy you anything.

                            

                             -- Justin

                            

                            
On 05/31/2013
                              10:15 AM, Phil Hunt wrote:

                            

                            

                              
The preference is to have the access
                                token for registration issued by the
                                normal token server rather then by the
                                registration endpoint. 

                              


                              

                              
In the current draft it is obtained
                                through a unique process and must
                                outlive the client. 

                              


                                Phil

                              


                                On 2013-05-30, at 19:47, "Richer, Justin
                                P." <jricher@mitre.org>




                                wrote:

                                

                              

                              

                                

                                  
I don't
                                    understand any of the comments below
                                    -- it already *is* an OAuth2
                                    protected resource without any
                                    special handling. Your access tokens
                                    can be short-lived, long-lived,
                                    federated, structured, random blobs
                                    ... totally doesn't matter. They are
                                    access tokens being used to access a
                                    normal protected resource. Full
                                    stop.

                                    

                                    Anything else is out of scope. The
                                    lifecycle discussions at the
                                    beginning are merely examples of
                                    some ways you *could* use it and are
                                    non-normative and non-exhaustive.

                                    

                                    You seem to be asking for something
                                    that's already in the draft.

                                    

                                     -- Justin

                                    

                                    

                                      

                                      
From: Phil
                                          Hunt [phil.hunt@oracle.com]

                                          Sent: Thursday, May 30,
                                          2013 7:31 PM

                                          To: Richer, Justin P.

                                          Cc: John Bradley; oauth@ietf.org
                                          WG

                                          Subject: Re: [OAUTH-WG]
                                          review comments on
                                          draft-ietf-oauth-dyn-reg-11.txt

                                        

                                      

                                      

                                        


                                          

                                          Phil

                                        


                                          On 2013-05-30, at 16:11,
                                          "Richer, Justin P." <jricher@mitre.org>



                                          wrote:

                                          

                                        

                                        

                                        

                                          

                                            
Comments
                                                inline, marked by [JR].

                                              

                                              

                                                

                                                
From:
                                                    Phil Hunt [phil.hunt@oracle.com]

                                                    Sent:
                                                    Thursday, May 30,
                                                    2013 5:25 PM

                                                    To: Richer,
                                                    Justin P.

                                                    Cc: John
                                                    Bradley; oauth@ietf.org WG

                                                    Subject: Re:
                                                    [OAUTH-WG] review
                                                    comments on
                                                    draft-ietf-oauth-dyn-reg-11.txt

                                                  

                                                

                                                
See below.

                                                  
                                                  

                                                  

                                                    
On 2013-05-30,
                                                      at 2:09 PM, Justin
                                                      Richer wrote:

                                                    

                                                    

                                                      
OK,

                                                        I think see part
                                                        of the hang up.
                                                        I have not seen
                                                        the scenario
                                                        that you
                                                        describe, where
                                                        you trade a 3rd
                                                        party token for
                                                        a "local" token.
                                                        I have seen
                                                        where access
                                                        tokens are
                                                        federated
                                                        directly at the
                                                        PR.
                                                        (Introspection
                                                        lets you do some
                                                        good things with
                                                        that pattern.) 

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  



--Apple-Mail-D6CAC5D9-7244-48F5-A96E-CAAA215D86A8--

From donald.coffin@reminetworks.com  Fri May 31 12:20:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA621F8B64 for ; Fri, 31 May 2013 12:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.664
X-Spam-Level: 
X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgMGwKgBkzlF for ; Fri, 31 May 2013 12:20:13 -0700 (PDT)
Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 8EEC521F894E for ; Fri, 31 May 2013 12:20:11 -0700 (PDT)
Received: (qmail 3557 invoked by uid 0); 31 May 2013 19:18:47 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 31 May 2013 19:18:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=EFRBusqbGTfmuBBadJU6X6KpgaLWjCn+7v9fzmFvnXQ=;  b=aHOnJp+a1deJFF7QFRqsbqTjuaDYIZZgXYyfbHjIqwynwJyrNfbgge4etWGOGovmGxnafdX6G8uYs8/Hb/VjNqnlqfDrVYfkl2+8zu1fwRzGPcakNVrcc+YdjOoS4NHB;
Received: from [68.4.207.246] (port=1236 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UiUqc-00011F-Dm; Fri, 31 May 2013 13:18:46 -0600
From: "Donald F Coffin" 
To: "'Phil Hunt'" , "'Justin Richer'" 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com>	<2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com>	<51A79B69.9090702@mitre.org>	<7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com>	<51A7A18F.1040104@mitre.org>	<4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com>	<51A7ADAE.4070005@mitre.org>	<62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>	<51A7C00B.6050409@mitre.org>	<78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>		<18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>		<77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>	<51A8B9C4.8020200! @mitre.org>		<51A8C0ED.6040607@mitre.org>	<87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>	<51A8D123.3090103@mit! re.org>		<51A8E0BD.9090908@mitre.org>	<521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! 030309@mitre.org> <75 C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com>
In-Reply-To: <75C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com>
Date: Fri, 31 May 2013 12:16:41 -0700
Message-ID: <002701ce5e33$620faaa0$262effe0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CE5DF8.B5B58D90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHkLb5nIhERHX9TmIR7UaHRfNz2VwJSzZdEAN7BlT0C1RdFjgG+pwsDAVpFt/ICBxf3nAIZfRN7Am762ZIDGGTpFAEh03SRAt+1O78CELshMAM3hDpXAsi6dGwB+OA2BQJzhJp3Am70oWcA5CDKWwFlGbIUAbl5Ra8B820jSQFE05cxAfdGMuKXfMwrEA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 19:20:18 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0028_01CE5DF8.B5B58D90
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

For something that was agreed to be parked a few hours ago, there sure =
seems to still be a lot of circular discussion.  Should we ask a =
mediator to intervene?

=20

FWIW I believe that is a significantly strong reason to differentiate an =
access token that can access the registration information without having =
the ability to access protected data.  Especially given the implied =
strength of the =E2=80=9Cclient credential=E2=80=9D obtained access =
token.  I have found it extremely confusing to users when explaining the =
difference between an access token obtained thorough an authorization =
code flow and a client credential flow, simply because they are both =
called an =E2=80=9Caccess token=E2=80=9D.  Changing the meaning of an =
access token obtained through the client credential flow to mean it has =
the ability to update a registration, when a user may not want it to =
have access to protected data will only increase both the complexity of =
the access tokens as well as make their usage harder to explain to =
non-technical individuals who have to understand the differences between =
the access tokens obtained through the various flows.

=20

Just my two cents.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt

=20

To be clear.=20

=20

It is two separate issues.=20

=20

1. Anonymous clients can easily be handled through policy config.=20

=20

2. Support for implicit clients needs to be discussed. The current =
proposal creates large negative value for the service provider and most =
would never allow in current form. Yes it gives each execution instance =
a new id, but that isnt what sp's want. It is a huge attack and =
management headache. Eliminate or propose a different solution.=20

Phil


On 2013-05-31, at 13:58, Justin Richer  wrote:

I'm not willing to write out an entire class of clients from this spec, =
especially when we have stated use cases for them doing dynamic =
registration.

I'm sorry, but your proposed solution will simply not work.

 -- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a credential is an implicit =
client. An implicit client is transient and so would never update.=20

Besides, as i have stated, implicit clients should not use dyn reg.=20


Phil


On 2013-05-31, at 13:41, Justin Richer  wrote:

But the outstanding question is: how do you get the access token to =
access the created resource (IE: the Registration Access Token)? You =
can't use the client_credentials flow for a client with no credentials!

 -- Justin



On 05/31/2013 12:58 PM, Phil Hunt wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

=20

Even simpler. You don't need an access token to create a new resource. =
You just need one to access one. That is just basic security config.=20


Phil


On 2013-05-31, at 12:34, Justin Richer  wrote:

I agree that we are going in circles, since I just was going to bring up =
my counter argument of "what about clients with no credentials?" again, =
which *still* isn't addressed by what you suggest doing, below. I also =
believe that getting rid of the Registration Access Token but using some =
other token method would actually make the spec larger, though I'd be =
glad to review a concrete counter-proposal if you'd like to write one. =
And the fact that OIDC is doing it this way, and considered but rejected =
the way that you're describing, should say something to the WG here =
about whether or not this is the right choice. Rough consensus and =
running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll =
move to the next draft in the last call process shortly, as I have a =
handful of non-normative editorial changes that I need to make, thanks =
to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to =
future feedback.

 -- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.=20

=20

There is absolutely no need for a registration access token.=20

=20

Get rid of it and just use access tokens as per 6749. If you can't =
follow 6749 and need new issuing methods, what are others to say =
regarding inventing new methods?

=20

I have not heard a good reason for the special process or one good =
enough to warrant a new method for issuing an access token. Does the =
broader group realize this is what the spec says?

=20

Yes, i heard a lot saying OIDC does it this way. But that is a political =
reason, not a technical reason. Still, compatibility is always a strong =
objective.  Even so, oidc could keep using their method just fine. There =
is no obligation here to do the same.=20

=20

The only reason so far was expiry of client creds. Well, why not require =
the client to update prior to expiry? It makes no sense to have another =
token with longer expiry. B'sides, even expired the client can =
re-register from scratch.=20

=20

Why force the client to persist multiple tokens and creds? That is far =
far too complex.=20

=20

Finally if you get rid of registration access token the spec size will =
drop roughly in half IMO. This suggests simplicity to me.=20

=20

Apologies for my rant. Maybe we should park this for now. We are going =
in circles.=20

Phil


On 2013-05-31, at 11:25, Justin Richer  wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear =
about which part you're objecting to because the answers are different. =
Please use the terms as defined in the document so that we all know =
which component we're talking about. I'm sure you'd agree than in =
specification work such as this, precision of language and labels is key =
for communication between parties. This is precisely why there's a =
Terminology section right up front, so that when I say "Registration =
Access Token" you can know that I mean a very specific thing, and when I =
say "Initial Registration Token" I mean a very different specific thing. =
So I'm asking you, please, use the defined terms so that we can avoid =
this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses =
to update is profile" *IS* the Registration Access Token. That's all =
that that token is used for. You're not asking for it to go away, you're =
asking for it to come from the Token Endpoint instead of the response =
from the Registration Endpoint. I don't see how the client *can* get it =
from the normal token process without jumping through specialized hoops =
to make that happen. I've implemented the draft the way that it is right =
now, both client and server side, and it works. Others have implemented =
it, too. We've done interop testing, and it works. This is a proven =
pattern and from where I sit there is both rough consensus and running =
code.

I believe that I've already pointed out how the solutions you've =
proposed so far won't work in practice, for various reasons, many of =
which have already been brought up and discussed previously. If you have =
another way for the client to get its Registration Access Token, please =
propose it; but I haven't seen anything yet that will fly.

 -- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:

Justin,

=20

This is my primary objection! We can't keep it straight. Their should be =
no such thing as a registrstion access token!  Just the token the client =
obtains to update its profile through the normal token request process.=20

Phil


On 2013-05-31, at 10:55, Justin Richer  wrote:

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through =
the normal token server no problem. (The lifecycle writeups don't call =
this out explicitly but I would be willing to do so.) Or you could get =
it elsewhere. Doesn't matter, just like it doesn't matter with any other =
OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from =
the token endpoint would require a lot more work and complexity on =
behalf of both of the client and server. Either you end up with public =
clients getting secrets they shouldn't need or with granting clients =
access to the client_credentials flow when they shouldn't actually have =
it. Plus it adds extra round trips which don't buy you anything.

 -- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:

The preference is to have the access token for registration issued by =
the normal token server rather then by the registration endpoint.=20

=20

In the current draft it is obtained through a unique process and must =
outlive the client.=20


Phil


On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:

I don't understand any of the comments below -- it already *is* an =
OAuth2 protected resource without any special handling. Your access =
tokens can be short-lived, long-lived, federated, structured, random =
blobs ... totally doesn't matter. They are access tokens being used to =
access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the =
beginning are merely examples of some ways you *could* use it and are =
non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

 -- Justin


  _____ =20


From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt



Phil


On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:

Comments inline, marked by [JR].


  _____ =20


From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

=20

@independentid

www.independentid.com

phil.hunt@oracle.com

=20

=20

=20

On 2013-05-30, at 2:09 PM, Justin Richer wrote:





OK, I think see part of the hang up. I have not seen the scenario that =
you describe, where you trade a 3rd party token for a "local" token. I =
have seen where access tokens are federated directly at the PR. =
(Introspection lets you do some good things with that pattern.)=20

=20

=20

=20


------=_NextPart_000_0028_01CE5DF8.B5B58D90
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


For something that was agreed to =
be parked a few hours ago, there sure seems to still be a lot of =
circular discussion.=C2=A0 Should we ask a mediator to =
intervene?
 
FWIW I =
believe that is a significantly strong reason to differentiate an access =
token that can access the registration information without having the =
ability to access protected data.=C2=A0 Especially given the implied =
strength of the =E2=80=9Cclient credential=E2=80=9D obtained access =
token.=C2=A0 I have found it extremely confusing to users when =
explaining the difference between an access token obtained thorough an =
authorization code flow and a client credential flow, simply because =
they are both called an =E2=80=9Caccess token=E2=80=9D.=C2=A0 Changing =
the meaning of an access token obtained through the client credential =
flow to mean it has the ability to update a registration, when a user =
may not want it to have access to protected data will only increase both =
the complexity of the access tokens as well as make their usage harder =
to explain to non-technical individuals who have to understand the =
differences between the access tokens obtained through the various =
flows.
 
Just my =
two cents.
 
=

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

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

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

 
=

From:=
 =
Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Friday, May 31, =
2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org =
WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt
 
To be =
clear. 
 
It is two separate =
issues. 
 
1. Anonymous clients can easily be handled through =
policy config. 
 
2. Support for implicit clients needs to be discussed. =
The current proposal creates large negative value for the service =
provider and most would never allow in current form. Yes it gives each =
execution instance a new id, but that isnt what sp's want. It is a huge =
attack and management headache. Eliminate or propose a different =
solution. 

Phil

On 2013-05-31, at =
13:58, Justin Richer <jricher@mitre.org> =
wrote:
I'm not willing to write out an entire =
class of clients from this spec, especially when we have stated use =
cases for them doing dynamic registration.

I'm sorry, but your =
proposed solution will simply not work.

 -- =
Justin
On 05/31/2013 01:56 PM, =
Phil Hunt wrote:
Well the only client that wouldn't have a credential =
is an implicit client. An implicit client is transient and so would =
never update. 

Besides, as i have stated, implicit clients =
should not use dyn reg. 

Phil

On 2013-05-31, at 13:41, Justin =
Richer <jricher@mitre.org> =
wrote:
But the outstanding question is: how do =
you get the access token to access the created resource (IE: the =
Registration Access Token)? You can't use the client_credentials flow =
for a client with no credentials!

 -- =
Justin

On 05/31/2013 =
12:58 PM, Phil Hunt wrote:
Yes. I specified the trivial solution to anonymous =
clients earlier.
 
Even simpler. You don't need an access token to create =
a new resource. You just need one to access one. That is just basic =
security config. 

Phil

On 2013-05-31, at 12:34, Justin =
Richer <jricher@mitre.org> =
wrote:
I agree that we are going in circles, =
since I just was going to bring up my counter argument of "what =
about clients with no credentials?" again, which *still* isn't =
addressed by what you suggest doing, below. I also believe that getting =
rid of the Registration Access Token but using some other token method =
would actually make the spec larger, though I'd be glad to review a =
concrete counter-proposal if you'd like to write one. And the fact that =
OIDC is doing it this way, and considered but rejected the way that =
you're describing, should say something to the WG here about whether or =
not this is the right choice. Rough consensus and running code, after =
all.

Regardless, I agree to park this issue and leave the text as =
is. We'll move to the next draft in the last call process shortly, as I =
have a handful of non-normative editorial changes that I need to make, =
thanks to feedback from a few folks.

Again, thanks for your =
thorough review, Phil, and I look forward to future =
feedback.

 -- Justin
On 05/31/2013 12:28 PM, Phil Hunt =
wrote:
I disagree. 
 
There is absolutely no need for a registration access =
token. 
 
Get rid of it and just use access tokens as per 6749. =
If you can't follow 6749 and need new issuing methods, what are others =
to say regarding inventing new methods?
 
I =
have not heard a good reason for the special process or one good enough =
to warrant a new method for issuing an access token. Does the broader =
group realize this is what the spec says?
 
Yes, i heard a lot saying OIDC does it this way. But =
that is a political reason, not a technical reason. Still, compatibility =
is always a strong objective.  Even so, oidc could keep using their =
method just fine. There is no obligation here to do the =
same. 
 
The only reason so far was expiry of client creds. =
Well, why not require the client to update prior to expiry? It makes no =
sense to have another token with longer expiry. B'sides, even expired =
the client can re-register from =
scratch. 
 
Why force the client to persist multiple tokens and =
creds? That is far far too complex. 
 
Finally if you get rid of registration access token =
the spec size will drop roughly in half IMO. This suggests simplicity to =
me. 
 
Apologies for my rant. Maybe we should park this for =
now. We are going in =
circles. 

Phil

On 2013-05-31, at 11:25, Justin =
Richer <jricher@mitre.org> =
wrote:
Phil,

We *can* keep it straight =
just fine, but I just need you to be clear about which part you're =
objecting to because the answers are different. Please use the terms as =
defined in the document so that we all know which component we're =
talking about. I'm sure you'd agree than in specification work such as =
this, precision of language and labels is key for communication between =
parties. This is precisely why there's a Terminology section right up =
front, so that when I say "Registration Access Token" you can =
know that I mean a very specific thing, and when I say "Initial =
Registration Token" I mean a very different specific thing. So I'm =
asking you, please, use the defined terms so that we can avoid this =
unnecessary confusion.

But anyway, what you're talking about =
below, "the token the client uses to update is profile" *IS* =
the Registration Access Token. That's all that that token is used for. =
You're not asking for it to go away, you're asking for it to come from =
the Token Endpoint instead of the response from the Registration =
Endpoint. I don't see how the client *can* get it from the normal token =
process without jumping through specialized hoops to make that happen. =
I've implemented the draft the way that it is right now, both client and =
server side, and it works. Others have implemented it, too. We've done =
interop testing, and it works. This is a proven pattern and from where I =
sit there is both rough consensus and running code.

I believe =
that I've already pointed out how the solutions you've proposed so far =
won't work in practice, for various reasons, many of which have already =
been brought up and discussed previously. If you have another way for =
the client to get its Registration Access Token, please propose it; but =
I haven't seen anything yet that will fly.

 -- =
Justin
On 05/31/2013 11:10 AM, =
Phil Hunt wrote:
Justin,
 
This is my primary objection! We can't keep it =
straight. Their should be no such thing as a registrstion access token! =
 Just the token the client obtains to update its profile through =
the normal token request =
process. 

Phil

On 2013-05-31, at 10:55, Justin =
Richer <jricher@mitre.org> =
wrote:
Which token are you referring to =
here?

If it's the Initial Registration Token, then you could get =
that through the normal token server no problem. (The lifecycle writeups =
don't call this out explicitly but I would be willing to do so.) Or you =
could get it elsewhere. Doesn't matter, just like it doesn't matter with =
any other OAuth2 protected resource.

If it's the Registration =
Access Token, then having the token come from the token endpoint would =
require a lot more work and complexity on behalf of both of the client =
and server. Either you end up with public clients getting secrets they =
shouldn't need or with granting clients access to the client_credentials =
flow when they shouldn't actually have it. Plus it adds extra round =
trips which don't buy you anything.

 -- =
Justin
On 05/31/2013 10:15 AM, =
Phil Hunt wrote:
The preference is to have the access token for =
registration issued by the normal token server rather then by the =
registration endpoint. 
 
In the current draft it is obtained through a unique =
process and must outlive the client. 

Phil

On 2013-05-30, at 19:47, =
"Richer, Justin P." <jricher@mitre.org> =
wrote:
=
I don't understand any of the comments below -- it already *is* an =
OAuth2 protected resource without any special handling. Your access =
tokens can be short-lived, long-lived, federated, structured, random =
blobs ... totally doesn't matter. They are access tokens being used to =
access a normal protected resource. Full stop.

Anything else is =
out of scope. The lifecycle discussions at the beginning are merely =
examples of some ways you *could* use it and are non-normative and =
non-exhaustive.

You seem to be asking for something that's =
already in the draft.

 -- =
Justin
=
From:=
 Phil Hunt [phil.hunt@oracle.com]
Sent=
: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin =
P.
Cc: John Bradley; oauth@ietf.org WG
Subject: =
Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt


Phil

On 2013-05-30, at 16:11, "Richer, Justin =
P." <jricher@mitre.org> =
wrote:
Comments inline, marked by [JR].=

=
From:=
 Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, =
May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John =
Bradley; oauth@ietf.org WG
Subject: Re: =
[OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt
See =
below.
 
On 2013-05-30, at 2:09 PM, =
Justin Richer wrote:


OK, I think see part of =
the hang up. I have not seen the scenario that you describe, where you =
trade a 3rd party token for a "local" token. I have seen where =
access tokens are federated directly at the PR. (Introspection lets you =
do some good things with that pattern.) =

 
 
 

------=_NextPart_000_0028_01CE5DF8.B5B58D90--


From phil.hunt@oracle.com  Fri May 31 12:33:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7AF21F85F7 for ; Fri, 31 May 2013 12:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=0.604,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CYj95ewVnZR for ; Fri, 31 May 2013 12:33:13 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9521621F85C0 for ; Fri, 31 May 2013 12:33:13 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VJX6lV022837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 19:33:11 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VJX4Ke020881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 19:33:05 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VJX4Xi017621; Fri, 31 May 2013 19:33:04 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 12:33:03 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <2F891558-6DDF-4FFB-B2D3-F1219EB6CFAF@oracle.com> <51A79B69.9090702@mitre.org> <7BB78EA6-B0F4-4A9E-853C-DB978C9DFB0B@oracle.com> <51A7A18F.1040104@mitre.org> <4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! ! !	030309@mitre.org> <75 C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <002701ce5e33$620faaa0$262effe0$@reminetworks.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-365E4224-2A33-4AC0-B57B-79D57CDB2C59
Content-Transfer-Encoding: 7bit
Message-Id: <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 15:33:02 -0400
To: Donald F Coffin 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 19:33:19 -0000

--Apple-Mail-365E4224-2A33-4AC0-B57B-79D57CDB2C59
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Don,

I am not proposing any change in meaning. If registration acces token issues=
 by normal token server with scope registration everything is clear as it is=
 for any other protected API. Draft 11 invents a whole new system. I strongl=
y disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin  wr=
ote:

> For something that was agreed to be parked a few hours ago, there sure see=
ms to still be a lot of circular discussion.  Should we ask a mediator to in=
tervene?
> =20
> FWIW I believe that is a significantly strong reason to differentiate an a=
ccess token that can access the registration information without having the a=
bility to access protected data.  Especially given the implied strength of t=
he =E2=80=9Cclient credential=E2=80=9D obtained access token.  I have found i=
t extremely confusing to users when explaining the difference between an acc=
ess token obtained thorough an authorization code flow and a client credenti=
al flow, simply because they are both called an =E2=80=9Caccess token=E2=80=9D=
.  Changing the meaning of an access token obtained through the client crede=
ntial flow to mean it has the ability to update a registration, when a user m=
ay not want it to have access to protected data will only increase both the c=
omplexity of the access tokens as well as make their usage harder to explain=
 to non-technical individuals who have to understand the differences between=
 the access tokens obtained through the various flows.
> =20
> Just my two cents.
> =20
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
> =20
> REMI Networks
> 22751 El Prado Suite 6216
> Rancho Santa Margarita, CA  92688-3836
> =20
> Phone:      (949) 636-8571
> Email:       donald.coffin@reminetworks.com
> =20
> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
> Sent: Friday, May 31, 2013 11:11 AM
> To: Justin Richer
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt=

> =20
> To be clear.=20
> =20
> It is two separate issues.=20
> =20
> 1. Anonymous clients can easily be handled through policy config.=20
> =20
> 2. Support for implicit clients needs to be discussed. The current proposa=
l creates large negative value for the service provider and most would never=
 allow in current form. Yes it gives each execution instance a new id, but t=
hat isnt what sp's want. It is a huge attack and management headache. Elimin=
ate or propose a different solution.=20
>=20
> Phil
>=20
> On 2013-05-31, at 13:58, Justin Richer  wrote:
>=20
> I'm not willing to write out an entire class of clients from this spec, es=
pecially when we have stated use cases for them doing dynamic registration.
>=20
> I'm sorry, but your proposed solution will simply not work.
>=20
>  -- Justin
>=20
> On 05/31/2013 01:56 PM, Phil Hunt wrote:
> Well the only client that wouldn't have a credential is an implicit client=
. An implicit client is transient and so would never update.=20
>=20
> Besides, as i have stated, implicit clients should not use dyn reg.=20
>=20
> Phil
>=20
> On 2013-05-31, at 13:41, Justin Richer  wrote:
>=20
> But the outstanding question is: how do you get the access token to access=
 the created resource (IE: the Registration Access Token)? You can't use the=
 client_credentials flow for a client with no credentials!
>=20
>  -- Justin
>=20
>=20
> On 05/31/2013 12:58 PM, Phil Hunt wrote:
> Yes. I specified the trivial solution to anonymous clients earlier.
> =20
> Even simpler. You don't need an access token to create a new resource. You=
 just need one to access one. That is just basic security config.=20
>=20
> Phil
>=20
> On 2013-05-31, at 12:34, Justin Richer  wrote:
>=20
> I agree that we are going in circles, since I just was going to bring up m=
y counter argument of "what about clients with no credentials?" again, which=
 *still* isn't addressed by what you suggest doing, below. I also believe th=
at getting rid of the Registration Access Token but using some other token m=
ethod would actually make the spec larger, though I'd be glad to review a co=
ncrete counter-proposal if you'd like to write one. And the fact that OIDC i=
s doing it this way, and considered but rejected the way that you're describ=
ing, should say something to the WG here about whether or not this is the ri=
ght choice. Rough consensus and running code, after all.
>=20
> Regardless, I agree to park this issue and leave the text as is. We'll mov=
e to the next draft in the last call process shortly, as I have a handful of=
 non-normative editorial changes that I need to make, thanks to feedback fro=
m a few folks.
>=20
> Again, thanks for your thorough review, Phil, and I look forward to future=
 feedback.
>=20
>  -- Justin
>=20
> On 05/31/2013 12:28 PM, Phil Hunt wrote:
> I disagree.=20
> =20
> There is absolutely no need for a registration access token.=20
> =20
> Get rid of it and just use access tokens as per 6749. If you can't follow 6=
749 and need new issuing methods, what are others to say regarding inventing=
 new methods?
> =20
> I have not heard a good reason for the special process or one good enough t=
o warrant a new method for issuing an access token. Does the broader group r=
ealize this is what the spec says?
> =20
> Yes, i heard a lot saying OIDC does it this way. But that is a political r=
eason, not a technical reason. Still, compatibility is always a strong objec=
tive.  Even so, oidc could keep using their method just fine. There is no ob=
ligation here to do the same.=20
> =20
> The only reason so far was expiry of client creds. Well, why not require t=
he client to update prior to expiry? It makes no sense to have another token=
 with longer expiry. B'sides, even expired the client can re-register from s=
cratch.=20
> =20
> Why force the client to persist multiple tokens and creds? That is far far=
 too complex.=20
> =20
> Finally if you get rid of registration access token the spec size will dro=
p roughly in half IMO. This suggests simplicity to me.=20
> =20
> Apologies for my rant. Maybe we should park this for now. We are going in c=
ircles.=20
>=20
> Phil
>=20
> On 2013-05-31, at 11:25, Justin Richer  wrote:
>=20
> Phil,
>=20
> We *can* keep it straight just fine, but I just need you to be clear about=
 which part you're objecting to because the answers are different. Please us=
e the terms as defined in the document so that we all know which component w=
e're talking about. I'm sure you'd agree than in specification work such as t=
his, precision of language and labels is key for communication between parti=
es. This is precisely why there's a Terminology section right up front, so t=
hat when I say "Registration Access Token" you can know that I mean a very s=
pecific thing, and when I say "Initial Registration Token" I mean a very dif=
ferent specific thing. So I'm asking you, please, use the defined terms so t=
hat we can avoid this unnecessary confusion.
>=20
> But anyway, what you're talking about below, "the token the client uses to=
 update is profile" *IS* the Registration Access Token. That's all that that=
 token is used for. You're not asking for it to go away, you're asking for i=
t to come from the Token Endpoint instead of the response from the Registrat=
ion Endpoint. I don't see how the client *can* get it from the normal token p=
rocess without jumping through specialized hoops to make that happen. I've i=
mplemented the draft the way that it is right now, both client and server si=
de, and it works. Others have implemented it, too. We've done interop testin=
g, and it works. This is a proven pattern and from where I sit there is both=
 rough consensus and running code.
>=20
> I believe that I've already pointed out how the solutions you've proposed s=
o far won't work in practice, for various reasons, many of which have alread=
y been brought up and discussed previously. If you have another way for the c=
lient to get its Registration Access Token, please propose it; but I haven't=
 seen anything yet that will fly.
>=20
>  -- Justin
>=20
> On 05/31/2013 11:10 AM, Phil Hunt wrote:
> Justin,
> =20
> This is my primary objection! We can't keep it straight. Their should be n=
o such thing as a registrstion access token!  Just the token the client obta=
ins to update its profile through the normal token request process.=20
>=20
> Phil
>=20
> On 2013-05-31, at 10:55, Justin Richer  wrote:
>=20
> Which token are you referring to here?
>=20
> If it's the Initial Registration Token, then you could get that through th=
e normal token server no problem. (The lifecycle writeups don't call this ou=
t explicitly but I would be willing to do so.) Or you could get it elsewhere=
. Doesn't matter, just like it doesn't matter with any other OAuth2 protecte=
d resource.
>=20
> If it's the Registration Access Token, then having the token come from the=
 token endpoint would require a lot more work and complexity on behalf of bo=
th of the client and server. Either you end up with public clients getting s=
ecrets they shouldn't need or with granting clients access to the client_cre=
dentials flow when they shouldn't actually have it. Plus it adds extra round=
 trips which don't buy you anything.
>=20
>  -- Justin
>=20
> On 05/31/2013 10:15 AM, Phil Hunt wrote:
> The preference is to have the access token for registration issued by the n=
ormal token server rather then by the registration endpoint.=20
> =20
> In the current draft it is obtained through a unique process and must outl=
ive the client.=20
>=20
> Phil
>=20
> On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:
>=20
> I don't understand any of the comments below -- it already *is* an OAuth2 p=
rotected resource without any special handling. Your access tokens can be sh=
ort-lived, long-lived, federated, structured, random blobs ... totally doesn=
't matter. They are access tokens being used to access a normal protected re=
source. Full stop.
>=20
> Anything else is out of scope. The lifecycle discussions at the beginning a=
re merely examples of some ways you *could* use it and are non-normative and=
 non-exhaustive.
>=20
> You seem to be asking for something that's already in the draft.
>=20
>  -- Justin
>=20
> From: Phil Hunt [phil.hunt@oracle.com]
> Sent: Thursday, May 30, 2013 7:31 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt=

>=20
>=20
>=20
> Phil
>=20
> On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:
>=20
> Comments inline, marked by [JR].
>=20
> From: Phil Hunt [phil.hunt@oracle.com]
> Sent: Thursday, May 30, 2013 5:25 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt=

>=20
> See below.
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> =20
> =20
>=20
> =20
> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>=20
>=20
> OK, I think see part of the hang up. I have not seen the scenario that you=
 describe, where you trade a 3rd party token for a "local" token. I have see=
n where access tokens are federated directly at the PR. (Introspection lets y=
ou do some good things with that pattern.)
> =20
> =20
> =20

--Apple-Mail-365E4224-2A33-4AC0-B57B-79D57CDB2C59
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Don,

I am not=
 proposing any change in meaning. If registration acces token issues by norm=
al token server with scope registration everything is clear as it is for any=
 other protected API. Draft 11 invents a whole new system. I strongly disagr=
ee with this.

Phil

On 2013-05-31, at 15:16, Donald F Co=
ffin <donald.coffin@rem=
inetworks.com> wrote:

 <=
/p>
Fo=
r something that was agreed to be parked a few hours ago, there sure seems t=
o still be a lot of circular discussion.  Should we ask a mediator to i=
ntervene?
 
FWIW I believe that is a significantly strong reason to differentia=
te an access token that can access the registration information without havi=
ng the ability to access protected data.  Especially given the implied s=
trength of the =E2=80=9Cclient credential=E2=80=9D obtained access token.&nb=
sp; I have found it extremely confusing to users when explaining the differe=
nce between an access token obtained thorough an authorization code flow and=
 a client credential flow, simply because they are both called an =E2=80=9Ca=
ccess token=E2=80=9D.  Changing the meaning of an access token obtained=
 through the client credential flow to mean it has the ability to update a r=
egistration, when a user may not want it to have access to protected data wi=
ll only increase both the complexity of the access tokens as well as make th=
eir usage harder to explain to non-technical individuals who have to underst=
and the differences between the access tokens obtained through the various f=
lows.
 
Just my two cents.
 <=
/span>
Best regards,
Don
Donald F. Coffin=

Founder/CTO
 
REMI Networks
22751 El Prado Suite 6216=

Rancho Santa Margarita, CA  92688-3836=

 
P=
hone:      (949) 636-8571
Email:       donald.coffin@remi=
networks.com
 <=
/o:p>
From: Phil Hunt [mailto:=
phil.hunt@oracle.com] 
Sent: Friday, May 31, 2013 11:11 AM
=
To: Justin Richer
Cc: oau=
th@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draf=
t-ietf-oauth-dyn-reg-11.txt
 
To be clear. <=
o:p>
 
<=
div>
It is two separate issues. 
 
1. Anonymous clients can easily be handled through policy config.=
 
 
=

2. Support for implicit clients needs to b=
e discussed. The current proposal creates large negative value for the servi=
ce provider and most would never allow in current form. Yes it gives each ex=
ecution instance a new id, but that isnt what sp's want. It is a huge attack=
 and management headache. Eliminate or propose a different solution. 
Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:
<=
blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
I'm not willing to write out an ent=
ire class of clients from this spec, especially when we have stated use case=
s for them doing dynamic registration.

I'm sorry, but your proposed s=
olution will simply not work.

 -- Justin
On 05/31/2013 01:56 PM, Phil Hunt wrote:
Well the only client that wouldn't have a credential is an im=
plicit client. An implicit client is transient and so would never update.&nb=
sp;

Besides, as i have stated, implicit clients should not use dyn re=
g. 

Phil=


On 2=
013-05-31, at 13:41, Justin Richer <=
jricher@mitre.org> wrote:
But the outstanding question is: how do you get the acces=
s token to access the created resource (IE: the Registration Access Token)? Y=
ou can't use the client_credentials flow for a client with no credentials!
 -- Justin

On 0=
5/31/2013 12:58 PM, Phil Hunt wrote:
Yes. I sp=
ecified the trivial solution to anonymous clients earlier.
 
Even simpler. You don't need an access token to create a new resou=
rce. You just need one to access one. That is just basic security config.&nb=
sp;

Phil
<=
/div>

On 2013-=
05-31, at 12:34, Justin Richer <jric=
her@mitre.org> wrote:
I agree that we are going in circles, since I just was going t=
o bring up my counter argument of "what about clients with no credentials?" a=
gain, which *still* isn't addressed by what you suggest doing, below. I also=
 believe that getting rid of the Registration Access Token but using some ot=
her token method would actually make the spec larger, though I'd be glad to r=
eview a concrete counter-proposal if you'd like to write one. And the fact t=
hat OIDC is doing it this way, and considered but rejected the way that you'=
re describing, should say something to the WG here about whether or not this=
 is the right choice. Rough consensus and running code, after all.

Re=
gardless, I agree to park this issue and leave the text as is. We'll move to=
 the next draft in the last call process shortly, as I have a handful of non=
-normative editorial changes that I need to make, thanks to feedback from a f=
ew folks.

Again, thanks for your thorough review, Phil, and I look fo=
rward to future feedback.

 -- Justin
On 05/31/2013 12:28 PM, Phil Hunt wrote:
=

I disagree. 
 
There is absolutely n=
o need for a registration access token. 
 
Get=
 rid of it and just use access tokens as per 6749. If you can't follow 6749 a=
nd need new issuing methods, what are others to say regarding inventing new m=
ethods?
 
I have not heard a good reason for the sp=
ecial process or one good enough to warrant a new method for issuing an acce=
ss token. Does the broader group realize this is what the spec says?
 
Yes, i heard a lot saying OIDC does it this way. But that=
 is a political reason, not a technical reason. Still, compatibility is alwa=
ys a strong objective.  Even so, oidc could keep using their method jus=
t fine. There is no obligation here to do the same. 
 
The only reason so far was expiry of client creds. Well, why not re=
quire the client to update prior to expiry? It makes no sense to have anothe=
r token with longer expiry. B'sides, even expired the client can re-register=
 from scratch. 
&n=
bsp;
Why force the client to pers=
ist multiple tokens and creds? That is far far too complex. =

 
Finally if you get rid of registration access token the spe=
c size will drop roughly in half IMO. This suggests simplicity to me. <=
o:p>
 
<=
div>
Apologies for my rant. Maybe we should park this f=
or now. We are going in circles. 

Phil
=


On 2013-05-31, at 1=
1:25, Justin Richer <jricher@mitre.o=
rg> wrote:
Phil,

We *can* keep it straight just fine, but I just need you to=
 be clear about which part you're objecting to because the answers are diffe=
rent. Please use the terms as defined in the document so that we all know wh=
ich component we're talking about. I'm sure you'd agree than in specificatio=
n work such as this, precision of language and labels is key for communicati=
on between parties. This is precisely why there's a Terminology section righ=
t up front, so that when I say "Registration Access Token" you can know that=
 I mean a very specific thing, and when I say "Initial Registration Token" I=
 mean a very different specific thing. So I'm asking you, please, use the de=
fined terms so that we can avoid this unnecessary confusion.

But anyw=
ay, what you're talking about below, "the token the client uses to update is=
 profile" *IS* the Registration Access Token. That's all that that token is u=
sed for. You're not asking for it to go away, you're asking for it to come f=
rom the Token Endpoint instead of the response from the Registration Endpoin=
t. I don't see how the client *can* get it from the normal token process wit=
hout jumping through specialized hoops to make that happen. I've implemented=
 the draft the way that it is right now, both client and server side, and it=
 works. Others have implemented it, too. We've done interop testing, and it w=
orks. This is a proven pattern and from where I sit there is both rough cons=
ensus and running code.

I believe that I've already pointed out how t=
he solutions you've proposed so far won't work in practice, for various reas=
ons, many of which have already been brought up and discussed previously. If=
 you have another way for the client to get its Registration Access Token, p=
lease propose it; but I haven't seen anything yet that will fly.

&nbs=
p;-- Justin
On 05/31/2013 11:10 AM=
, Phil Hunt wrote:
Justin,
 
This is my primary objection! We can't keep it straight. Their shou=
ld be no such thing as a registrstion access token!  Just the token the=
 client obtains to update its profile through the normal token request proce=
ss. 

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:
Which token are you referr=
ing to here?

If it's the Initial Registration Token, then you could g=
et that through the normal token server no problem. (The lifecycle writeups d=
on't call this out explicitly but I would be willing to do so.) Or you could=
 get it elsewhere. Doesn't matter, just like it doesn't matter with any othe=
r OAuth2 protected resource.

If it's the Registration Access Token, t=
hen having the token come from the token endpoint would require a lot more w=
ork and complexity on behalf of both of the client and server. Either you en=
d up with public clients getting secrets they shouldn't need or with grantin=
g clients access to the client_credentials flow when they shouldn't actually=
 have it. Plus it adds extra round trips which don't buy you anything.
 -- Justin
On 05/31/2013 10=
:15 AM, Phil Hunt wrote:
The preference is to=
 have the access token for registration issued by the normal token server ra=
ther then by the registration endpoint. 
 
In t=
he current draft it is obtained through a unique process and must outlive th=
e client. 

Phil
=

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:
I don't underst=
and any of the comments below -- it already *is* an OAuth2 protected resourc=
e without any special handling. Your access tokens can be short-lived, long-=
lived, federated, structured, random blobs ... totally doesn't matter. They a=
re access tokens being used to access a normal protected resource. Full stop=
.

Anything else is out of scope. The lifecycle discussions at the beg=
inning are merely examples of some ways you *could* use it and are non-norma=
tive and non-exhaustive.

You seem to be asking for something that's a=
lready in the draft.

 -- Justin
From: Phil Hunt=
 [phil.hunt@oracle.com]
Se=
nt: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org W=
G
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-=
reg-11.txt


Phil<=
/o:p>

On 2013-05-30, at 16:11, "Richer, Justi=
n P." <jricher@mit=
re.org> wrote:
Comments inline, marked by [JR]=
.
From: Phil Hunt [phil.hunt@oracle.com]Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.=

Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments=
 on draft-ietf-oauth-dyn-reg-11.txt<=
/o:p>
See below.
&n=
bsp;
 
 
On 2013-05-30, at 2:09 P=
M, Justin Richer wrote:


OK, I think see part of the hang up. I h=
ave not seen the scenario that you describe, where you trade a 3rd party tok=
en for a "local" token. I have seen where access tokens are federated direct=
ly at the PR. (Introspection lets you do some good things with that pattern.=
) 
 <=
/p>
 <=
/p>
=

--Apple-Mail-365E4224-2A33-4AC0-B57B-79D57CDB2C59--

From jricher@mitre.org  Fri May 31 12:41:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93421F8EAE for ; Fri, 31 May 2013 12:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.132
X-Spam-Level: 
X-Spam-Status: No, score=-5.132 tagged_above=-999 required=5 tests=[AWL=0.866,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MmmfVe2Kg12 for ; Fri, 31 May 2013 12:41:05 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C440B21F8E8F for ; Fri, 31 May 2013 12:41:04 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C2492A50051; Fri, 31 May 2013 15:41:04 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 20BB82A5004E; Fri, 31 May 2013 15:41:04 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 15:41:03 -0400
Message-ID: <51A8FCA6.9050109@mitre.org>
Date: Fri, 31 May 2013 15:40:22 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! ! !	030309@mitre.org> <75 C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com>
In-Reply-To: <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com>
Content-Type: multipart/alternative; boundary="------------040603040705080608040007"
X-Originating-IP: [129.83.31.56]
Cc: Donald F Coffin , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 19:41:11 -0000

--------------040603040705080608040007
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

I feel the need to clarify a couple erroneous things in Phil's statement:

   * To be clear, Draft 11 has the same Registration Access Token system 
that has been in place since draft 01, it is not inventing something new 
at the last minute as could be inferred from the statement below.
   * DynReg is using an absolutely standard OAuth 2 Bearer token as the 
Registration Access Token, it's just not coming from a Token Endpoint. 
However, since an OAuth Protected Resource doesn't care where its tokens 
come from so long as it can validate them, I don't see this as a problem 
-- this is a key point where Phil and I disagree.

  -- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:
> Don,
>
> I am not proposing any change in meaning. If registration acces token 
> issues by normal token server with scope registration everything is 
> clear as it is for any other protected API. Draft 11 invents a whole 
> new system. I strongly disagree with this.
>
> Phil
>
> On 2013-05-31, at 15:16, Donald F Coffin 
>  > wrote:
>
>> For something that was agreed to be parked a few hours ago, there 
>> sure seems to still be a lot of circular discussion.  Should we ask a 
>> mediator to intervene?
>>
>> FWIW I believe that is a significantly strong reason to differentiate 
>> an access token that can access the registration information without 
>> having the ability to access protected data.  Especially given the 
>> implied strength of the “client credential” obtained access token.  I 
>> have found it extremely confusing to users when explaining the 
>> difference between an access token obtained thorough an authorization 
>> code flow and a client credential flow, simply because they are both 
>> called an “access token”.  Changing the meaning of an access token 
>> obtained through the client credential flow to mean it has the 
>> ability to update a registration, when a user may not want it to have 
>> access to protected data will only increase both the complexity of 
>> the access tokens as well as make their usage harder to explain to 
>> non-technical individuals who have to understand the differences 
>> between the access tokens obtained through the various flows.
>>
>> Just my two cents.
>>
>> Best regards,
>>
>> Don
>>
>> Donald F. Coffin
>>
>> Founder/CTO
>>
>> REMI Networks
>>
>> 22751 El Prado Suite 6216
>>
>> Rancho Santa Margarita, CA  92688-3836
>>
>> Phone: (949) 636-8571
>>
>> Email: donald.coffin@reminetworks.com 
>> 
>>
>> *From:*Phil Hunt [mailto:phil.hunt@oracle.com]
>> *Sent:* Friday, May 31, 2013 11:11 AM
>> *To:* Justin Richer
>> *Cc:* oauth@ietf.org  WG
>> *Subject:* Re: [OAUTH-WG] review comments on 
>> draft-ietf-oauth-dyn-reg-11.txt
>>
>> To be clear.
>>
>> It is two separate issues.
>>
>> 1. Anonymous clients can easily be handled through policy config.
>>
>> 2. Support for implicit clients needs to be discussed. The current 
>> proposal creates large negative value for the service provider and 
>> most would never allow in current form. Yes it gives each execution 
>> instance a new id, but that isnt what sp's want. It is a huge attack 
>> and management headache. Eliminate or propose a different solution.
>>
>> Phil
>>
>>
>> On 2013-05-31, at 13:58, Justin Richer > > wrote:
>>
>>     I'm not willing to write out an entire class of clients from this
>>     spec, especially when we have stated use cases for them doing
>>     dynamic registration.
>>
>>     I'm sorry, but your proposed solution will simply not work.
>>
>>      -- Justin
>>
>>     On 05/31/2013 01:56 PM, Phil Hunt wrote:
>>
>>         Well the only client that wouldn't have a credential is an
>>         implicit client. An implicit client is transient and so would
>>         never update.
>>
>>         Besides, as i have stated, implicit clients should not use
>>         dyn reg.
>>
>>
>>         Phil
>>
>>
>>         On 2013-05-31, at 13:41, Justin Richer >         > wrote:
>>
>>             But the outstanding question is: how do you get the
>>             access token to access the created resource (IE: the
>>             Registration Access Token)? You can't use the
>>             client_credentials flow for a client with no credentials!
>>
>>              -- Justin
>>
>>             On 05/31/2013 12:58 PM, Phil Hunt wrote:
>>
>>                 Yes. I specified the trivial solution to anonymous
>>                 clients earlier.
>>
>>                 Even simpler. You don't need an access token to
>>                 create a new resource. You just need one to access
>>                 one. That is just basic security config.
>>
>>
>>                 Phil
>>
>>
>>                 On 2013-05-31, at 12:34, Justin Richer
>>                 > wrote:
>>
>>                     I agree that we are going in circles, since I
>>                     just was going to bring up my counter argument of
>>                     "what about clients with no credentials?" again,
>>                     which *still* isn't addressed by what you suggest
>>                     doing, below. I also believe that getting rid of
>>                     the Registration Access Token but using some
>>                     other token method would actually make the spec
>>                     larger, though I'd be glad to review a concrete
>>                     counter-proposal if you'd like to write one. And
>>                     the fact that OIDC is doing it this way, and
>>                     considered but rejected the way that you're
>>                     describing, should say something to the WG here
>>                     about whether or not this is the right choice.
>>                     Rough consensus and running code, after all.
>>
>>                     Regardless, I agree to park this issue and leave
>>                     the text as is. We'll move to the next draft in
>>                     the last call process shortly, as I have a
>>                     handful of non-normative editorial changes that I
>>                     need to make, thanks to feedback from a few folks.
>>
>>                     Again, thanks for your thorough review, Phil, and
>>                     I look forward to future feedback.
>>
>>                      -- Justin
>>
>>                     On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>
>>                         I disagree.
>>
>>                         There is absolutely no need for a
>>                         registration access token.
>>
>>                         Get rid of it and just use access tokens as
>>                         per 6749. If you can't follow 6749 and need
>>                         new issuing methods, what are others to say
>>                         regarding inventing new methods?
>>
>>                         I have not heard a good reason for the
>>                         special process or one good enough to warrant
>>                         a new method for issuing an access token.
>>                         Does the broader group realize this is what
>>                         the spec says?
>>
>>                         Yes, i heard a lot saying OIDC does it this
>>                         way. But that is a political reason, not a
>>                         technical reason. Still, compatibility is
>>                         always a strong objective.  Even so, oidc
>>                         could keep using their method just fine.
>>                         There is no obligation here to do the same.
>>
>>                         The only reason so far was expiry of client
>>                         creds. Well, why not require the client to
>>                         update prior to expiry? It makes no sense to
>>                         have another token with longer expiry.
>>                         B'sides, even expired the client can
>>                         re-register from scratch.
>>
>>                         Why force the client to persist multiple
>>                         tokens and creds? That is far far too complex.
>>
>>                         Finally if you get rid of registration access
>>                         token the spec size will drop roughly in half
>>                         IMO. This suggests simplicity to me.
>>
>>                         Apologies for my rant. Maybe we should park
>>                         this for now. We are going in circles.
>>
>>                         Phil
>>
>>
>>                         On 2013-05-31, at 11:25, Justin Richer
>>                         >                         > wrote:
>>
>>                             Phil,
>>
>>                             We *can* keep it straight just fine, but
>>                             I just need you to be clear about which
>>                             part you're objecting to because the
>>                             answers are different. Please use the
>>                             terms as defined in the document so that
>>                             we all know which component we're talking
>>                             about. I'm sure you'd agree than in
>>                             specification work such as this,
>>                             precision of language and labels is key
>>                             for communication between parties. This
>>                             is precisely why there's a Terminology
>>                             section right up front, so that when I
>>                             say "Registration Access Token" you can
>>                             know that I mean a very specific thing,
>>                             and when I say "Initial Registration
>>                             Token" I mean a very different specific
>>                             thing. So I'm asking you, please, use the
>>                             defined terms so that we can avoid this
>>                             unnecessary confusion.
>>
>>                             But anyway, what you're talking about
>>                             below, "the token the client uses to
>>                             update is profile" *IS* the Registration
>>                             Access Token. That's all that that token
>>                             is used for. You're not asking for it to
>>                             go away, you're asking for it to come
>>                             from the Token Endpoint instead of the
>>                             response from the Registration Endpoint.
>>                             I don't see how the client *can* get it
>>                             from the normal token process without
>>                             jumping through specialized hoops to make
>>                             that happen. I've implemented the draft
>>                             the way that it is right now, both client
>>                             and server side, and it works. Others
>>                             have implemented it, too. We've done
>>                             interop testing, and it works. This is a
>>                             proven pattern and from where I sit there
>>                             is both rough consensus and running code.
>>
>>                             I believe that I've already pointed out
>>                             how the solutions you've proposed so far
>>                             won't work in practice, for various
>>                             reasons, many of which have already been
>>                             brought up and discussed previously. If
>>                             you have another way for the client to
>>                             get its Registration Access Token, please
>>                             propose it; but I haven't seen anything
>>                             yet that will fly.
>>
>>                              -- Justin
>>
>>                             On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>
>>                                 Justin,
>>
>>                                 This is my primary objection! We
>>                                 can't keep it straight. Their should
>>                                 be no such thing as a registrstion
>>                                 access token!  Just the token the
>>                                 client obtains to update its profile
>>                                 through the normal token request
>>                                 process.
>>
>>                                 Phil
>>
>>
>>                                 On 2013-05-31, at 10:55, Justin
>>                                 Richer >                                 > wrote:
>>
>>                                     Which token are you referring to
>>                                     here?
>>
>>                                     If it's the Initial Registration
>>                                     Token, then you could get that
>>                                     through the normal token server
>>                                     no problem. (The lifecycle
>>                                     writeups don't call this out
>>                                     explicitly but I would be willing
>>                                     to do so.) Or you could get it
>>                                     elsewhere. Doesn't matter, just
>>                                     like it doesn't matter with any
>>                                     other OAuth2 protected resource.
>>
>>                                     If it's the Registration Access
>>                                     Token, then having the token come
>>                                     from the token endpoint would
>>                                     require a lot more work and
>>                                     complexity on behalf of both of
>>                                     the client and server. Either you
>>                                     end up with public clients
>>                                     getting secrets they shouldn't
>>                                     need or with granting clients
>>                                     access to the client_credentials
>>                                     flow when they shouldn't actually
>>                                     have it. Plus it adds extra round
>>                                     trips which don't buy you anything.
>>
>>                                      -- Justin
>>
>>                                     On 05/31/2013 10:15 AM, Phil Hunt
>>                                     wrote:
>>
>>                                         The preference is to have the
>>                                         access token for registration
>>                                         issued by the normal token
>>                                         server rather then by the
>>                                         registration endpoint.
>>
>>                                         In the current draft it is
>>                                         obtained through a unique
>>                                         process and must outlive the
>>                                         client.
>>
>>
>>                                         Phil
>>
>>
>>                                         On 2013-05-30, at 19:47,
>>                                         "Richer, Justin P."
>>                                         >                                         >
>>                                         wrote:
>>
>>                                             I don't understand any of
>>                                             the comments below -- it
>>                                             already *is* an OAuth2
>>                                             protected resource
>>                                             without any special
>>                                             handling. Your access
>>                                             tokens can be
>>                                             short-lived, long-lived,
>>                                             federated, structured,
>>                                             random blobs ... totally
>>                                             doesn't matter. They are
>>                                             access tokens being used
>>                                             to access a normal
>>                                             protected resource. Full
>>                                             stop.
>>
>>                                             Anything else is out of
>>                                             scope. The lifecycle
>>                                             discussions at the
>>                                             beginning are merely
>>                                             examples of some ways you
>>                                             *could* use it and are
>>                                             non-normative and
>>                                             non-exhaustive.
>>
>>                                             You seem to be asking for
>>                                             something that's already
>>                                             in the draft.
>>
>>                                              -- Justin
>>
>>                                             ------------------------------------------------------------------------
>>
>>                                             *From:*Phil Hunt
>>                                             [phil.hunt@oracle.com
>>                                             ]
>>                                             *Sent:* Thursday, May 30,
>>                                             2013 7:31 PM
>>                                             *To:* Richer, Justin P.
>>                                             *Cc:* John Bradley;
>>                                             oauth@ietf.org
>>                                              WG
>>                                             *Subject:* Re: [OAUTH-WG]
>>                                             review comments on
>>                                             draft-ietf-oauth-dyn-reg-11.txt
>>
>>
>>
>>                                             Phil
>>
>>
>>                                             On 2013-05-30, at 16:11,
>>                                             "Richer, Justin P."
>>                                             >                                             >
>>                                             wrote:
>>
>>                                                 Comments inline,
>>                                                 marked by [JR].
>>
>>                                                 ------------------------------------------------------------------------
>>
>>                                                 *From:*Phil Hunt
>>                                                 [phil.hunt@oracle.com
>>                                                 ]
>>                                                 *Sent:* Thursday, May
>>                                                 30, 2013 5:25 PM
>>                                                 *To:* Richer, Justin P.
>>                                                 *Cc:* John Bradley;
>>                                                 oauth@ietf.org
>>                                                 
>>                                                 WG
>>                                                 *Subject:* Re:
>>                                                 [OAUTH-WG] review
>>                                                 comments on
>>                                                 draft-ietf-oauth-dyn-reg-11.txt
>>
>>                                                 See below.
>>
>>                                                 Phil
>>
>>                                                 @independentid
>>
>>                                                 www.independentid.com
>>                                                 
>>
>>                                                 phil.hunt@oracle.com
>>                                                 
>>
>>                                                 On 2013-05-30, at
>>                                                 2:09 PM, Justin
>>                                                 Richer wrote:
>>
>>
>>
>>                                                 OK, I think see part
>>                                                 of the hang up. I
>>                                                 have not seen the
>>                                                 scenario that you
>>                                                 describe, where you
>>                                                 trade a 3rd party
>>                                                 token for a "local"
>>                                                 token. I have seen
>>                                                 where access tokens
>>                                                 are federated
>>                                                 directly at the PR.
>>                                                 (Introspection lets
>>                                                 you do some good
>>                                                 things with that
>>                                                 pattern.)
>>


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


  
    
  
  
    I feel the need to clarify a couple erroneous things in Phil's
    statement:

    

      * To be clear, Draft 11 has the same Registration Access Token
    system that has been in place since draft 01, it is not inventing
    something new at the last minute as could be inferred from the
    statement below.

      * DynReg is using an absolutely standard OAuth 2 Bearer token as
    the Registration Access Token, it's just not coming from a Token
    Endpoint. However, since an OAuth Protected Resource doesn't care
    where its tokens come from so long as it can validate them, I don't
    see this as a problem -- this is a key point where Phil and I
    disagree.

    

     -- Justin

    

    
On 05/31/2013 03:33 PM, Phil Hunt
      wrote:

    

    

      
      
Don,

      


      

      
I am not proposing any change in meaning. If registration
        acces token issues by normal token server with scope
        registration everything is clear as it is for any other
        protected API. Draft 11 invents a whole new system. I strongly
        disagree with this.

        

        Phil

      


        On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com>
        wrote:

        

      

      

        

          
          
          
          

            
For
                something that was agreed to be parked a few hours ago,
                there sure seems to still be a lot of circular
                discussion.  Should we ask a mediator to intervene?

            
 

            
FWIW
                I believe that is a significantly strong reason to
                differentiate an access token that can access the
                registration information without having the ability to
                access protected data.  Especially given the implied
                strength of the “client credential” obtained access
                token.  I have found it extremely confusing to users
                when explaining the difference between an access token
                obtained thorough an authorization code flow and a
                client credential flow, simply because they are both
                called an “access token”.  Changing the meaning of an
                access token obtained through the client credential flow
                to mean it has the ability to update a registration,
                when a user may not want it to have access to protected
                data will only increase both the complexity of the
                access tokens as well as make their usage harder to
                explain to non-technical individuals who have to
                understand the differences between the access tokens
                obtained through the various flows.

            
 

            
Just
                my two cents.

            
 

            

              
Best
                  regards,

              
Don

              
Donald
                  F. Coffin

              
Founder/CTO

              
 

              
REMI
                  Networks

              
22751
                  El Prado Suite 6216

              
Rancho
                  Santa Margarita, CA  92688-3836

              
 

              
Phone:     
                  (949) 636-8571

              
Email:      
                  donald.coffin@reminetworks.com

            

            
 

            

              

                
From:
                    Phil Hunt [mailto:phil.hunt@oracle.com]
                    

                    Sent: Friday, May 31, 2013 11:11 AM

                    To: Justin Richer

                    Cc: oauth@ietf.org WG

                    Subject: Re: [OAUTH-WG] review comments on
                    draft-ietf-oauth-dyn-reg-11.txt

              

            

            
 

            

              
To be clear. 

            

            

              
 

            

            

              
It is two separate issues. 

            

            

              
 

            

            

              
1. Anonymous clients can easily be
                handled through policy config. 

            

            

              
 

            

            

              
2. Support for implicit clients needs
                to be discussed. The current proposal creates large
                negative value for the service provider and most would
                never allow in current form. Yes it gives each execution
                instance a new id, but that isnt what sp's want. It is a
                huge attack and management headache. Eliminate or
                propose a different solution. 

                

                Phil

            

            

              


                On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org>
                wrote:

            

            

              

                
I'm
                  not willing to write out an entire class of clients
                  from this spec, especially when we have stated use
                  cases for them doing dynamic registration.

                  

                  I'm sorry, but your proposed solution will simply not
                  work.

                  

                   -- Justin

                

                  
On 05/31/2013 01:56 PM, Phil Hunt
                    wrote:

                

                

                  

                    
Well the only client that
                      wouldn't have a credential is an implicit client.
                      An implicit client is transient and so would never
                      update. 

                      

                      Besides, as i have stated, implicit clients should
                      not use dyn reg. 

                  

                  

                    


                      Phil

                  

                  

                    


                      On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>
                      wrote:

                  

                  

                    

                      
But
                        the outstanding question is: how do you get the
                        access token to access the created resource (IE:
                        the Registration Access Token)? You can't use
                        the client_credentials flow for a client with no
                        credentials!

                        

                         -- Justin

                        

                        

                      

                        
On 05/31/2013 12:58 PM,
                          Phil Hunt wrote:

                      

                      

                        

                          
Yes. I specified the
                            trivial solution to anonymous clients
                            earlier.

                        

                        

                          
 

                        

                        

                          
Even simpler. You don't
                            need an access token to create a new
                            resource. You just need one to access one.
                            That is just basic security config. 

                        

                        

                          


                            Phil

                        

                        

                          


                            On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>
                            wrote:

                        

                        

                          

                            
I agree that
                              we are going in circles, since I just was
                              going to bring up my counter argument of
                              "what about clients with no credentials?"
                              again, which *still* isn't addressed by
                              what you suggest doing, below. I also
                              believe that getting rid of the
                              Registration Access Token but using some
                              other token method would actually make the
                              spec larger, though I'd be glad to review
                              a concrete counter-proposal if you'd like
                              to write one. And the fact that OIDC is
                              doing it this way, and considered but
                              rejected the way that you're describing,
                              should say something to the WG here about
                              whether or not this is the right choice.
                              Rough consensus and running code, after
                              all.

                              

                              Regardless, I agree to park this issue and
                              leave the text as is. We'll move to the
                              next draft in the last call process
                              shortly, as I have a handful of
                              non-normative editorial changes that I
                              need to make, thanks to feedback from a
                              few folks.

                              

                              Again, thanks for your thorough review,
                              Phil, and I look forward to future
                              feedback.

                              

                               -- Justin

                            

                              
On 05/31/2013 12:28
                                PM, Phil Hunt wrote:

                            

                            

                              

                                
I disagree. 

                              

                              

                                
 

                              

                              

                                
There is absolutely
                                  no need for a registration access
                                  token. 

                              

                              

                                
 

                              

                              

                                
Get rid of it and
                                  just use access tokens as per 6749. If
                                  you can't follow 6749 and need new
                                  issuing methods, what are others to
                                  say regarding inventing new methods?

                              

                              

                                
 

                              

                              

                                
I have not heard a
                                  good reason for the special process or
                                  one good enough to warrant a new
                                  method for issuing an access token.
                                  Does the broader group realize this is
                                  what the spec says?

                              

                              

                                
 

                              

                              

                                
Yes, i heard a lot
                                  saying OIDC does it this way. But that
                                  is a political reason, not a technical
                                  reason. Still, compatibility is always
                                  a strong objective.  Even so, oidc
                                  could keep using their method just
                                  fine. There is no obligation here to
                                  do the same. 

                              

                              

                                
 

                              

                              

                                
The only reason so
                                  far was expiry of client creds. Well,
                                  why not require the client to update
                                  prior to expiry? It makes no sense to
                                  have another token with longer expiry.
                                  B'sides, even expired the client can
                                  re-register from scratch. 

                              

                              

                                
 

                              

                              

                                
Why force the
                                  client to persist multiple tokens and
                                  creds? That is far far too complex. 

                              

                              

                                
 

                              

                              

                                
Finally if you get
                                  rid of registration access token the
                                  spec size will drop roughly in half
                                  IMO. This suggests simplicity to me. 

                              

                              

                                
 

                              

                              

                                
Apologies for my
                                  rant. Maybe we should park this for
                                  now. We are going in circles. 

                                  

                                  Phil

                              

                              

                                


                                  On 2013-05-31, at 11:25, Justin Richer
                                  <jricher@mitre.org>
                                  wrote:

                              

                              

                                

                                  
Phil,

                                    

                                    We *can* keep it straight just fine,
                                    but I just need you to be clear
                                    about which part you're objecting to
                                    because the answers are different.
                                    Please use the terms as defined in
                                    the document so that we all know
                                    which component we're talking about.
                                    I'm sure you'd agree than in
                                    specification work such as this,
                                    precision of language and labels is
                                    key for communication between
                                    parties. This is precisely why
                                    there's a Terminology section right
                                    up front, so that when I say
                                    "Registration Access Token" you can
                                    know that I mean a very specific
                                    thing, and when I say "Initial
                                    Registration Token" I mean a very
                                    different specific thing. So I'm
                                    asking you, please, use the defined
                                    terms so that we can avoid this
                                    unnecessary confusion.

                                    

                                    But anyway, what you're talking
                                    about below, "the token the client
                                    uses to update is profile" *IS* the
                                    Registration Access Token. That's
                                    all that that token is used for.
                                    You're not asking for it to go away,
                                    you're asking for it to come from
                                    the Token Endpoint instead of the
                                    response from the Registration
                                    Endpoint. I don't see how the client
                                    *can* get it from the normal token
                                    process without jumping through
                                    specialized hoops to make that
                                    happen. I've implemented the draft
                                    the way that it is right now, both
                                    client and server side, and it
                                    works. Others have implemented it,
                                    too. We've done interop testing, and
                                    it works. This is a proven pattern
                                    and from where I sit there is both
                                    rough consensus and running code.

                                    

                                    I believe that I've already pointed
                                    out how the solutions you've
                                    proposed so far won't work in
                                    practice, for various reasons, many
                                    of which have already been brought
                                    up and discussed previously. If you
                                    have another way for the client to
                                    get its Registration Access Token,
                                    please propose it; but I haven't
                                    seen anything yet that will fly.

                                    

                                     -- Justin

                                  

                                    
On 05/31/2013
                                      11:10 AM, Phil Hunt wrote:

                                  

                                  

                                    

                                      
Justin,

                                    

                                    

                                      
 

                                    

                                    

                                      
This is my
                                        primary objection! We can't keep
                                        it straight. Their should be no
                                        such thing as a registrstion
                                        access token!  Just the token
                                        the client obtains to update its
                                        profile through the normal token
                                        request process. 

                                        

                                        Phil

                                    

                                    

                                      


                                        On 2013-05-31, at 10:55, Justin
                                        Richer <jricher@mitre.org>
                                        wrote:

                                    

                                    

                                      

                                        
Which
                                          token are you referring to
                                          here?

                                          

                                          If it's the Initial
                                          Registration Token, then you
                                          could get that through the
                                          normal token server no
                                          problem. (The lifecycle
                                          writeups don't call this out
                                          explicitly but I would be
                                          willing to do so.) Or you
                                          could get it elsewhere.
                                          Doesn't matter, just like it
                                          doesn't matter with any other
                                          OAuth2 protected resource.

                                          

                                          If it's the Registration
                                          Access Token, then having the
                                          token come from the token
                                          endpoint would require a lot
                                          more work and complexity on
                                          behalf of both of the client
                                          and server. Either you end up
                                          with public clients getting
                                          secrets they shouldn't need or
                                          with granting clients access
                                          to the client_credentials flow
                                          when they shouldn't actually
                                          have it. Plus it adds extra
                                          round trips which don't buy
                                          you anything.

                                          

                                           -- Justin

                                        

                                          
On
                                            05/31/2013 10:15 AM, Phil
                                            Hunt wrote:

                                        

                                        

                                          

                                            
The
                                              preference is to have the
                                              access token for
                                              registration issued by the
                                              normal token server rather
                                              then by the registration
                                              endpoint. 

                                          

                                          

                                            
 

                                          

                                          

                                            
In the
                                              current draft it is
                                              obtained through a unique
                                              process and must outlive
                                              the client. 

                                          

                                          

                                            


                                              Phil

                                          

                                          

                                            


                                              On 2013-05-30, at 19:47,
                                              "Richer, Justin P." <jricher@mitre.org>
                                              wrote:

                                          

                                          

                                            

                                              

                                                
I
                                                    don't understand any
                                                    of the comments
                                                    below -- it already
                                                    *is* an OAuth2
                                                    protected resource
                                                    without any special
                                                    handling. Your
                                                    access tokens can be
                                                    short-lived,
                                                    long-lived,
                                                    federated,
                                                    structured, random
                                                    blobs ... totally
                                                    doesn't matter. They
                                                    are access tokens
                                                    being used to access
                                                    a normal protected
                                                    resource. Full stop.

                                                    

                                                    Anything else is out
                                                    of scope. The
                                                    lifecycle
                                                    discussions at the
                                                    beginning are merely
                                                    examples of some
                                                    ways you *could* use
                                                    it and are
                                                    non-normative and
                                                    non-exhaustive.

                                                    

                                                    You seem to be
                                                    asking for something
                                                    that's already in
                                                    the draft.

                                                    

                                                     -- Justin

                                                

                                                  

                                                      

                                                  

                                                    
From:
                                                        Phil Hunt [phil.hunt@oracle.com]

                                                        Sent:
                                                        Thursday, May
                                                        30, 2013 7:31 PM

                                                        To:
                                                        Richer, Justin
                                                        P.

                                                        Cc: John
                                                        Bradley; oauth@ietf.org WG

                                                        Subject:
                                                        Re: [OAUTH-WG]
                                                        review comments
                                                        on
                                                        draft-ietf-oauth-dyn-reg-11.txt

                                                  

                                                  

                                                    

                                                      


                                                          

                                                          Phil

                                                    

                                                    

                                                      


                                                          On 2013-05-30,
                                                          at 16:11,
                                                          "Richer,
                                                          Justin P."
                                                          <jricher@mitre.org>
                                                          wrote:

                                                    

                                                    

                                                      

                                                        

                                                          
Comments
                                                          inline, marked
                                                          by [JR].

                                                          

                                                          

                                                          

                                                          

                                                          
From:
                                                          Phil Hunt [phil.hunt@oracle.com]

                                                          Sent:
                                                          Thursday, May
                                                          30, 2013 5:25
                                                          PM

                                                          To:
                                                          Richer, Justin
                                                          P.

                                                          Cc:
                                                          John Bradley;
                                                          oauth@ietf.org WG

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          review
                                                          comments on
                                                          draft-ietf-oauth-dyn-reg-11.txt

                                                          

                                                          

                                                          
See below.

                                                          

                                                          

                                                          
                                                          
 

                                                          

                                                          
 

                                                          

                                                          
 

                                                          

                                                          

                                                          
On 2013-05-30, at 2:09 PM, Justin Richer wrote:

                                                          

                                                          


                                                          

                                                          

                                                          

                                                          
OK, I think see part of the hang up. I have not seen
                                                          the scenario
                                                          that you
                                                          describe,
                                                          where you
                                                          trade a 3rd
                                                          party token
                                                          for a "local"
                                                          token. I have
                                                          seen where
                                                          access tokens
                                                          are federated
                                                          directly at
                                                          the PR.
                                                          (Introspection
                                                          lets you do
                                                          some good
                                                          things with
                                                          that pattern.)
                                                          

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                            
 

                          

                        

                      

                      
 

                    

                  

                

                
 

              

            

          

        

      

    

    

  


--------------040603040705080608040007--

From phil.hunt@oracle.com  Fri May 31 12:52:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F621F9051 for ; Fri, 31 May 2013 12:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level: 
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=0.504,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWg3Az2ykC6P for ; Fri, 31 May 2013 12:52:02 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 185F621F85E6 for ; Fri, 31 May 2013 12:52:01 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4VJpwC0008488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 19:51:59 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VJpx0d026093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 19:52:00 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4VJpx32021925; Fri, 31 May 2013 19:51:59 GMT
Received: from [192.168.4.225] (/64.134.196.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 May 2013 12:51:57 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>  <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>  <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8B9C4.8020200! @mitre.org>  <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8D123.3090103@mit! re.org>  <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! ! !	030309@mitre.org> <75 C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A8FCA6.9050109@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-4AD6487F-0F3E-4928-B29B-0C46DF9CAD1B
Content-Transfer-Encoding: 7bit
Message-Id: <639AEA53-9CA2-4DA3-B7DC-61F9FE7623D0@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt 
Date: Fri, 31 May 2013 15:51:56 -0400
To: Justin Richer 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Donald F Coffin , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 19:52:09 -0000

--Apple-Mail-4AD6487F-0F3E-4928-B29B-0C46DF9CAD1B
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ok. You are correct. All versions invent a new method for issuing access tok=
ens.=20

This is not within the charter.=20

Phil

On 2013-05-31, at 15:40, Justin Richer  wrote:

> I feel the need to clarify a couple erroneous things in Phil's statement:
>=20
>   * To be clear, Draft 11 has the same Registration Access Token system th=
at has been in place since draft 01, it is not inventing something new at th=
e last minute as could be inferred from the statement below.
>   * DynReg is using an absolutely standard OAuth 2 Bearer token as the Reg=
istration Access Token, it's just not coming from a Token Endpoint. However,=
 since an OAuth Protected Resource doesn't care where its tokens come from s=
o long as it can validate them, I don't see this as a problem -- this is a k=
ey point where Phil and I disagree.
>=20
>  -- Justin
>=20
> On 05/31/2013 03:33 PM, Phil Hunt wrote:
>> Don,
>>=20
>> I am not proposing any change in meaning. If registration acces token iss=
ues by normal token server with scope registration everything is clear as it=
 is for any other protected API. Draft 11 invents a whole new system. I stro=
ngly disagree with this.
>>=20
>> Phil
>>=20
>> On 2013-05-31, at 15:16, Donald F Coffin =
         wrote:
>>=20
>>> For something that was agreed to be parked a few hours ago, there sure s=
eems to still be a lot of circular discussion.  Should we ask a mediator to i=
ntervene?
>>> =20
>>> FWIW I believe that is a significantly strong reason to differentiate an=
 access token that can access the registration information without having th=
e ability to access protected data.  Especially given the implied strength o=
f the =E2=80=9Cclient credential=E2=80=9D obtained access token.  I have fou=
nd it extremely confusing to users when explaining the difference between an=
 access token obtained thorough an authorization code flow and a client cred=
ential flow, simply because they are both called an =E2=80=9Caccess token=E2=
=80=9D.  Changing the meaning of an access token obtained through the client=
 credential flow to mean it has the ability to update a registration, when a=
 user may not want it to have access to protected data will only increase bo=
th the complexity of the access tokens as well as make their usage harder to=
 explain to non-technical individuals who have to understand the differences=
 between the access tokens obtained through the various flows.
>>> =20
>>> Just my two cents.
>>> =20
>>> Best regards,
>>> Don
>>> Donald F. Coffin
>>> Founder/CTO
>>> =20
>>> REMI Networks
>>> 22751 El Prado Suite 6216
>>> Rancho Santa Margarita, CA  92688-3836
>>> =20
>>> Phone:      (949) 636-8571
>>> Email:       donald.coffin@reminetworks.com
>>> =20
>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
>>> Sent: Friday, May 31, 2013 11:11 AM
>>> To: Justin Richer
>>> Cc: oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.t=
xt
>>> =20
>>> To be clear.=20
>>> =20
>>> It is two separate issues.=20
>>> =20
>>> 1. Anonymous clients can easily be handled through policy config.=20
>>> =20
>>> 2. Support for implicit clients needs to be discussed. The current propo=
sal creates large negative value for the service provider and most would nev=
er allow in current form. Yes it gives each execution                 instan=
ce a new id, but that isnt what sp's want. It is a huge attack and managemen=
t headache. Eliminate or propose a different solution.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-31, at 13:58, Justin Richer  wrote:
>>>=20
>>> I'm not willing to write out an entire class of clients from this spec, e=
specially when we have stated use cases for them doing dynamic registration.=

>>>=20
>>> I'm sorry, but your proposed solution will simply not work.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 01:56 PM, Phil Hunt wrote:
>>> Well the only client that wouldn't have a credential is an implicit clie=
nt. An implicit client is transient and so would never update.=20
>>>=20
>>> Besides, as i have stated, implicit clients should not use dyn reg.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-31, at 13:41, Justin Richer  wrote:
>>>=20
>>> But the outstanding question is: how do you get the access token to acce=
ss the created resource (IE: the Registration Access Token)? You can't use t=
he client_credentials flow for a client with no credentials!
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> On 05/31/2013 12:58 PM, Phil Hunt wrote:
>>> Yes. I specified the trivial solution to anonymous clients earlier.
>>> =20
>>> Even simpler. You don't need an access token to create a new resource. Y=
ou just need one to access one. That is just basic security config.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-31, at 12:34, Justin Richer  wrote:
>>>=20
>>> I agree that we are going in circles, since I just was going to bring up=
 my counter argument of "what about clients with no credentials?" again, whi=
ch *still* isn't addressed by what you suggest doing, below. I also believe t=
hat getting rid of the Registration Access Token but using some other token m=
ethod would actually make the spec larger, though I'd be glad to review a co=
ncrete counter-proposal if you'd like to write one. And the fact that OIDC i=
s doing it this way, and considered but rejected the way that you're describ=
ing, should say something to the WG here about whether or not this is the ri=
ght choice. Rough consensus and running code, after                         =
      all.
>>>=20
>>> Regardless, I agree to park this issue and leave the text as is. We'll m=
ove to the next draft in the last call process shortly, as I have a handful o=
f non-normative editorial changes that I need to make, thanks to feedback fr=
om a few folks.
>>>=20
>>> Again, thanks for your thorough review, Phil, and I look forward to futu=
re feedback.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>> I disagree.=20
>>> =20
>>> There is absolutely no need for a registration access token.=20
>>> =20
>>> Get rid of it and just use access tokens as per 6749. If you can't follo=
w 6749 and need new issuing methods, what are others to say regarding invent=
ing new methods?
>>> =20
>>> I have not heard a good reason for the special process or one good enoug=
h to warrant a new method for issuing an access token. Does the broader grou=
p realize this is what the spec says?
>>> =20
>>> Yes, i heard a lot saying OIDC does it this way. But that is a political=
 reason, not a technical reason. Still, compatibility is always a strong obj=
ective.  Even so, oidc could keep using their method just fine. There is no o=
bligation here to do the same.=20
>>> =20
>>> The only reason so far was expiry of client creds. Well, why not require=
 the client to update prior to expiry? It makes no sense to have another tok=
en with longer expiry. B'sides, even expired the client can re-register from=
 scratch.=20
>>> =20
>>> Why force the client to persist multiple tokens and creds? That is far f=
ar too complex.=20
>>> =20
>>> Finally if you get rid of registration access token the spec size will d=
rop roughly in half IMO. This suggests simplicity to me.=20
>>> =20
>>> Apologies for my rant. Maybe we should park this for now. We are going i=
n circles.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-31, at 11:25, Justin Richer  wrote:
>>>=20
>>> Phil,
>>>=20
>>> We *can* keep it straight just fine, but I just need you to be clear abo=
ut which part you're objecting to because the answers are different. Please u=
se the terms as defined in the document so that we all know which component w=
e're talking about. I'm sure you'd agree than in specification work such as t=
his, precision of language and labels is key for communication between parti=
es. This is precisely why there's a Terminology section right up front, so t=
hat when I say "Registration Access Token" you can know that I mean a very s=
pecific thing, and when I say "Initial Registration Token" I mean a very dif=
ferent specific thing. So I'm asking you, please, use the defined terms so t=
hat we can avoid this unnecessary confusion.
>>>=20
>>> But anyway, what you're talking about below, "the token the client uses t=
o update is profile" *IS* the Registration Access Token. That's all that tha=
t token is used for. You're not asking for it to go away, you're asking for i=
t to come from the Token Endpoint instead of the response from the Registrat=
ion                                     Endpoint. I don't see how the client=
 *can* get it from the normal token process without jumping through speciali=
zed hoops to make that happen. I've implemented the draft the way that it is=
 right now, both client and server side, and it works. Others have implement=
ed it, too. We've done interop testing, and it works. This is a proven patte=
rn                                     and from where I sit there is both ro=
ugh consensus and running code.
>>>=20
>>> I believe that I've already pointed out how the solutions you've propose=
d so far won't work in practice, for various reasons, many of which have alr=
eady been brought up and discussed previously. If you have another way for t=
he client to get its Registration Access Token, please propose it; but I hav=
en't seen anything yet that will fly.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>> Justin,
>>> =20
>>> This is my primary objection! We can't keep it straight. Their should be=
 no such thing as a registrstion access token!  Just the token the client ob=
tains to update its profile through the normal token request process.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-31, at 10:55, Justin Richer  wrote:
>>>=20
>>> Which token are you referring to here?
>>>=20
>>> If it's the Initial Registration Token, then you could get that through t=
he normal token server no problem. (The lifecycle writeups don't call this o=
ut explicitly but I would be willing to do so.) Or you could get it elsewher=
e. Doesn't matter, just like it doesn't matter with any other OAuth2 protect=
ed resource.
>>>=20
>>> If it's the Registration Access Token, then having the token come from t=
he token endpoint would require a lot more work and complexity on behalf of b=
oth of the client and server. Either you end up with public clients getting s=
ecrets they shouldn't need or with granting clients access to the client_cre=
dentials flow when they shouldn't actually have it. Plus it adds extra round=
 trips which don't buy you anything.
>>>=20
>>>  -- Justin
>>>=20
>>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>>> The preference is to have the access token for registration issued by th=
e normal token server rather                                               t=
hen by the registration endpoint.=20
>>> =20
>>> In the current draft it is obtained through a unique                    =
                           process and must outlive the client.=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-30, at 19:47,                                               "=
Richer, Justin P."  wrote:
>>>=20
>>> I don't understand any of the comments below -- it already *is* an OAuth=
2 protected resource without any special handling. Your access tokens can be=
 short-lived, long-lived, federated, structured, random blobs ... totally do=
esn't matter. They are access tokens being used to access a normal protected=
 resource. Full stop.
>>>=20
>>> Anything else is out of scope. The lifecycle discussions at the beginnin=
g are merely examples of some ways you *could* use it and are non-normative a=
nd non-exhaustive.
>>>=20
>>> You seem to be asking for something that's already in the draft.
>>>=20
>>>  -- Justin
>>>=20
>>> From: Phil Hunt [phil.hunt@oracle.com]
>>> Sent: Thursday, May 30, 2013 7:31 PM
>>> To: Richer, Justin P.
>>> Cc: John Bradley; oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.t=
xt
>>>=20
>>>=20
>>>=20
>>> Phil
>>>=20
>>> On 2013-05-30, at 16:11, "Richer, Justin P."         =
                                                   wrote:
>>>=20
>>> Comments inline, marked by [JR].
>>>=20
>>> From: Phil Hunt [phil.hunt@oracle.com]
>>> Sent: Thursday, May 30, 2013 5:25 PM
>>> To: Richer, Justin P.
>>> Cc: John Bradley; oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.t=
xt
>>>=20
>>> See below.
>>> Phil
>>> =20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>>>=20
>>>=20
>>> OK, I think see part of the hang up. I have not seen the scenario that y=
ou describe, where you trade a 3rd party token for a "local" token. I have s=
een where access tokens are federated directly at the PR. (Introspection let=
s you do some good things with that pattern.)
>=20

--Apple-Mail-4AD6487F-0F3E-4928-B29B-0C46DF9CAD1B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ok. You are correct. All versions inve=
nt a new method for issuing access tokens. 

Th=
is is not within the charter. 

Phil

On 2013-05-31,=
 at 15:40, Justin Richer <jricher@mi=
tre.org> wrote:


 =20
    
 =20
 =20
    I feel the need to clarify a couple erroneous things in Phil's
    statement:

    

      * To be clear, Draft 11 has the same Registration Access Token
    system that has been in place since draft 01, it is not inventing
    something new at the last minute as could be inferred from the
    statement below.

      * DynReg is using an absolutely standard OAuth 2 Bearer token as
    the Registration Access Token, it's just not coming from a Token
    Endpoint. However, since an OAuth Protected Resource doesn't care
    where its tokens come from so long as it can validate them, I don't
    see this as a problem -- this is a key point where Phil and I
    disagree.

    

     -- Justin

    

    
On 05/31/2013 03:33 PM, Phil Hunt
      wrote:

    

    

      
      
Don,

      


      

      
I am not proposing any change in meaning. If registration
        acces token issues by normal token server with scope
        registration everything is clear as it is for any other
        protected API. Draft 11 invents a whole new system. I strongly
        disagree with this.

        

        Phil

      


        On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetwor=
ks.com>
        wrote:

        

      

      

        

          
          
          
          

            
For
                something that was agreed to be parked a few hours ago,
                there sure seems to still be a lot of circular
                discussion.  Should we ask a mediator to intervene?

            
 

            
FWIW
                I believe that is a significantly strong reason to
                differentiate an access token that can access the
                registration information without having the ability to
                access protected data.  Especially given the implied
                strength of the =E2=80=9Cclient credential=E2=80=9D obtained=
 access
                token.  I have found it extremely confusing to users
                when explaining the difference between an access token
                obtained thorough an authorization code flow and a
                client credential flow, simply because they are both
                called an =E2=80=9Caccess token=E2=80=9D.  Changing the=
 meaning of an
                access token obtained through the client credential flow
                to mean it has the ability to update a registration,
                when a user may not want it to have access to protected
                data will only increase both the complexity of the
                access tokens as well as make their usage harder to
                explain to non-technical individuals who have to
                understand the differences between the access tokens
                obtained through the various flows.

            
 

            
Just
                my two cents.

            
 

            

              
Best
                  regards,

              
Don

              
Donald
                  F. Coffin

              
Founder/CTO

              
 

              
REMI
                  Networks

              
22751
                  El Prado Suite 6216

              
Rancho
                  Santa Margarita, CA  92688-3836
=

              
 

              
Phone:     
                  (949) 636-8571

              
Email:      
                  donald.coffin@reminetworks.com

            

            
 

            

              

                
From:
                    Phil Hunt [mailto:phil.hunt@oracle.com]
                    

                    Sent: Friday, May 31, 2013 11:11 AM

                    To: Justin Richer

                    Cc: oauth@ietf.org WG

                    Subject: Re: [OAUTH-WG] review comments on
                    draft-ietf-oauth-dyn-reg-11.txt

              

            

            
 

            

              
To be clear. 

            

            

              
 

            

            

              
It is two separate issues. 

            

            

              
 

            

            

              
1. Anonymous clients can easily be
                handled through policy config. 

            

            

              
 

            

            

              
2. Support for implicit clients needs
                to be discussed. The current proposal creates large
                negative value for the service provider and most would
                never allow in current form. Yes it gives each execution
                instance a new id, but that isnt what sp's want. It is a
                huge attack and management headache. Eliminate or
                propose a different solution. 

                

                Phil

            

            

              


                On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org>
                wrote:

            

            

              

                
I'm
                  not willing to write out an entire class of clients
                  from this spec, especially when we have stated use
                  cases for them doing dynamic registration.

                  

                  I'm sorry, but your proposed solution will simply not
                  work.

                  

                   -- Justin

                

                  
On 05/31/2013 01:56 PM, Phil Hunt
                    wrote:

                

                

                  

                    
Well the only client that
                      wouldn't have a credential is an implicit client.
                      An implicit client is transient and so would never
                      update. 

                      

                      Besides, as i have stated, implicit clients should
                      not use dyn reg. 

                  

                  

                    


                      Phil

                  

                  

                    

                      On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>=

                      wrote:

                  

                  

                    

                      
=
But
                        the outstanding question is: how do you get the
                        access token to access the created resource (IE:
                        the Registration Access Token)? You can't use
                        the client_credentials flow for a client with no
                        credentials!

                        

                         -- Justin

                        

                        

                      

                        
On 05/31/2013 12:58 PM,
                          Phil Hunt wrote:

                      

                      

                        

                          
Yes. I specified the
                            trivial solution to anonymous clients
                            earlier.

                        

                        

                          
 

                        

                        

                          
Even simpler. You don't
                            need an access token to create a new
                            resource. You just need one to access one.
                            That is just basic security config. 

                        

                        

                          


                            Phil

                        

                        

                          


                            On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>
                            wrote:

                        

                        

                          

                            
I agree that
                              we are going in circles, since I just was
                              going to bring up my counter argument of
                              "what about clients with no credentials?"
                              again, which *still* isn't addressed by
                              what you suggest doing, below. I also
                              believe that getting rid of the
                              Registration Access Token but using some
                              other token method would actually make the
                              spec larger, though I'd be glad to review
                              a concrete counter-proposal if you'd like
                              to write one. And the fact that OIDC is
                              doing it this way, and considered but
                              rejected the way that you're describing,
                              should say something to the WG here about
                              whether or not this is the right choice.
                              Rough consensus and running code, after
                              all.

                              

                              Regardless, I agree to park this issue and
                              leave the text as is. We'll move to the
                              next draft in the last call process
                              shortly, as I have a handful of
                              non-normative editorial changes that I
                              need to make, thanks to feedback from a
                              few folks.

                              

                              Again, thanks for your thorough review,
                              Phil, and I look forward to future
                              feedback.

                              

                               -- Justin

                            

                              
On 05/31/2013 12:28
                                PM, Phil Hunt wrote:

                            

                            

                              

                                
I disagree. 

                              

                              

                                
 
=

                              

                              

                                
There is absolutely
                                  no need for a registration access
                                  token. 

                              

                              

                                
 
=

                              

                              

                                
Get rid of it and
                                  just use access tokens as per 6749. If
                                  you can't follow 6749 and need new
                                  issuing methods, what are others to
                                  say regarding inventing new methods?<=
/o:p>

                              

                              

                                
 
=

                              

                              

                                
I have not heard a
                                  good reason for the special process or
                                  one good enough to warrant a new
                                  method for issuing an access token.
                                  Does the broader group realize this is
                                  what the spec says?

                              

                              

                                
 
=

                              

                              

                                
Yes, i heard a lot
                                  saying OIDC does it this way. But that
                                  is a political reason, not a technical
                                  reason. Still, compatibility is always
                                  a strong objective.  Even so, oidc
                                  could keep using their method just
                                  fine. There is no obligation here to
                                  do the same. 

                              

                              

                                
 
=

                              

                              

                                
The only reason so
                                  far was expiry of client creds. Well,
                                  why not require the client to update
                                  prior to expiry? It makes no sense to
                                  have another token with longer expiry.
                                  B'sides, even expired the client can
                                  re-register from scratch. =


                              

                              

                                
 
=

                              

                              

                                
Why force the
                                  client to persist multiple tokens and
                                  creds? That is far far too complex. <=
o:p>

                              

                              

                                
 
=

                              

                              

                                
Finally if you get
                                  rid of registration access token the
                                  spec size will drop roughly in half
                                  IMO. This suggests simplicity to me. =


                              

                              

                                
 
=

                              

                              

                                
Apologies for my
                                  rant. Maybe we should park this for
                                  now. We are going in circles. 

                                  

                                  Phil

                              

                              
                              

                                

                                  
Phil,

                                    

                                    We *can* keep it straight just fine,
                                    but I just need you to be clear
                                    about which part you're objecting to
                                    because the answers are different.
                                    Please use the terms as defined in
                                    the document so that we all know
                                    which component we're talking about.
                                    I'm sure you'd agree than in
                                    specification work such as this,
                                    precision of language and labels is
                                    key for communication between
                                    parties. This is precisely why
                                    there's a Terminology section right
                                    up front, so that when I say
                                    "Registration Access Token" you can
                                    know that I mean a very specific
                                    thing, and when I say "Initial
                                    Registration Token" I mean a very
                                    different specific thing. So I'm
                                    asking you, please, use the defined
                                    terms so that we can avoid this
                                    unnecessary confusion.

                                    

                                    But anyway, what you're talking
                                    about below, "the token the client
                                    uses to update is profile" *IS* the
                                    Registration Access Token. That's
                                    all that that token is used for.
                                    You're not asking for it to go away,
                                    you're asking for it to come from
                                    the Token Endpoint instead of the
                                    response from the Registration
                                    Endpoint. I don't see how the client
                                    *can* get it from the normal token
                                    process without jumping through
                                    specialized hoops to make that
                                    happen. I've implemented the draft
                                    the way that it is right now, both
                                    client and server side, and it
                                    works. Others have implemented it,
                                    too. We've done interop testing, and
                                    it works. This is a proven pattern
                                    and from where I sit there is both
                                    rough consensus and running code.

                                    

                                    I believe that I've already pointed
                                    out how the solutions you've
                                    proposed so far won't work in
                                    practice, for various reasons, many
                                    of which have already been brought
                                    up and discussed previously. If you
                                    have another way for the client to
                                    get its Registration Access Token,
                                    please propose it; but I haven't
                                    seen anything yet that will fly.

                                    

                                     -- Justin

                                  

                                    
On 05/31/2013
                                      11:10 AM, Phil Hunt wrote:<=
/p>
                                  

                                  

                                    

                                      
Justin,

                                    

                                    

                                      
 

                                    

                                    

                                      
This is my
                                        primary objection! We can't keep
                                        it straight. Their should be no
                                        such thing as a registrstion
                                        access token!  Just the token
                                        the client obtains to update its
                                        profile through the normal token
                                        request process. 

                                        

                                        Phil

                                    

                                    

                                      


                                        On 2013-05-31, at 10:55, Justin
                                        Richer <jricher@mitre.org>
                                        wrote:

                                    

                                    

                                      

                                        
Which
                                          token are you referring to
                                          here?

                                          

                                          If it's the Initial
                                          Registration Token, then you
                                          could get that through the
                                          normal token server no
                                          problem. (The lifecycle
                                          writeups don't call this out
                                          explicitly but I would be
                                          willing to do so.) Or you
                                          could get it elsewhere.
                                          Doesn't matter, just like it
                                          doesn't matter with any other
                                          OAuth2 protected resource.

                                          

                                          If it's the Registration
                                          Access Token, then having the
                                          token come from the token
                                          endpoint would require a lot
                                          more work and complexity on
                                          behalf of both of the client
                                          and server. Either you end up
                                          with public clients getting
                                          secrets they shouldn't need or
                                          with granting clients access
                                          to the client_credentials flow
                                          when they shouldn't actually
                                          have it. Plus it adds extra
                                          round trips which don't buy
                                          you anything.

                                          

                                           -- Justin

                                        

                                          
On
                                            05/31/2013 10:15 AM, Phil
                                            Hunt wrote:

                                        

                                        

                                          

                                            
The
                                              preference is to have the
                                              access token for
                                              registration issued by the
                                              normal token server rather
                                              then by the registration
                                              endpoint. 
=

                                          

                                          

                                            
&nbs=
p;

                                          

                                          

                                            
In the
                                              current draft it is
                                              obtained through a unique
                                              process and must outlive
                                              the client. 
                                          

                                          

                                            


                                              Phil

                                          

                                          

                                            


                                              On 2013-05-30, at 19:47,
                                              "Richer, Justin P." <jricher@mitre.org>
                                              wrote:

                                          

                                          

                                            

                                              

                                                
I
                                                    don't understand any
                                                    of the comments
                                                    below -- it already
                                                    *is* an OAuth2
                                                    protected resource
                                                    without any special
                                                    handling. Your
                                                    access tokens can be
                                                    short-lived,
                                                    long-lived,
                                                    federated,
                                                    structured, random
                                                    blobs ... totally
                                                    doesn't matter. They
                                                    are access tokens
                                                    being used to access
                                                    a normal protected
                                                    resource. Full stop.
=

                                                    

                                                    Anything else is out
                                                    of scope. The
                                                    lifecycle
                                                    discussions at the
                                                    beginning are merely
                                                    examples of some
                                                    ways you *could* use
                                                    it and are
                                                    non-normative and
                                                    non-exhaustive.

                                                    

                                                    You seem to be
                                                    asking for something
                                                    that's already in
                                                    the draft.

                                                    

                                                     -- Justin

                                                

                                                  

                                                      

                                                  

                                                    
From:
                                                        Phil Hunt [phil.hunt@oracle.com=
]

                                                        Sent:
                                                        Thursday, May
                                                        30, 2013 7:31 PM
=

                                                        To:
                                                        Richer, Justin
                                                        P.

                                                        Cc: John
                                                        Bradley; oauth@ietf.org WG

                                                        Subject:
                                                        Re: [OAUTH-WG]
                                                        review comments
                                                        on
                                                        draft-ietf-oauth-dyn=
-reg-11.txt

                                                  

                                                  

                                                    

                                                      


                                                          

                                                          Phil

                                                    

                                                    

                                                      


                                                          On 2013-05-30,
                                                          at 16:11,
                                                          "Richer,
                                                          Justin P."
                                                          <jricher@mi=
tre.org>
                                                          wrote:<=
/span>

                                                    

                                                    

                                                      

                                                        

                                                          
Comments
                                                          inline, marked
                                                          by [JR].

                                                          

                                                          

                                                          

                                                          

                                                          
From:
                                                          Phil Hunt [=
phil.hunt@oracle.com]

                                                          Sent:
                                                          Thursday, May
                                                          30, 2013 5:25
                                                          PM

                                                          To:
                                                          Richer, Justin
                                                          P.

                                                          Cc:
                                                          John Bradley;
                                                          oauth@ietf.org WG

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          review
                                                          comments on
                                                          draft-ietf-oauth-d=
yn-reg-11.txt

                                                          

                                                          

                                                          
See below.

                                                          
                                                          
 

                                                          

                                                          

                                                          
On 2013-05-30, at 2:09 PM, Justin Richer wr=
ote:

                                                          

                                                          


                                                          

                                                          =


                                                          

                                                          
OK, I think see part of the hang up. I have=
 not seen
                                                          the scenario
                                                          that you
                                                          describe,
                                                          where you
                                                          trade a 3rd
                                                          party token
                                                          for a "local"
                                                          token. I have
                                                          seen where
                                                          access tokens
                                                          are federated
                                                          directly at
                                                          the PR.
                                                          (Introspection
                                                          lets you do
                                                          some good
                                                          things with
                                                          that pattern.)
                                                          =


                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                            
 

                          

                        

                      

                      
 

                    

                  

                

                
 

              

            

          

        

      

    

    

 =20


=

--Apple-Mail-4AD6487F-0F3E-4928-B29B-0C46DF9CAD1B--

From jricher@mitre.org  Fri May 31 12:56:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF67321F919D for ; Fri, 31 May 2013 12:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.348
X-Spam-Level: 
X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPpfnEox+2Vk for ; Fri, 31 May 2013 12:56:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E70221F90AC for ; Fri, 31 May 2013 12:56:15 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2DD9C1F031E; Fri, 31 May 2013 15:56:15 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 126D01F039C; Fri, 31 May 2013 15:56:15 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 15:56:14 -0400
Message-ID: <51A90035.4010404@mitre.org>
Date: Fri, 31 May 2013 15:55:33 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Donald F Coffin 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com>	<51A7A18F.1040104@mitre.org>	<4CCD92A5-0800-4E4C-8952-C8B88E22C811@oracle.com>	<51A7ADAE.4070005@mitre.org>	<62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>	<51A7C00B.6050409@mitre.org>	<78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>		<18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>		<77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>	<51A8B9C4.8020200! @mitre.org>		<51A8C0ED.6040607@mitre.org>	<87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>	<51A8D123.3090103@mit! re.org>		<51A8E0BD.9090908@mitre.org>	<521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1! 030309@mitre.org> <75 C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com>
In-Reply-To: <002701ce5e33$620faaa0$262effe0$@reminetworks.com>
Content-Type: multipart/alternative; boundary="------------080300050806040806050800"
X-Originating-IP: [129.83.31.56]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 19:56:21 -0000

--------------080300050806040806050800
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Don, thank you, this articulates one of the problems I have with using 
the client_credentials flow to get the registration access token -- in 
order for it to be deployed securely, you'd need to know that for a 
particular client, it would have access to the special registration 
access token scope but not others. I think it's very dangerous to say 
that all clients now have access to the client_credentials flow unless 
you can draw a very sharp delineation between these two uses. And again, 
it still doesn't work for clients that don't have credentials, so to me 
it's a non-starter even if you *could* build a secure system with it.

But you're right -- we're still talking in circles and we've agreed to 
park it. Parking now. :)

  -- Justin


On 05/31/2013 03:16 PM, Donald F Coffin wrote:
>
> For something that was agreed to be parked a few hours ago, there sure 
> seems to still be a lot of circular discussion. Should we ask a 
> mediator to intervene?
>
> FWIW I believe that is a significantly strong reason to differentiate 
> an access token that can access the registration information without 
> having the ability to access protected data.  Especially given the 
> implied strength of the “client credential” obtained access token. I 
> have found it extremely confusing to users when explaining the 
> difference between an access token obtained thorough an authorization 
> code flow and a client credential flow, simply because they are both 
> called an “access token”.  Changing the meaning of an access token 
> obtained through the client credential flow to mean it has the ability 
> to update a registration, when a user may not want it to have access 
> to protected data will only increase both the complexity of the access 
> tokens as well as make their usage harder to explain to non-technical 
> individuals who have to understand the differences between the access 
> tokens obtained through the various flows.
>
> Just my two cents.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
> *From:*Phil Hunt [mailto:phil.hunt@oracle.com]
> *Sent:* Friday, May 31, 2013 11:11 AM
> *To:* Justin Richer
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] review comments on 
> draft-ietf-oauth-dyn-reg-11.txt
>
> To be clear.
>
> It is two separate issues.
>
> 1. Anonymous clients can easily be handled through policy config.
>
> 2. Support for implicit clients needs to be discussed. The current 
> proposal creates large negative value for the service provider and 
> most would never allow in current form. Yes it gives each execution 
> instance a new id, but that isnt what sp's want. It is a huge attack 
> and management headache. Eliminate or propose a different solution.
>
> Phil
>
>
> On 2013-05-31, at 13:58, Justin Richer  > wrote:
>
>     I'm not willing to write out an entire class of clients from this
>     spec, especially when we have stated use cases for them doing
>     dynamic registration.
>
>     I'm sorry, but your proposed solution will simply not work.
>
>      -- Justin
>
>     On 05/31/2013 01:56 PM, Phil Hunt wrote:
>
>         Well the only client that wouldn't have a credential is an
>         implicit client. An implicit client is transient and so would
>         never update.
>
>         Besides, as i have stated, implicit clients should not use dyn
>         reg.
>
>
>         Phil
>
>
>         On 2013-05-31, at 13:41, Justin Richer          > wrote:
>
>             But the outstanding question is: how do you get the access
>             token to access the created resource (IE: the Registration
>             Access Token)? You can't use the client_credentials flow
>             for a client with no credentials!
>
>              -- Justin
>
>             On 05/31/2013 12:58 PM, Phil Hunt wrote:
>
>                 Yes. I specified the trivial solution to anonymous
>                 clients earlier.
>
>                 Even simpler. You don't need an access token to create
>                 a new resource. You just need one to access one. That
>                 is just basic security config.
>
>
>                 Phil
>
>
>                 On 2013-05-31, at 12:34, Justin Richer
>                 > wrote:
>
>                     I agree that we are going in circles, since I just
>                     was going to bring up my counter argument of "what
>                     about clients with no credentials?" again, which
>                     *still* isn't addressed by what you suggest doing,
>                     below. I also believe that getting rid of the
>                     Registration Access Token but using some other
>                     token method would actually make the spec larger,
>                     though I'd be glad to review a concrete
>                     counter-proposal if you'd like to write one. And
>                     the fact that OIDC is doing it this way, and
>                     considered but rejected the way that you're
>                     describing, should say something to the WG here
>                     about whether or not this is the right choice.
>                     Rough consensus and running code, after all.
>
>                     Regardless, I agree to park this issue and leave
>                     the text as is. We'll move to the next draft in
>                     the last call process shortly, as I have a handful
>                     of non-normative editorial changes that I need to
>                     make, thanks to feedback from a few folks.
>
>                     Again, thanks for your thorough review, Phil, and
>                     I look forward to future feedback.
>
>                      -- Justin
>
>                     On 05/31/2013 12:28 PM, Phil Hunt wrote:
>
>                         I disagree.
>
>                         There is absolutely no need for a registration
>                         access token.
>
>                         Get rid of it and just use access tokens as
>                         per 6749. If you can't follow 6749 and need
>                         new issuing methods, what are others to say
>                         regarding inventing new methods?
>
>                         I have not heard a good reason for the special
>                         process or one good enough to warrant a new
>                         method for issuing an access token. Does the
>                         broader group realize this is what the spec says?
>
>                         Yes, i heard a lot saying OIDC does it this
>                         way. But that is a political reason, not a
>                         technical reason. Still, compatibility is
>                         always a strong objective.  Even so, oidc
>                         could keep using their method just fine. There
>                         is no obligation here to do the same.
>
>                         The only reason so far was expiry of client
>                         creds. Well, why not require the client to
>                         update prior to expiry? It makes no sense to
>                         have another token with longer expiry.
>                         B'sides, even expired the client can
>                         re-register from scratch.
>
>                         Why force the client to persist multiple
>                         tokens and creds? That is far far too complex.
>
>                         Finally if you get rid of registration access
>                         token the spec size will drop roughly in half
>                         IMO. This suggests simplicity to me.
>
>                         Apologies for my rant. Maybe we should park
>                         this for now. We are going in circles.
>
>                         Phil
>
>
>                         On 2013-05-31, at 11:25, Justin Richer
>                         >
>                         wrote:
>
>                             Phil,
>
>                             We *can* keep it straight just fine, but I
>                             just need you to be clear about which part
>                             you're objecting to because the answers
>                             are different. Please use the terms as
>                             defined in the document so that we all
>                             know which component we're talking about.
>                             I'm sure you'd agree than in specification
>                             work such as this, precision of language
>                             and labels is key for communication
>                             between parties. This is precisely why
>                             there's a Terminology section right up
>                             front, so that when I say "Registration
>                             Access Token" you can know that I mean a
>                             very specific thing, and when I say
>                             "Initial Registration Token" I mean a very
>                             different specific thing. So I'm asking
>                             you, please, use the defined terms so that
>                             we can avoid this unnecessary confusion.
>
>                             But anyway, what you're talking about
>                             below, "the token the client uses to
>                             update is profile" *IS* the Registration
>                             Access Token. That's all that that token
>                             is used for. You're not asking for it to
>                             go away, you're asking for it to come from
>                             the Token Endpoint instead of the response
>                             from the Registration Endpoint. I don't
>                             see how the client *can* get it from the
>                             normal token process without jumping
>                             through specialized hoops to make that
>                             happen. I've implemented the draft the way
>                             that it is right now, both client and
>                             server side, and it works. Others have
>                             implemented it, too. We've done interop
>                             testing, and it works. This is a proven
>                             pattern and from where I sit there is both
>                             rough consensus and running code.
>
>                             I believe that I've already pointed out
>                             how the solutions you've proposed so far
>                             won't work in practice, for various
>                             reasons, many of which have already been
>                             brought up and discussed previously. If
>                             you have another way for the client to get
>                             its Registration Access Token, please
>                             propose it; but I haven't seen anything
>                             yet that will fly.
>
>                              -- Justin
>
>                             On 05/31/2013 11:10 AM, Phil Hunt wrote:
>
>                                 Justin,
>
>                                 This is my primary objection! We can't
>                                 keep it straight. Their should be no
>                                 such thing as a registrstion access
>                                 token!  Just the token the client
>                                 obtains to update its profile through
>                                 the normal token request process.
>
>                                 Phil
>
>
>                                 On 2013-05-31, at 10:55, Justin Richer
>                                                                  > wrote:
>
>                                     Which token are you referring to here?
>
>                                     If it's the Initial Registration
>                                     Token, then you could get that
>                                     through the normal token server no
>                                     problem. (The lifecycle writeups
>                                     don't call this out explicitly but
>                                     I would be willing to do so.) Or
>                                     you could get it elsewhere.
>                                     Doesn't matter, just like it
>                                     doesn't matter with any other
>                                     OAuth2 protected resource.
>
>                                     If it's the Registration Access
>                                     Token, then having the token come
>                                     from the token endpoint would
>                                     require a lot more work and
>                                     complexity on behalf of both of
>                                     the client and server. Either you
>                                     end up with public clients getting
>                                     secrets they shouldn't need or
>                                     with granting clients access to
>                                     the client_credentials flow when
>                                     they shouldn't actually have it.
>                                     Plus it adds extra round trips
>                                     which don't buy you anything.
>
>                                      -- Justin
>
>                                     On 05/31/2013 10:15 AM, Phil Hunt
>                                     wrote:
>
>                                         The preference is to have the
>                                         access token for registration
>                                         issued by the normal token
>                                         server rather then by the
>                                         registration endpoint.
>
>                                         In the current draft it is
>                                         obtained through a unique
>                                         process and must outlive the
>                                         client.
>
>
>                                         Phil
>
>
>                                         On 2013-05-30, at 19:47,
>                                         "Richer, Justin P."
>                                                                                  > wrote:
>
>                                             I don't understand any of
>                                             the comments below -- it
>                                             already *is* an OAuth2
>                                             protected resource without
>                                             any special handling. Your
>                                             access tokens can be
>                                             short-lived, long-lived,
>                                             federated, structured,
>                                             random blobs ... totally
>                                             doesn't matter. They are
>                                             access tokens being used
>                                             to access a normal
>                                             protected resource. Full stop.
>
>                                             Anything else is out of
>                                             scope. The lifecycle
>                                             discussions at the
>                                             beginning are merely
>                                             examples of some ways you
>                                             *could* use it and are
>                                             non-normative and
>                                             non-exhaustive.
>
>                                             You seem to be asking for
>                                             something that's already
>                                             in the draft.
>
>                                              -- Justin
>
>                                             ------------------------------------------------------------------------
>
>                                             *From:*Phil Hunt
>                                             [phil.hunt@oracle.com
>                                             ]
>                                             *Sent:* Thursday, May 30,
>                                             2013 7:31 PM
>                                             *To:* Richer, Justin P.
>                                             *Cc:* John Bradley;
>                                             oauth@ietf.org
>                                              WG
>                                             *Subject:* Re: [OAUTH-WG]
>                                             review comments on
>                                             draft-ietf-oauth-dyn-reg-11.txt
>
>
>
>                                             Phil
>
>
>                                             On 2013-05-30, at 16:11,
>                                             "Richer, Justin P."
>                                                                                          > wrote:
>
>                                                 Comments inline,
>                                                 marked by [JR].
>
>                                                 ------------------------------------------------------------------------
>
>                                                 *From:*Phil Hunt
>                                                 [phil.hunt@oracle.com
>                                                 ]
>                                                 *Sent:* Thursday, May
>                                                 30, 2013 5:25 PM
>                                                 *To:* Richer, Justin P.
>                                                 *Cc:* John Bradley;
>                                                 oauth@ietf.org
>                                                  WG
>                                                 *Subject:* Re:
>                                                 [OAUTH-WG] review
>                                                 comments on
>                                                 draft-ietf-oauth-dyn-reg-11.txt
>
>                                                 See below.
>
>                                                 Phil
>
>                                                 @independentid
>
>                                                 www.independentid.com
>                                                 
>
>                                                 phil.hunt@oracle.com
>                                                 
>
>                                                 On 2013-05-30, at 2:09
>                                                 PM, Justin Richer wrote:
>
>
>
>                                                 OK, I think see part
>                                                 of the hang up. I have
>                                                 not seen the scenario
>                                                 that you describe,
>                                                 where you trade a 3rd
>                                                 party token for a
>                                                 "local" token. I have
>                                                 seen where access
>                                                 tokens are federated
>                                                 directly at the PR.
>                                                 (Introspection lets
>                                                 you do some good
>                                                 things with that
>                                                 pattern.)
>


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


  
    
  
  
    Don, thank you, this articulates one of the problems I have with
    using the client_credentials flow to get the registration access
    token -- in order for it to be deployed securely, you'd need to know
    that for a particular client, it would have access to the special
    registration access token scope but not others. I think it's very
    dangerous to say that all clients now have access to the
    client_credentials flow unless you can draw a very sharp delineation
    between these two uses. And again, it still doesn't work for clients
    that don't have credentials, so to me it's a non-starter even if you
    *could* build a secure system with it.

    

    But you're right -- we're still talking in circles and we've agreed
    to park it. Parking now. :)

    

     -- Justin

    

    

    
On 05/31/2013 03:16 PM, Donald F Coffin
      wrote:

    

    

      
      
      
      
      

        
For
            something that was agreed to be parked a few hours ago,
            there sure seems to still be a lot of circular discussion. 
            Should we ask a mediator to intervene?

        
 

        
FWIW
            I believe that is a significantly strong reason to
            differentiate an access token that can access the
            registration information without having the ability to
            access protected data.  Especially given the implied
            strength of the “client credential” obtained access token. 
            I have found it extremely confusing to users when explaining
            the difference between an access token obtained thorough an
            authorization code flow and a client credential flow, simply
            because they are both called an “access token”.  Changing
            the meaning of an access token obtained through the client
            credential flow to mean it has the ability to update a
            registration, when a user may not want it to have access to
            protected data will only increase both the complexity of the
            access tokens as well as make their usage harder to explain
            to non-technical individuals who have to understand the
            differences between the access tokens obtained through the
            various flows.

        
 

        
Just
            my two cents.

        
 

        

          
Best
              regards,

          
Don

          
Donald
              F. Coffin

          
Founder/CTO

          
 

          
REMI
              Networks

          
22751
              El Prado Suite 6216

          
Rancho
              Santa Margarita, CA  92688-3836

          
 

          
Phone:     
              (949) 636-8571

          
Email:      
              donald.coffin@reminetworks.com

        

        
 

        

          

            
From:
                Phil Hunt [mailto:phil.hunt@oracle.com] 

                Sent: Friday, May 31, 2013 11:11 AM

                To: Justin Richer

                Cc: oauth@ietf.org WG

                Subject: Re: [OAUTH-WG] review comments on
                draft-ietf-oauth-dyn-reg-11.txt

          

        

        
 

        

          
To be clear. 

        

        

          
 

        

        

          
It is two separate issues. 

        

        

          
 

        

        

          
1. Anonymous clients can easily be
            handled through policy config. 

        

        

          
 

        

        

          
2. Support for implicit clients needs to
            be discussed. The current proposal creates large negative
            value for the service provider and most would never allow in
            current form. Yes it gives each execution instance a new id,
            but that isnt what sp's want. It is a huge attack and
            management headache. Eliminate or propose a different
            solution. 

            

            Phil

        

        

          


            On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org>
            wrote:

        

        

          

            
I'm not
              willing to write out an entire class of clients from this
              spec, especially when we have stated use cases for them
              doing dynamic registration.

              

              I'm sorry, but your proposed solution will simply not
              work.

              

               -- Justin

            

              
On 05/31/2013 01:56 PM, Phil Hunt
                wrote:

            

            

              

                
Well the only client that wouldn't
                  have a credential is an implicit client. An implicit
                  client is transient and so would never update. 

                  

                  Besides, as i have stated, implicit clients should not
                  use dyn reg. 

              

              

                


                  Phil

              

              

                


                  On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org>
                  wrote:

              

              

                

                  
But
                    the outstanding question is: how do you get the
                    access token to access the created resource (IE: the
                    Registration Access Token)? You can't use the
                    client_credentials flow for a client with no
                    credentials!

                    

                     -- Justin

                    

                    

                  

                    
On 05/31/2013 12:58 PM, Phil
                      Hunt wrote:

                  

                  

                    

                      
Yes. I specified the trivial
                        solution to anonymous clients earlier.

                    

                    

                      
 

                    

                    

                      
Even simpler. You don't need
                        an access token to create a new resource. You
                        just need one to access one. That is just basic
                        security config. 

                    

                    

                      


                        Phil

                    

                    

                      


                        On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org>
                        wrote:

                    

                    

                      

                        
I agree that we
                          are going in circles, since I just was going
                          to bring up my counter argument of "what about
                          clients with no credentials?" again, which
                          *still* isn't addressed by what you suggest
                          doing, below. I also believe that getting rid
                          of the Registration Access Token but using
                          some other token method would actually make
                          the spec larger, though I'd be glad to review
                          a concrete counter-proposal if you'd like to
                          write one. And the fact that OIDC is doing it
                          this way, and considered but rejected the way
                          that you're describing, should say something
                          to the WG here about whether or not this is
                          the right choice. Rough consensus and running
                          code, after all.

                          

                          Regardless, I agree to park this issue and
                          leave the text as is. We'll move to the next
                          draft in the last call process shortly, as I
                          have a handful of non-normative editorial
                          changes that I need to make, thanks to
                          feedback from a few folks.

                          

                          Again, thanks for your thorough review, Phil,
                          and I look forward to future feedback.

                          

                           -- Justin

                        

                          
On 05/31/2013 12:28 PM,
                            Phil Hunt wrote:

                        

                        

                          

                            
I disagree. 

                          

                          

                            
 

                          

                          

                            
There is absolutely no
                              need for a registration access token. 

                          

                          

                            
 

                          

                          

                            
Get rid of it and just
                              use access tokens as per 6749. If you
                              can't follow 6749 and need new issuing
                              methods, what are others to say regarding
                              inventing new methods?

                          

                          

                            
 

                          

                          

                            
I have not heard a good
                              reason for the special process or one good
                              enough to warrant a new method for issuing
                              an access token. Does the broader group
                              realize this is what the spec says?

                          

                          

                            
 

                          

                          

                            
Yes, i heard a lot
                              saying OIDC does it this way. But that is
                              a political reason, not a technical
                              reason. Still, compatibility is always a
                              strong objective.  Even so, oidc could
                              keep using their method just fine. There
                              is no obligation here to do the same. 

                          

                          

                            
 

                          

                          

                            
The only reason so far
                              was expiry of client creds. Well, why not
                              require the client to update prior to
                              expiry? It makes no sense to have another
                              token with longer expiry. B'sides, even
                              expired the client can re-register from
                              scratch. 

                          

                          

                            
 

                          

                          

                            
Why force the client to
                              persist multiple tokens and creds? That is
                              far far too complex. 

                          

                          

                            
 

                          

                          

                            
Finally if you get rid
                              of registration access token the spec size
                              will drop roughly in half IMO. This
                              suggests simplicity to me. 

                          

                          

                            
 

                          

                          

                            
Apologies for my rant.
                              Maybe we should park this for now. We are
                              going in circles. 

                              

                              Phil

                          

                          

                            


                              On 2013-05-31, at 11:25, Justin Richer
                              <jricher@mitre.org>
                              wrote:

                          

                          

                            

                              
Phil,

                                

                                We *can* keep it straight just fine, but
                                I just need you to be clear about which
                                part you're objecting to because the
                                answers are different. Please use the
                                terms as defined in the document so that
                                we all know which component we're
                                talking about. I'm sure you'd agree than
                                in specification work such as this,
                                precision of language and labels is key
                                for communication between parties. This
                                is precisely why there's a Terminology
                                section right up front, so that when I
                                say "Registration Access Token" you can
                                know that I mean a very specific thing,
                                and when I say "Initial Registration
                                Token" I mean a very different specific
                                thing. So I'm asking you, please, use
                                the defined terms so that we can avoid
                                this unnecessary confusion.

                                

                                But anyway, what you're talking about
                                below, "the token the client uses to
                                update is profile" *IS* the Registration
                                Access Token. That's all that that token
                                is used for. You're not asking for it to
                                go away, you're asking for it to come
                                from the Token Endpoint instead of the
                                response from the Registration Endpoint.
                                I don't see how the client *can* get it
                                from the normal token process without
                                jumping through specialized hoops to
                                make that happen. I've implemented the
                                draft the way that it is right now, both
                                client and server side, and it works.
                                Others have implemented it, too. We've
                                done interop testing, and it works. This
                                is a proven pattern and from where I sit
                                there is both rough consensus and
                                running code.

                                

                                I believe that I've already pointed out
                                how the solutions you've proposed so far
                                won't work in practice, for various
                                reasons, many of which have already been
                                brought up and discussed previously. If
                                you have another way for the client to
                                get its Registration Access Token,
                                please propose it; but I haven't seen
                                anything yet that will fly.

                                

                                 -- Justin

                              

                                
On 05/31/2013 11:10
                                  AM, Phil Hunt wrote:

                              

                              

                                

                                  
Justin,

                                

                                

                                  
 

                                

                                

                                  
This is my
                                    primary objection! We can't keep it
                                    straight. Their should be no such
                                    thing as a registrstion access
                                    token!  Just the token the client
                                    obtains to update its profile
                                    through the normal token request
                                    process. 

                                    

                                    Phil

                                

                                

                                  


                                    On 2013-05-31, at 10:55, Justin
                                    Richer <jricher@mitre.org>
                                    wrote:

                                

                                

                                  

                                    
Which
                                      token are you referring to here?

                                      

                                      If it's the Initial Registration
                                      Token, then you could get that
                                      through the normal token server no
                                      problem. (The lifecycle writeups
                                      don't call this out explicitly but
                                      I would be willing to do so.) Or
                                      you could get it elsewhere.
                                      Doesn't matter, just like it
                                      doesn't matter with any other
                                      OAuth2 protected resource.

                                      

                                      If it's the Registration Access
                                      Token, then having the token come
                                      from the token endpoint would
                                      require a lot more work and
                                      complexity on behalf of both of
                                      the client and server. Either you
                                      end up with public clients getting
                                      secrets they shouldn't need or
                                      with granting clients access to
                                      the client_credentials flow when
                                      they shouldn't actually have it.
                                      Plus it adds extra round trips
                                      which don't buy you anything.

                                      

                                       -- Justin

                                    

                                      
On 05/31/2013
                                        10:15 AM, Phil Hunt wrote:

                                    

                                    

                                      

                                        
The
                                          preference is to have the
                                          access token for registration
                                          issued by the normal token
                                          server rather then by the
                                          registration endpoint. 

                                      

                                      

                                        
 

                                      

                                      

                                        
In the
                                          current draft it is obtained
                                          through a unique process and
                                          must outlive the client. 

                                      

                                      

                                        


                                          Phil

                                      

                                      

                                        


                                          On 2013-05-30, at 19:47,
                                          "Richer, Justin P." <jricher@mitre.org>
                                          wrote:

                                      

                                      

                                        

                                          

                                            
I
                                                don't understand any of
                                                the comments below -- it
                                                already *is* an OAuth2
                                                protected resource
                                                without any special
                                                handling. Your access
                                                tokens can be
                                                short-lived, long-lived,
                                                federated, structured,
                                                random blobs ... totally
                                                doesn't matter. They are
                                                access tokens being used
                                                to access a normal
                                                protected resource. Full
                                                stop.

                                                

                                                Anything else is out of
                                                scope. The lifecycle
                                                discussions at the
                                                beginning are merely
                                                examples of some ways
                                                you *could* use it and
                                                are non-normative and
                                                non-exhaustive.

                                                

                                                You seem to be asking
                                                for something that's
                                                already in the draft.

                                                

                                                 -- Justin

                                            

                                              

                                                  

                                              

                                                
From:
                                                    Phil Hunt [phil.hunt@oracle.com]

                                                    Sent:
                                                    Thursday, May 30,
                                                    2013 7:31 PM

                                                    To: Richer,
                                                    Justin P.

                                                    Cc: John
                                                    Bradley; oauth@ietf.org WG

                                                    Subject: Re:
                                                    [OAUTH-WG] review
                                                    comments on
                                                    draft-ietf-oauth-dyn-reg-11.txt

                                              

                                              

                                                

                                                  


                                                      

                                                      Phil

                                                

                                                

                                                  


                                                      On 2013-05-30, at
                                                      16:11, "Richer,
                                                      Justin P." <jricher@mitre.org>
                                                      wrote:

                                                

                                                

                                                  

                                                    

                                                      
Comments
                                                          inline, marked
                                                          by [JR].

                                                      

                                                        

                                                          

                                                        

                                                          
From:
                                                          Phil Hunt [phil.hunt@oracle.com]

                                                          Sent:
                                                          Thursday, May
                                                          30, 2013 5:25
                                                          PM

                                                          To:
                                                          Richer, Justin
                                                          P.

                                                          Cc:
                                                          John Bradley;
                                                          oauth@ietf.org WG

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          review
                                                          comments on
                                                          draft-ietf-oauth-dyn-reg-11.txt

                                                        

                                                        

                                                          
See below.

                                                          

                                                          

                                                          
                                                          
 

                                                          

                                                          
 

                                                          

                                                          
 

                                                          

                                                          

                                                          
On 2013-05-30, at 2:09 PM, Justin Richer wrote:

                                                          

                                                          


                                                          

                                                          

                                                          

                                                          
OK, I think see part of the hang up. I have not seen
                                                          the scenario
                                                          that you
                                                          describe,
                                                          where you
                                                          trade a 3rd
                                                          party token
                                                          for a "local"
                                                          token. I have
                                                          seen where
                                                          access tokens
                                                          are federated
                                                          directly at
                                                          the PR.
                                                          (Introspection
                                                          lets you do
                                                          some good
                                                          things with
                                                          that pattern.)
                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        
 

                      

                    

                  

                  
 

                

              

            

            
 

          

        

      

    

    

  


--------------080300050806040806050800--

From donald.coffin@reminetworks.com  Fri May 31 13:06:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF18B21F853A for ; Fri, 31 May 2013 13:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.664
X-Spam-Level: 
X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqaIgzUliMTB for ; Fri, 31 May 2013 13:06:21 -0700 (PDT)
Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id C1FF621F960F for ; Fri, 31 May 2013 13:06:20 -0700 (PDT)
Received: (qmail 21721 invoked by uid 0); 31 May 2013 20:06:11 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 31 May 2013 20:06:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=lzNq+UllP4WgAP6bYbLUlKOEwo/KaQa4Yos/WLlPVYc=;  b=nGNpN7cR9rQc4UH/IRvJ9mc5TEZSBHW5hT9T6XIGmu2kJLn9qTmL5dc2eZvb1cZ7gnJ4bX8C/PcyVLnE6HqoBxVp7eUaZWg34APmvXVxOJFGPuaY1c6AbxHj4xwkswTg;
Received: from [68.4.207.246] (port=1339 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1UiVaU-0007Qy-UF; Fri, 31 May 2013 14:06:11 -0600
From: "Donald F Coffin" 
To: "'Justin Richer'" , "'Phil Hunt'" 
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com>	<51A7ADAE.4070005@mitre.org>	<62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com>	<51A7C00B.6050409@mitre.org>	<78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com>		<18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com>		<77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com>	<51A8B9C4.8020200! @mitre.org>		<51A8C0ED.6040607@mitre.org>	<87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com>	<51A8D123.3090103@mit! re.org>		<51A8E0BD.9090908@mitre.org>	<521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <51A8E4B2.1!	! !	030309@mitre.org> <75	C87F6C-4388-482C-ABE9-216FB63FE926@oracle.com>	<002701ce5e33$620faaa0$262effe0$@reminetworks.com>	<0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org>
In-Reply-To: <51A8FCA6.9050109@mitre.org>
Date: Fri, 31 May 2013 13:04:03 -0700
Message-ID: <004401ce5e3a$01854b70$048fe250$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01CE5DFF.552B2E60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHkLb5nIhERHX9TmIR7UaHRfNz2VwIHF/ecAhl9E3sCbvrZkgMYZOkUASHTdJEC37U7vwIQuyEwAzeEOlcCyLp0bAH44DYFAnOEmncCbvShZwDkIMpbAWUZshQBuXlFrwHzbSNJAdYGcOoDBY0CSwEjMm/jAdjpr64BxmnIqJeSw2sA
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.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, 31 May 2013 20:06:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0045_01CE5DFF.552B2E60
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

See my comments inline [DFC]

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Justin Richer [mailto:jricher@mitre.org]=20
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt

=20

I feel the need to clarify a couple erroneous things in Phil's =
statement:

  * To be clear, Draft 11 has the same Registration Access Token system =
that has been in place since draft 01, it is not inventing something new =
at the last minute as could be inferred from the statement below.

[DFC]  I agree with Justin.  There is nothing new in draft 11 regarding =
Registration Access Tokens that wasn=E2=80=99t in the initial draft.  It =
appears because Phil hasn=E2=80=99t been following the proposed drafts =
until the last call he is now raising an issue no one in the WG saw as =
an issue.  That=E2=80=99s not to say his point isn=E2=80=99t valid, but =
the discussion continues to go all over the map between =
=E2=80=9Clocal=E2=80=9D and =E2=80=9Cfederated=E2=80=9D tokens, usage of =
the RFC6749 =E2=80=9CToken=E2=80=9D endpoint, etc.  It would be great if =
all of Phil=E2=80=99s points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense =
or even comprehend the point being discussed.


  * DynReg is using an absolutely standard OAuth 2 Bearer token as the =
Registration Access Token, it's just not coming from a Token Endpoint. =
However, since an OAuth Protected Resource doesn't care where its tokens =
come from so long as it can validate them, I don't see this as a problem =
-- this is a key point where Phil and I disagree.

[DFC]  I understand the disagreement, but I have not seen a proposal =
from Phil that would describe the differences between the two =
perspectives other than to say that the Dynamic Registration should use =
the Token endpoint defined in RFC6749, which does not    discuss dynamic =
registration.  Phil=E2=80=99s point as I understand it is that there =
should be no difference between an access token used to access resource =
owner protected data and the registration structure, which I do not =
agree with.  As I said in the previous
            response, my users do NOT want to provide implied access to =
resource owner protected data just because a client is creating a =
registration with an AS.  This would be the situation if the client =
credential flow is used to register an application.  Since our
            implementation does NOT support the implicit flow, that use =
case is one we have elected NOT to support.

            [DFC]  I repeat my initial comment, this conversation has =
been a circular exchange now for the past few days without any =
appearance of an alternative option to resolve the issues.


 -- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:

Don,

=20

I am not proposing any change in meaning. If registration acces token =
issues by normal token server with scope registration everything is =
clear as it is for any other protected API. Draft 11 invents a whole new =
system. I strongly disagree with this.

Phil


On 2013-05-31, at 15:16, Donald F Coffin =
 wrote:

For something that was agreed to be parked a few hours ago, there sure =
seems to still be a lot of circular discussion.  Should we ask a =
mediator to intervene?

=20

FWIW I believe that is a significantly strong reason to differentiate an =
access token that can access the registration information without having =
the ability to access protected data.  Especially given the implied =
strength of the =E2=80=9Cclient credential=E2=80=9D obtained access =
token.  I have found it extremely confusing to users when explaining the =
difference between an access token obtained thorough an authorization =
code flow and a client credential flow, simply because they are both =
called an =E2=80=9Caccess token=E2=80=9D.  Changing the meaning of an =
access token obtained through the client credential flow to mean it has =
the ability to update a registration, when a user may not want it to =
have access to protected data will only increase both the complexity of =
the access tokens as well as make their usage harder to explain to =
non-technical individuals who have to understand the differences between =
the access tokens obtained through the various flows.

=20

Just my two cents.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

From: Phil Hunt [mailto:phil.hunt@oracle.com]=20
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt

=20

To be clear.=20

=20

It is two separate issues.=20

=20

1. Anonymous clients can easily be handled through policy config.=20

=20

2. Support for implicit clients needs to be discussed. The current =
proposal creates large negative value for the service provider and most =
would never allow in current form. Yes it gives each execution instance =
a new id, but that isnt what sp's want. It is a huge attack and =
management headache. Eliminate or propose a different solution.=20

Phil


On 2013-05-31, at 13:58, Justin Richer  wrote:

I'm not willing to write out an entire class of clients from this spec, =
especially when we have stated use cases for them doing dynamic =
registration.

I'm sorry, but your proposed solution will simply not work.

 -- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a credential is an implicit =
client. An implicit client is transient and so would never update.=20

Besides, as i have stated, implicit clients should not use dyn reg.=20


Phil


On 2013-05-31, at 13:41, Justin Richer  wrote:

But the outstanding question is: how do you get the access token to =
access the created resource (IE: the Registration Access Token)? You =
can't use the client_credentials flow for a client with no credentials!

 -- Justin




On 05/31/2013 12:58 PM, Phil Hunt wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

=20

Even simpler. You don't need an access token to create a new resource. =
You just need one to access one. That is just basic security config.=20


Phil


On 2013-05-31, at 12:34, Justin Richer  wrote:

I agree that we are going in circles, since I just was going to bring up =
my counter argument of "what about clients with no credentials?" again, =
which *still* isn't addressed by what you suggest doing, below. I also =
believe that getting rid of the Registration Access Token but using some =
other token method would actually make the spec larger, though I'd be =
glad to review a concrete counter-proposal if you'd like to write one. =
And the fact that OIDC is doing it this way, and considered but rejected =
the way that you're describing, should say something to the WG here =
about whether or not this is the right choice. Rough consensus and =
running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll =
move to the next draft in the last call process shortly, as I have a =
handful of non-normative editorial changes that I need to make, thanks =
to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to =
future feedback.

 -- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.=20

=20

There is absolutely no need for a registration access token.=20

=20

Get rid of it and just use access tokens as per 6749. If you can't =
follow 6749 and need new issuing methods, what are others to say =
regarding inventing new methods?

=20

I have not heard a good reason for the special process or one good =
enough to warrant a new method for issuing an access token. Does the =
broader group realize this is what the spec says?

=20

Yes, i heard a lot saying OIDC does it this way. But that is a political =
reason, not a technical reason. Still, compatibility is always a strong =
objective.  Even so, oidc could keep using their method just fine. There =
is no obligation here to do the same.=20

=20

The only reason so far was expiry of client creds. Well, why not require =
the client to update prior to expiry? It makes no sense to have another =
token with longer expiry. B'sides, even expired the client can =
re-register from scratch.=20

=20

Why force the client to persist multiple tokens and creds? That is far =
far too complex.=20

=20

Finally if you get rid of registration access token the spec size will =
drop roughly in half IMO. This suggests simplicity to me.=20

=20

Apologies for my rant. Maybe we should park this for now. We are going =
in circles.=20

Phil


On 2013-05-31, at 11:25, Justin Richer  wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear =
about which part you're objecting to because the answers are different. =
Please use the terms as defined in the document so that we all know =
which component we're talking about. I'm sure you'd agree than in =
specification work such as this, precision of language and labels is key =
for communication between parties. This is precisely why there's a =
Terminology section right up front, so that when I say "Registration =
Access Token" you can know that I mean a very specific thing, and when I =
say "Initial Registration Token" I mean a very different specific thing. =
So I'm asking you, please, use the defined terms so that we can avoid =
this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses =
to update is profile" *IS* the Registration Access Token. That's all =
that that token is used for. You're not asking for it to go away, you're =
asking for it to come from the Token Endpoint instead of the response =
from the Registration Endpoint. I don't see how the client *can* get it =
from the normal token process without jumping through specialized hoops =
to make that happen. I've implemented the draft the way that it is right =
now, both client and server side, and it works. Others have implemented =
it, too. We've done interop testing, and it works. This is a proven =
pattern and from where I sit there is both rough consensus and running =
code.

I believe that I've already pointed out how the solutions you've =
proposed so far won't work in practice, for various reasons, many of =
which have already been brought up and discussed previously. If you have =
another way for the client to get its Registration Access Token, please =
propose it; but I haven't seen anything yet that will fly.

 -- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:

Justin,

=20

This is my primary objection! We can't keep it straight. Their should be =
no such thing as a registrstion access token!  Just the token the client =
obtains to update its profile through the normal token request process.=20

Phil


On 2013-05-31, at 10:55, Justin Richer  wrote:

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through =
the normal token server no problem. (The lifecycle writeups don't call =
this out explicitly but I would be willing to do so.) Or you could get =
it elsewhere. Doesn't matter, just like it doesn't matter with any other =
OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from =
the token endpoint would require a lot more work and complexity on =
behalf of both of the client and server. Either you end up with public =
clients getting secrets they shouldn't need or with granting clients =
access to the client_credentials flow when they shouldn't actually have =
it. Plus it adds extra round trips which don't buy you anything.

 -- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:

The preference is to have the access token for registration issued by =
the normal token server rather then by the registration endpoint.=20

=20

In the current draft it is obtained through a unique process and must =
outlive the client.=20


Phil


On 2013-05-30, at 19:47, "Richer, Justin P."  wrote:

I don't understand any of the comments below -- it already *is* an =
OAuth2 protected resource without any special handling. Your access =
tokens can be short-lived, long-lived, federated, structured, random =
blobs ... totally doesn't matter. They are access tokens being used to =
access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the =
beginning are merely examples of some ways you *could* use it and are =
non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

 -- Justin

  _____ =20

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt



Phil


On 2013-05-30, at 16:11, "Richer, Justin P."  wrote:

Comments inline, marked by [JR].

  _____ =20

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

=20

@independentid

www.independentid.com

phil.hunt@oracle.com

=20

=20

=20

On 2013-05-30, at 2:09 PM, Justin Richer wrote:






OK, I think see part of the hang up. I have not seen the scenario that =
you describe, where you trade a 3rd party token for a "local" token. I =
have seen where access tokens are federated directly at the PR. =
(Introspection lets you do some good things with that pattern.)=20

=20

=20

=20

=20


------=_NextPart_000_0045_01CE5DFF.552B2E60
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


See my comments =
inline [DFC]
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=

 =

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

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

 
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Friday, =
May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F =
Coffin; oauth@ietf.org
Subject: Re: [OAUTH-WG] review comments =
on draft-ietf-oauth-dyn-reg-11.txt
 
I feel the need to clarify a couple =
erroneous things in Phil's statement:

  * To be clear, Draft =
11 has the same Registration Access Token system that has been in place =
since draft 01, it is not inventing something new at the last minute as =
could be inferred from the statement below.
[DFC] =C2=A0I =
agree with Justin.=C2=A0 There is nothing new in draft 11 regarding =
Registration Access Tokens that wasn=E2=80=99t in the initial =
draft.=C2=A0 It appears because Phil hasn=E2=80=99t been following the =
proposed drafts until the last call he is now raising an issue no one in =
the WG saw as an issue.=C2=A0 That=E2=80=99s not to say his point =
isn=E2=80=99t valid, but the discussion continues to go all over the map =
between =E2=80=9Clocal=E2=80=9D and =E2=80=9Cfederated=E2=80=9D tokens, =
usage of the RFC6749 =E2=80=9CToken=E2=80=9D endpoint, etc.=C2=A0 It =
would be great if all of Phil=E2=80=99s points could be addressed in =
priority
without the threads becoming so convoluted no one is able to =
make sense or even comprehend the point being =
discussed.

  * DynReg is using an =
absolutely standard OAuth 2 Bearer token as the Registration Access =
Token, it's just not coming from a Token Endpoint. However, since an =
OAuth Protected Resource doesn't care where its tokens come from so long =
as it can validate them, I don't see this as a problem -- this is a key =
point where Phil and I disagree.
[DFC] =C2=A0I =
understand the disagreement, but I have not seen a proposal from Phil =
that would describe the differences between the two perspectives other =
than to say that the Dynamic Registration should use the Token endpoint =
defined in RFC6749, which does not=C2=A0=C2=A0=C2=A0 discuss dynamic =
registration.=C2=A0 Phil=E2=80=99s point as I understand it is that =
there should be no difference between an access token used to access =
resource owner protected data and the registration structure, which I do =
not agree with.=C2=A0 As I said in the =
previous
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 response, my users do NOT want to provide implied access to resource =
owner protected data just because a client is creating a registration =
with an AS.=C2=A0 This would be the situation if the client credential =
flow is used to register an application.=C2=A0 Since =
our
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 implementation does NOT support the implicit flow, that use case is one =
we have elected NOT to support.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [DFC]=C2=A0 I repeat my initial comment, this =
conversation has been a circular exchange now for the past few days =
without any appearance of an alternative option to resolve the =
issues.

 -- Justin
On 05/31/2013 03:33 PM, Phil Hunt =
wrote:
Don,
 
I =
am not proposing any change in meaning. If registration acces token =
issues by normal token server with scope registration everything is =
clear as it is for any other protected API. Draft 11 invents a whole new =
system. I strongly disagree with =
this.

Phil

On 2013-05-31, at 15:16, Donald F =
Coffin <donald.coffin@reminetworks=
.com> wrote:
For =
something that was agreed to be parked a few hours ago, there sure seems =
to still be a lot of circular discussion.  Should we ask a mediator =
to intervene?
 
FWIW I =
believe that is a significantly strong reason to differentiate an access =
token that can access the registration information without having the =
ability to access protected data.  Especially given the implied =
strength of the =E2=80=9Cclient credential=E2=80=9D obtained access =
token.  I have found it extremely confusing to users when =
explaining the difference between an access token obtained thorough an =
authorization code flow and a client credential flow, simply because =
they are both called an =E2=80=9Caccess token=E2=80=9D.  Changing =
the meaning of an access token obtained through the client credential =
flow to mean it has the ability to update a registration, when a user =
may not want it to have access to protected data will only increase both =
the complexity of the access tokens as well as make their usage harder =
to explain to non-technical individuals who have to understand the =
differences between the access tokens obtained through the various =
flows.
 
Just my =
two cents.
 
=

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

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

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

From:=
 =
Phil Hunt [mailto:phil.hunt@oracle.com] =

Sent: Friday, May 31, 2013 11:11 AM
To: Justin =
Richer
Cc: oauth@ietf.org WG
Subject: =
Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt
 
To be =
clear. 
 
It is two separate =
issues. 
 
1. Anonymous clients can easily be handled through =
policy config. 
 
2. Support for implicit clients needs to be discussed. =
The current proposal creates large negative value for the service =
provider and most would never allow in current form. Yes it gives each =
execution instance a new id, but that isnt what sp's want. It is a huge =
attack and management headache. Eliminate or propose a different =
solution. 

Phil

On 2013-05-31, at =
13:58, Justin Richer <jricher@mitre.org> =
wrote:
I'm not willing to write out an entire =
class of clients from this spec, especially when we have stated use =
cases for them doing dynamic registration.

I'm sorry, but your =
proposed solution will simply not work.

 -- =
Justin
On 05/31/2013 01:56 PM, =
Phil Hunt wrote:
Well the only client that wouldn't have a credential =
is an implicit client. An implicit client is transient and so would =
never update. 

Besides, as i have stated, implicit clients =
should not use dyn reg. 

Phil

On 2013-05-31, at 13:41, Justin =
Richer <jricher@mitre.org> =
wrote:
But the outstanding question is: how do =
you get the access token to access the created resource (IE: the =
Registration Access Token)? You can't use the client_credentials flow =
for a client with no credentials!

 -- =
Justin


On 05/31/2013 =
12:58 PM, Phil Hunt wrote:
Yes. I specified the trivial solution to anonymous =
clients earlier.
 
Even simpler. You don't need an access token to create =
a new resource. You just need one to access one. That is just basic =
security config. 

Phil

On 2013-05-31, at 12:34, Justin =
Richer <jricher@mitre.org> =
wrote:
I agree that we are going in circles, =
since I just was going to bring up my counter argument of "what =
about clients with no credentials?" again, which *still* isn't =
addressed by what you suggest doing, below. I also believe that getting =
rid of the Registration Access Token but using some other token method =
would actually make the spec larger, though I'd be glad to review a =
concrete counter-proposal if you'd like to write one. And the fact that =
OIDC is doing it this way, and considered but rejected the way that =
you're describing, should say something to the WG here about whether or =
not this is the right choice. Rough consensus and running code, after =
all.

Regardless, I agree to park this issue and leave the text as =
is. We'll move to the next draft in the last call process shortly, as I =
have a handful of non-normative editorial changes that I need to make, =
thanks to feedback from a few folks.

Again, thanks for your =
thorough review, Phil, and I look forward to future =
feedback.

 -- Justin
On 05/31/2013 12:28 PM, Phil Hunt =
wrote:
I disagree. 
 
There is absolutely no need for a registration access =
token. 
 
Get rid of it and just use access tokens as per 6749. =
If you can't follow 6749 and need new issuing methods, what are others =
to say regarding inventing new methods?
 
I =
have not heard a good reason for the special process or one good enough =
to warrant a new method for issuing an access token. Does the broader =
group realize this is what the spec says?
 
Yes, i heard a lot saying OIDC does it this way. But =
that is a political reason, not a technical reason. Still, compatibility =
is always a strong objective.  Even so, oidc could keep using their =
method just fine. There is no obligation here to do the =
same. 
 
The only reason so far was expiry of client creds. =
Well, why not require the client to update prior to expiry? It makes no =
sense to have another token with longer expiry. B'sides, even expired =
the client can re-register from =
scratch. 
 
Why force the client to persist multiple tokens and =
creds? That is far far too complex. 
 
Finally if you get rid of registration access token =
the spec size will drop roughly in half IMO. This suggests simplicity to =
me. 
 
Apologies for my rant. Maybe we should park this for =
now. We are going in =
circles. 

Phil

On 2013-05-31, at 11:25, Justin =
Richer <jricher@mitre.org> =
wrote:
Phil,

We *can* keep it straight =
just fine, but I just need you to be clear about which part you're =
objecting to because the answers are different. Please use the terms as =
defined in the document so that we all know which component we're =
talking about. I'm sure you'd agree than in specification work such as =
this, precision of language and labels is key for communication between =
parties. This is precisely why there's a Terminology section right up =
front, so that when I say "Registration Access Token" you can =
know that I mean a very specific thing, and when I say "Initial =
Registration Token" I mean a very different specific thing. So I'm =
asking you, please, use the defined terms so that we can avoid this =
unnecessary confusion.

But anyway, what you're talking about =
below, "the token the client uses to update is profile" *IS* =
the Registration Access Token. That's all that that token is used for. =
You're not asking for it to go away, you're asking for it to come from =
the Token Endpoint instead of the response from the Registration =
Endpoint. I don't see how the client *can* get it from the normal token =
process without jumping through specialized hoops to make that happen. =
I've implemented the draft the way that it is right now, both client and =
server side, and it works. Others have implemented it, too. We've done =
interop testing, and it works. This is a proven pattern and from where I =
sit there is both rough consensus and running code.

I believe =
that I've already pointed out how the solutions you've proposed so far =
won't work in practice, for various reasons, many of which have already =
been brought up and discussed previously. If you have another way for =
the client to get its Registration Access Token, please propose it; but =
I haven't seen anything yet that will fly.

 -- =
Justin
On 05/31/2013 11:10 AM, =
Phil Hunt wrote:
Justin,
 
This is my primary objection! We can't keep it =
straight. Their should be no such thing as a registrstion access token! =
 Just the token the client obtains to update its profile through =
the normal token request =
process. 

Phil

On 2013-05-31, at 10:55, Justin =
Richer <jricher@mitre.org> =
wrote:
Which token are you referring to =
here?

If it's the Initial Registration Token, then you could get =
that through the normal token server no problem. (The lifecycle writeups =
don't call this out explicitly but I would be willing to do so.) Or you =
could get it elsewhere. Doesn't matter, just like it doesn't matter with =
any other OAuth2 protected resource.

If it's the Registration =
Access Token, then having the token come from the token endpoint would =
require a lot more work and complexity on behalf of both of the client =
and server. Either you end up with public clients getting secrets they =
shouldn't need or with granting clients access to the client_credentials =
flow when they shouldn't actually have it. Plus it adds extra round =
trips which don't buy you anything.

 -- =
Justin
On 05/31/2013 10:15 AM, =
Phil Hunt wrote:
The preference is to have the access token for =
registration issued by the normal token server rather then by the =
registration endpoint. 
 
In the current draft it is obtained through a unique =
process and must outlive the client. 

Phil

On 2013-05-30, at 19:47, =
"Richer, Justin P." <jricher@mitre.org> =
wrote:
I don't =
understand any of the comments below -- it already *is* an OAuth2 =
protected resource without any special handling. Your access tokens can =
be short-lived, long-lived, federated, structured, random blobs ... =
totally doesn't matter. They are access tokens being used to access a =
normal protected resource. Full stop.

Anything else is out of =
scope. The lifecycle discussions at the beginning are merely examples of =
some ways you *could* use it and are non-normative and =
non-exhaustive.

You seem to be asking for something that's =
already in the draft.

 -- =
Justin
From:=
 =
Phil Hunt [phil.hunt@oracle.com]
Sent=
: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin =
P.
Cc: John Bradley; oauth@ietf.org WG
Subject: =
Re: [OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt


Phil

On 2013-05-30, at =
16:11, "Richer, Justin P." <jricher@mitre.org> =
wrote:
Comments inline, marked by [JR].
From:=
 =
Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, =
May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John =
Bradley; oauth@ietf.org WG
Subject: Re: =
[OAUTH-WG] review comments on =
draft-ietf-oauth-dyn-reg-11.txt
See =
below.
 
On =
2013-05-30, at 2:09 PM, Justin Richer wrote:



OK, I think see part of the hang up. I have not seen =
the scenario that you describe, where you trade a 3rd party token for a =
"local" token. I have seen where access tokens are federated =
directly at the PR. (Introspection lets you do some good things with =
that pattern.) =

=

 
 
 
 

------=_NextPart_000_0045_01CE5DFF.552B2E60--